udev & kernel names

udev & kernel names

[Nishanth Aravamudan]

Greg, udev Developers,

One of the most valuable features of new udev-based system is persistent
device naming. This is especially useful for large systems, which may
involve upwards of 4000 disks. Rather than determining which disk is
sdzz, the administrator can name it tray15_disk7 and thus easily access
the drive. We all know this much, though.

Another interesting idea would be to somehow inform the kernel of these
new names (sysfs?). The gist being that currently, even though udev has
created a new dev node for the device, the kernel is unaware of this
``name'' when reporting errors. I think it could be very useful for our
friendly sysadmin to see ``tray15_disk7 has failed'' rather than ``sdzz
has failed.'' Or perhaps they want to offline an entire tray; it would
be simpler in scripts to refer to ``tray15_*'' than the appropriate
kernel device nodes.

My questions are:

Is this feasible?
Would a new file per-device in sysfs be the appropriate place for this?
Is there a better way to go about getting these useful log messages?

If I need to clarify the problem/proposed solution further, please let
me know.

Please make sure to keep me CC'ed on replies, as I am not subscribed to
the hotplug list.

Thanks,
Nish


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Greg KH]

On Tue, Apr 26, 2005 at 04:15:16PM -0700, Nishanth Aravamudan wrote:
> Greg, udev Developers,
> 
> One of the most valuable features of new udev-based system is persistent
> device naming. This is especially useful for large systems, which may
> involve upwards of 4000 disks. Rather than determining which disk is
> sdzz, the administrator can name it tray15_disk7 and thus easily access
> the drive. We all know this much, though.
> 
> Another interesting idea would be to somehow inform the kernel of these
> new names (sysfs?).

Um, didn't we talk about this before?

And didn't I get across the point that this is pointless, wrong, and
will never happen? :)

> The gist being that currently, even though udev has
> created a new dev node for the device, the kernel is unaware of this
> ``name'' when reporting errors. I think it could be very useful for our
> friendly sysadmin to see ``tray15_disk7 has failed'' rather than ``sdzz
> has failed.'' Or perhaps they want to offline an entire tray; it would
> be simpler in scripts to refer to ``tray15_*'' than the appropriate
> kernel device nodes.
> 
> My questions are:
> 
> Is this feasible?

No.

> Would a new file per-device in sysfs be the appropriate place for this?

No.

> Is there a better way to go about getting these useful log messages?

Modify your syslog program to do it.

Oh, and what about the fact that I can create 2 device nodes in the fs
that really are the same kernel device?

/me watches the ras developers get all agitated

> If I need to clarify the problem/proposed solution further, please let
> me know.

Please let me know who is trying to drive such a misguided and
ill-conceived issue and I will track them down...

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Daniel Stekloff]

On Wed, 2005-04-27 at 09:05 -0700, Greg KH wrote:
> On Tue, Apr 26, 2005 at 04:15:16PM -0700, Nishanth Aravamudan wrote:
> > Greg, udev Developers,
> > 
> > One of the most valuable features of new udev-based system is persistent
> > device naming. This is especially useful for large systems, which may
> > involve upwards of 4000 disks. Rather than determining which disk is
> > sdzz, the administrator can name it tray15_disk7 and thus easily access
> > the drive. We all know this much, though.
> > 
> > Another interesting idea would be to somehow inform the kernel of these
> > new names (sysfs?).
> 
> Um, didn't we talk about this before?
> 
> And didn't I get across the point that this is pointless, wrong, and
> will never happen? :)
> 
> > The gist being that currently, even though udev has
> > created a new dev node for the device, the kernel is unaware of this
> > ``name'' when reporting errors. I think it could be very useful for our
> > friendly sysadmin to see ``tray15_disk7 has failed'' rather than ``sdzz
> > has failed.'' Or perhaps they want to offline an entire tray; it would
> > be simpler in scripts to refer to ``tray15_*'' than the appropriate
> > kernel device nodes.
> > 
> > My questions are:
> > 
> > Is this feasible?
> 
> No.
> 
> > Would a new file per-device in sysfs be the appropriate place for this?
> 
> No.
> 
> > Is there a better way to go about getting these useful log messages?
> 
> Modify your syslog program to do it.



