From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: libsysfs/udev hang
Date: Tue, 23 Mar 2004 20:57:57 +0000 [thread overview]
Message-ID: <4060A4D5.9050808@gmx.net> (raw)
In-Reply-To: <4060259D.4000905@gmx.net>
Daniel Stekloff wrote:
> On Tuesday 23 March 2004 11:09 am, Greg KH wrote:
>
>>On Tue, Mar 23, 2004 at 06:04:16PM +0100, Carl-Daniel Hailfinger wrote:
>>
>>>>That's probably the bug.
>>>
>>>Then it has to be fixed in udevinfo.c:print_device_chain, too.
>>
>>Probably. Care to send a patch?
>
>
> Yes, udevinfo.c print_device_chain is wrong. It doesn't properly use libsysfs
> mechanisms of "open/close" and "get". I will make a patch, unless someone
> else beats me to it.
>
> If there's confusion on "open/close" and "get" and how that works with
> libsysfs, please let me know. I can explain further.
Well, I assumed the udevinfo.c code was correct and took it as a starting
point since the libsysfs documentation has many bugs and sports unclear
wording (will send a patch for those sections once I've understood what
all of those functions do).
Greg: I noticed libsysfs in udev was updated recently, but it seems to
differ in a few definitions from libsysfs-1.0.0. Is that intended?
To explain my motivation for the buggy code I posted:
For my ataraid detection code, I need a list of all hard disks attached to
the system hanging off a pci ATA/SATA controller. For each disk, I need
the size, the ability to read from the correct device, the vendor/device/
subsystem_vendor/subsystem_device of the hard disk controller.
struct harddisk {
char name[SYSFS_PATH_MAX];
dev_t device;
unsigned long size;
unsigned int vendor;
unsigned int device;
unsigned int subsystem_vendor;
unsigned int subsystem_device;
}
The ataraid detection gets a list of struct harddisk and checks if it can
find devices which are the basis of a Promise/Highpoint/whatever RAID.
Greg: Is there some block device enumeration code in udev I could adapt to
my purposes?
I was inspired to hack a bit on udev by kpartx (utility to enable
partitions on top of dm) which uses the udev build environment quite
successfully and am contemplating where ataraid detection from userspace
should end up in the long run. Should it be integrated into udev? Separate
package?
Dan: Is there a preferred way for getting the above accomplished with
libsysfs?
Regards,
Carl-Daniel
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-03-23 20:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 11:55 libsysfs/udev hang Carl-Daniel Hailfinger
2004-03-23 15:57 ` Greg KH
2004-03-23 17:04 ` Carl-Daniel Hailfinger
2004-03-23 19:09 ` Greg KH
2004-03-23 19:19 ` Daniel Stekloff
2004-03-23 19:24 ` Daniel Stekloff
2004-03-23 20:57 ` Carl-Daniel Hailfinger [this message]
2004-03-24 1:32 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4060A4D5.9050808@gmx.net \
--to=c-d.hailfinger.kernel.2004@gmx.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).