Part of the goal was to add the dev_* macros in the kernel to identify
devices. In User Space, you can query sysfs or udev for more information
regarding a specific device from the information present in the log
message. Another (failed/neglected/unneeded) goal we had was to create
an application that could parse log files for specific device
information, providing a single interface for querying log messages by
device, by device class, etc. All done from User Space.



> Oh, and what about the fact that I can create 2 device nodes in the fs
> that really are the same kernel device?
> 
> /me watches the ras developers get all agitated


<yawn>

;^)


> > If I need to clarify the problem/proposed solution further, please let
> > me know.
> 
> Please let me know who is trying to drive such a misguided and
> ill-conceived issue and I will track them down...
> 
> thanks,
> 
> greg k-h
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
> _______________________________________________
> 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
> 



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Nishanth Aravamudan]

* Greg KH <greg@kroah.com> [2005-0427 09:05:46 -0700]:

> On Tue, Apr 26, 2005 at 04:15:16PM -0700, Nishanth Aravamudan wrote:
> > Greg, udev Developers,
> > 
> > One of the most valuable features of new udev-based system is persistent
> > device naming. This is especially useful for large systems, which may
> > involve upwards of 4000 disks. Rather than determining which disk is
> > sdzz, the administrator can name it tray15_disk7 and thus easily access
> > the drive. We all know this much, though.
> > 
> > Another interesting idea would be to somehow inform the kernel of these
> > new names (sysfs?).
> 
> Um, didn't we talk about this before?
> 
> And didn't I get across the point that this is pointless, wrong, and
> will never happen? :)

Sorry, Greg, I wasn't part of that conversation. Thanks for the
information that this won't happen.

> > The gist being that currently, even though udev has
> > created a new dev node for the device, the kernel is unaware of this
> > ``name'' when reporting errors. I think it could be very useful for our
> > friendly sysadmin to see ``tray15_disk7 has failed'' rather than ``sdzz
> > has failed.'' Or perhaps they want to offline an entire tray; it would
> > be simpler in scripts to refer to ``tray15_*'' than the appropriate
> > kernel device nodes.
> > 
> > My questions are:
> > 
> > Is this feasible?
> 
> No.
> 
> > Would a new file per-device in sysfs be the appropriate place for this?
> 
> No.
> 
> > Is there a better way to go about getting these useful log messages?
> 
> Modify your syslog program to do it.

Would it make some sense then to make an udev-aware syslog program? If
such a package were created, would it be possible to integrate it with
the udev package? Or, minimally, provide some documentation as to how to
make the modifications oneself?

> Oh, and what about the fact that I can create 2 device nodes in the fs
> that really are the same kernel device?

I never said my proposal was perfect :) I was trying to find out what
was possible and what wasn't. You answered that fine.

> /me watches the ras developers get all agitated
> 
> > If I need to clarify the problem/proposed solution further, please let
> > me know.
> 
> Please let me know who is trying to drive such a misguided and
> ill-conceived issue and I will track them down...

I will see if I can get you some names :)

Thanks,
Nish


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Greg KH]

On Wed, Apr 27, 2005 at 09:53:17AM -0700, Nishanth Aravamudan wrote:
> * Greg KH <greg@kroah.com> [2005-0427 09:05:46 -0700]:
> > On Tue, Apr 26, 2005 at 04:15:16PM -0700, Nishanth Aravamudan wrote:
> > > Is there a better way to go about getting these useful log messages?
> > 
> > Modify your syslog program to do it.
> 
> Would it make some sense then to make an udev-aware syslog program?

Sure.

> If such a package were created, would it be possible to integrate it
> with the udev package? Or, minimally, provide some documentation as to
> how to make the modifications oneself?

No, udev will not contain such a package.  Please realize that there are
at least 3 different, popular syslog programs, and probably a zillion
other, not as popular ones.  As well as a number of big, expensive
syslog programs from companies that are very willing to have you pay for
this kind of feature :)

Use udevinfo to do a mapping from kernel name to udev-known name.
That's all the documentation you need.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Daniel Stekloff]

On Wed, 2005-04-27 at 09:53 -0700, Nishanth Aravamudan wrote:
> * Greg KH <greg@kroah.com> [2005-0427 09:05:46 -0700]:
> 
> > On Tue, Apr 26, 2005 at 04:15:16PM -0700, Nishanth Aravamudan wrote:
> > > Greg, udev Developers,
> > > 
> > > One of the most valuable features of new udev-based system is persistent
> > > device naming. This is especially useful for large systems, which may
> > > involve upwards of 4000 disks. Rather than determining which disk is
> > > sdzz, the administrator can name it tray15_disk7 and thus easily access
> > > the drive. We all know this much, though.
> > > 
> > > Another interesting idea would be to somehow inform the kernel of these
> > > new names (sysfs?).
> > 
> > Um, didn't we talk about this before?
> > 
> > And didn't I get across the point that this is pointless, wrong, and
> > will never happen? :)
> 
> Sorry, Greg, I wasn't part of that conversation. Thanks for the
> information that this won't happen.
> 
> > > The gist being that currently, even though udev has
> > > created a new dev node for the device, the kernel is unaware of this
> > > ``name'' when reporting errors. I think it could be very useful for our
> > > friendly sysadmin to see ``tray15_disk7 has failed'' rather than ``sdzz
> > > has failed.'' Or perhaps they want to offline an entire tray; it would
> > > be simpler in scripts to refer to ``tray15_*'' than the appropriate
> > > kernel device nodes.
> > > 
> > > My questions are:
> > > 
> > > Is this feasible?
> > 
> > No.
> > 
> > > Would a new file per-device in sysfs be the appropriate place for this?
> > 
> > No.
> > 
> > > Is there a better way to go about getting these useful log messages?
> > 
> > Modify your syslog program to do it.
> 
> Would it make some sense then to make an udev-aware syslog program? If
> such a package were created, would it be possible to integrate it with
> the udev package? Or, minimally, provide some documentation as to how to
> make the modifications oneself?



I know you're going to kick me in the head for saying this, but the User
Space portion of Event Logging can do this. Whatever the issues there
were for the kernel portion - ignore it. The User Space Event Logging is
very useful. There are ways to trigger off devices, specific messages.
It has callouts so you could run specific analysis at error events. You
can even set up templates to work off of for specific errors.

You can create templates based on *existing* kernel messages based on
the specific format and then execute specific instructions for that
specific message. No need to edit the kernel. 

Then... we could resurrect sysdiag to automate responding to error
messages.

Heh... next, THE WORLD!

<grin>

Or... you could implement your own. One thing to keep in mind, sysfs and
udev don't have all the information necessary. You may need to query
other sources.

Thanks,

Dan


> > Oh, and what about the fact that I can create 2 device nodes in the fs
> > that really are the same kernel device?
> 
> I never said my proposal was perfect :) I was trying to find out what
> was possible and what wasn't. You answered that fine.
> 
> > /me watches the ras developers get all agitated
> > 
> > > If I need to clarify the problem/proposed solution further, please let
> > > me know.
> > 
> > Please let me know who is trying to drive such a misguided and
> > ill-conceived issue and I will track them down...
> 
> I will see if I can get you some names :)
> 
> Thanks,
> Nish
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
> _______________________________________________
> 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
> 



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Martin Schwenke]

>>>>> "Greg" = Greg KH <greg@kroah.com> writes:

    >> Is there a better way to go about getting these useful log
    >> messages?

    Greg> Modify your syslog program to do it.

/me dons asbestos suit...  :-)

... and we've had the following conversation before, but let me try to
put it more clearly right here.

Kernel names are evil.  They look like device names, but they are not
device names.  They are kernel names.  Device names are created in
userspace and the kernel has no knowledge of them.  The confusion
occurs because they look the same (or similar)...

A nicer solution would be to log different canonical labels for
devices, and pass these to udev.  For SCSI devices this could be
something like "scsi/1:2:3:4" or even sd/major,minor - it doesn't
matter too much.

In a previous conversation (or more :-) you pointed out that the
kernel name is a canonical label and that's good enough.

One reason why it isn't good enough is that people keep getting
confused between kernel names and devices names.  When they do this
they suggest passing the device name back into the kernel, so you will
hear this suggestion as long as kernel names are used.  :-)

... and I'll still argue that the kernel name code is bloat.  Sure,
some "canonical labels" are going to look very similar to kernel names
(e.g. ttys), but many of the important ones aren't going to.  The
"default name" code should be in udev, not in the kernel.  The kernel
currently exports the kernel name and the major/minor - there's
unnecessary duplication of information there.

Kernel names are a bad user interface because they look like device
names and they confuse people into believing they're looking at the
same namespace.

peace & happiness,
martin

-- 
Martin Schwenke                 IBM OzLabs - Linux Technology Centre
<martins@au.ibm.com>            http://ozlabs.au.ibm.com/~martins/



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Greg KH]

On Thu, Apr 28, 2005 at 09:01:29AM +1000, Martin Schwenke wrote:
> >>>>> "Greg" = Greg KH <greg@kroah.com> writes:
> 
>     >> Is there a better way to go about getting these useful log
>     >> messages?
> 
>     Greg> Modify your syslog program to do it.
> 
> /me dons asbestos suit...  :-)
> 
> ... and we've had the following conversation before, but let me try to
> put it more clearly right here.
> 
> Kernel names are evil.  They look like device names, but they are not
> device names.  They are kernel names.  Device names are created in
> userspace and the kernel has no knowledge of them.  The confusion
> occurs because they look the same (or similar)...

I know, we've been over this before.  A very simple solution to this is
just never have the kernel print the name it is internally using :)

> A nicer solution would be to log different canonical labels for
> devices, and pass these to udev.  For SCSI devices this could be
> something like "scsi/1:2:3:4" or even sd/major,minor - it doesn't
> matter too much.

dev_printk() solves this issue nicely.  Care to create a patch for all
places that you object to where the kernel prints out a kernel name?

thanks,

greg k-h



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[ocomber]

On Wed, 2005-04-27 at 09:05 -0700, Greg KH wrote:

<snip>

> 
> > Is there a better way to go about getting these useful log messages?
> 
> Modify your syslog program to do it.
> 

Would it be possible to call udev's parser directly?  

What I'm thinking is syslog Somehow (tm) knows it has a line with a
device name in it.  It could then call udev's parser to execute the
appropriate rule, but instead of creating any devices, put udev's device
name on standard output.  Syslog could then substitute this into place
on the log line.

I'm sure a well crafted regular expression could split out the kernel
device name to pass to the parser, and syslog then appends udev's idea
of the device name to the line.  If the udev parser returns nothing, you
know your regex produced a red herring.


> Oh, and what about the fact that I can create 2 device nodes in the fs
> that really are the same kernel device?
> 
> /me watches the ras developers get all agitated
> 
> > If I need to clarify the problem/proposed solution further, please let
> > me know.
> 
> Please let me know who is trying to drive such a misguided and
> ill-conceived issue and I will track them down...
> 
> thanks,
> 
> greg k-h
> 

Thanks,
-Oli




-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

Quoting ocomber <ocomber@cmedltd.com>:
> Would it be possible to call udev's parser directly?  

udevinfo?

-- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: udev & kernel names

[ocomber]

On Thu, 2005-04-28 at 13:21 +0200, Michael Buesch wrote:
> Quoting ocomber <ocomber@cmedltd.com>:
> > Would it be possible to call udev's parser directly?  
> 
> udevinfo?
> 

Ah, cool, didn't know you could already do this - No new parts
necessary! :0)

-Oli



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Kay Sievers]

On Wed, 2005-04-27 at 21:37 -0700, Greg KH wrote:
> On Thu, Apr 28, 2005 at 09:01:29AM +1000, Martin Schwenke wrote:
> > >>>>> "Greg" = Greg KH <greg@kroah.com> writes:
> > 
> >     >> Is there a better way to go about getting these useful log
> >     >> messages?
> > 
> >     Greg> Modify your syslog program to do it.
> > 
> > /me dons asbestos suit...  :-)
> > 
> > ... and we've had the following conversation before, but let me try to
> > put it more clearly right here.
> > 
> > Kernel names are evil.  They look like device names, but they are not
> > device names.  They are kernel names.  Device names are created in
> > userspace and the kernel has no knowledge of them.  The confusion
> > occurs because they look the same (or similar)...
> 
> I know, we've been over this before.  A very simple solution to this is
> just never have the kernel print the name it is internally using :)
> 
> > A nicer solution would be to log different canonical labels for
> > devices, and pass these to udev.  For SCSI devices this could be
> > something like "scsi/1:2:3:4" or even sd/major,minor - it doesn't
> > matter too much.
> 
> dev_printk() solves this issue nicely.  Care to create a patch for all
> places that you object to where the kernel prints out a kernel name?

What about centralizing error messages at a common place and use the
DEVPATH of the device instead? It's the key to look up the device-name
in the udev-database and probably the best namespace to use. There would
also no need to print driver or bus-id, cause that can be read from the
devpath-location in sysfs.
A central place for error logging would be nice, cause we would be able
to use a better transport than the kernel-log to parse.

Thanks,
Kay



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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

Re: udev & kernel names

[Martin Schwenke]

>>>>> "Kay" = Kay Sievers <kay.sievers@vrfy.org> writes:

    Kay> What about centralizing error messages at a common place and
    Kay> use the DEVPATH of the device instead? It's the key to look
    Kay> up the device-name in the udev-database and probably the best
    Kay> namespace to use. There would also no need to print driver or
    Kay> bus-id, cause that can be read from the devpath-location in
    Kay> sysfs.  A central place for error logging would be nice,
    Kay> cause we would be able to use a better transport than the
    Kay> kernel-log to parse.

A DEVPATH value like /block/sda?  That includes the kernel name... :-(

That's one part of the non-kernel-name-canonical-labels argument I
haven't been able to convince myself of.  If you don't have kernel
names, then the subsystem stuff changes fairly fundamentally.

When I modprobe scsi_debug, I see the following events:

    add-bus-/bus/pseudo
    add-module-/module/scsi_debug
    add-pseudo-/devices/pseudo_0/adapter0
    add-bus-/bus/pseudo/devices
    add-bus-/bus/pseudo/drivers
    add-scsi_host-/class/scsi_host/host2
    add-scsi-/devices/pseudo_0/adapter0/host2/target2:0:0/2:0:0:0
    add-drivers-/bus/pseudo/drivers/scsi_debug
    add-scsi_generic-/class/scsi_generic/sg0
    add-scsi_device-/class/scsi_device/2:0:0:0
    add-block-/block/sda

One thing that concerns me is that I don't see anything that adds the
SCSI bus link:

    add-scsi-/bus/scsi/devices/2:0:0:0

That would seems to be the most easily catchable event for a SCSI
device ...

However, for the block subsystem, these would be about as meaningful as
/block/sda:

    add-block-/block/major/minor
    add-block-/block/major,minor

That's incredibly sane.  Block devices, for example, don't really have
names: they have major and minor numbers...

At the moment you can guess the type of block device from the basename
of /block/sda.  However, that's only a "guess".  Looking at the
"device" link in /block/major,minor gives you at least as much
information.

peace & happiness,
martin

-- 
Martin Schwenke                 IBM OzLabs - Linux Technology Centre
<martins@au.ibm.com>            http://ozlabs.au.ibm.com/~martins/



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
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