udev and the kernel's idea of a device

udev and the kernel's idea of a device

[Bill Nottingham]

udev does not actually change the intrinsic name inside the kernel,
wherever such a thing might be kept. [*]

So, say you have a disk error, of some sort. It gets logged in the
logs, and a few days later you go to figure out what happened.

It can be logged in various ways:

- it can print out the 'kernel' device name.

   From a user perspective who's using udev, this isn't useful -
   you need a reverse mapping.

- it can print out the, say, host-channel-id-lun

   Again, here you need a reverse mapping.
 
- it can print out the major/minor

   Of course, the major/minor are dynamic. So, not only do you need
   a reverse mapping, you need a mapping that has a timeframe associated
   with each mapping for when it was valid.

Am I missing something here? Are there better ways to handle this?

Bill

[*] aside from network devices


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Greg KH]

On Tue, Apr 06, 2004 at 03:22:29PM -0400, Bill Nottingham wrote:
> udev does not actually change the intrinsic name inside the kernel,
> wherever such a thing might be kept. [*]
> 
> So, say you have a disk error, of some sort. It gets logged in the
> logs, and a few days later you go to figure out what happened.
> 
> It can be logged in various ways:
> 
> - it can print out the 'kernel' device name.
> 
>    From a user perspective who's using udev, this isn't useful -
>    you need a reverse mapping.

Which udev can provide you easily, using udevinfo.

> - it can print out the, say, host-channel-id-lun
> 
>    Again, here you need a reverse mapping.

True, but tools lie sysfsutils provide this mapping.  That's why
dev_printk() and friends were created for.

> - it can print out the major/minor

Ick.  That just doesn't make much sense.

>    Of course, the major/minor are dynamic. So, not only do you need
>    a reverse mapping, you need a mapping that has a timeframe associated
>    with each mapping for when it was valid.
> 
> Am I missing something here? Are there better ways to handle this?

So what would you prefer the kernel to print out?  As it is very simple
to translate from the kernel device name to the real /dev name at any
point in time using udevinfo, why is that not sufficient?

thanks,

greg k-h


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Bill Nottingham]

Greg KH (greg@kroah.com) said: 
> > - it can print out the major/minor
> 
> Ick.  That just doesn't make much sense.

And yet, there are drivers that do that.

> As it is very simple
> to translate from the kernel device name to the real /dev name at any
> point in time using udevinfo, why is that not sufficient?

Requires integrating udevinfo into various random userland apps...
it's certainly doable, but it just doesn't seem very clean.

Bill


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Greg KH]

On Tue, Apr 06, 2004 at 04:10:24PM -0400, Bill Nottingham wrote:
> Greg KH (greg@kroah.com) said: 
> > > - it can print out the major/minor
> > 
> > Ick.  That just doesn't make much sense.
> 
> And yet, there are drivers that do that.

Which ones?  I'd be glad to go fix that up.

> > As it is very simple
> > to translate from the kernel device name to the real /dev name at any
> > point in time using udevinfo, why is that not sufficient?
> 
> Requires integrating udevinfo into various random userland apps...
> it's certainly doable, but it just doesn't seem very clean.

I agree, but what random userland apps are you talking about?  Can you
think of a cleaner suggestion?

thanks,

greg k-h


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Bill Nottingham]

Greg KH (greg@kroah.com) said: 
> > > Ick.  That just doesn't make much sense.
> > 
> > And yet, there are drivers that do that.
> 
> Which ones?  I'd be glad to go fix that up.

Ah, I was thinking end_request, but that got fixed in 2.6.
That will teach me to talk without checking.

> > > As it is very simple
> > > to translate from the kernel device name to the real /dev name at any
> > > point in time using udevinfo, why is that not sufficient?
> > 
> > Requires integrating udevinfo into various random userland apps...
> > it's certainly doable, but it just doesn't seem very clean.
> 
> I agree, but what random userland apps are you talking about?

Off the top of my head, iostat, cdrom capability checkers, fbset
and friends, etc. But, in the long run, see below.

> Can you think of a cleaner suggestion?

Drill HAL throughout the entire OS. :)

Bill


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Greg KH]

On Tue, Apr 06, 2004 at 04:49:24PM -0400, Bill Nottingham wrote:
> > > > As it is very simple
> > > > to translate from the kernel device name to the real /dev name at any
> > > > point in time using udevinfo, why is that not sufficient?
> > > 
> > > Requires integrating udevinfo into various random userland apps...
> > > it's certainly doable, but it just doesn't seem very clean.
> > 
> > I agree, but what random userland apps are you talking about?
> 
> Off the top of my head, iostat, cdrom capability checkers, fbset
> and friends, etc. But, in the long run, see below.

But those apps want to know the /dev node, right?  They don't get errors
back from the kernel with the kernel device name (well, I don't know
what iostat uses, but I think the later version use sysfs...).  Things
like fbset want to know where the fb device is at in /dev, not the other
way around.

Or am I confused too?

> > Can you think of a cleaner suggestion?
> 
> Drill HAL throughout the entire OS. :)

Yeah, that's the "correct" solution, but until then I imagine you need
to get real work done :)

thanks,

greg k-h


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Bill Nottingham]

Greg KH (greg@kroah.com) said: 
> > Off the top of my head, iostat, cdrom capability checkers, fbset
> > and friends, etc. But, in the long run, see below.
> 
> But those apps want to know the /dev node, right?

Well, they want to know the dev node, and they use the device
as a key to get auxillary information. For example, the framebuffer
stuff has some limited auxillary information in /proc/fb, there's
random CD-ROM info in /proc/sys/dev/cdrom/info, etc.

> back from the kernel with the kernel device name (well, I don't know
> what iostat uses, but I think the later version use sysfs...).

The version I have here still reads /proc/diskstats. Perhaps
there is a newer one.

Bill


-------------------------------------------------------
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

Re: udev and the kernel's idea of a device

[Daniel Stekloff]

On Tuesday 06 April 2004 02:06 pm, Greg KH wrote:
> On Tue, Apr 06, 2004 at 04:49:24PM -0400, Bill Nottingham wrote:
> > > > > As it is very simple
> > > > > to translate from the kernel device name to the real /dev name at
> > > > > any point in time using udevinfo, why is that not sufficient?
> > > >
> > > > Requires integrating udevinfo into various random userland apps...
> > > > it's certainly doable, but it just doesn't seem very clean.
> > >
> > > I agree, but what random userland apps are you talking about?
> >
> > Off the top of my head, iostat, cdrom capability checkers, fbset
> > and friends, etc. But, in the long run, see below.
>
> But those apps want to know the /dev node, right?  They don't get errors
> back from the kernel with the kernel device name (well, I don't know
> what iostat uses, but I think the later version use sysfs...).  Things
> like fbset want to know where the fb device is at in /dev, not the other
> way around.
>
> Or am I confused too?
>
> > > Can you think of a cleaner suggestion?
> >
> > Drill HAL throughout the entire OS. :)
>
> Yeah, that's the "correct" solution, but until then I imagine you need
> to get real work done :)


Our error log analysis application takes the information prefixed to an error 
message by dev_printk() macros and uses it as a key to query specific device 
information. We are using Martin Schwenke's lsvpd package to get all the 
Vital Product Data (VPD) about a device. His package currently builds a db of 
system devices, pulling information from various places like sysfs and 
sg3_utils, and provides commands for retrieving that information. 

We are working with Martin to increase the usability of lsvpd and its device 
database. Martin plans to hook lsvpd up to hotplug events for adding and 
removing devices. He also plans to store device name information for those 
devices named by udev. Finally, we plan to help him create an API for 
querying device information so we have *one* place to go for getting a 
device's vital data. 

I had originally thought an API would be needed for udev, but it can be done 
outside udev. Udev is for naming certain devices. What we need is an API for 
retrieving information from *all* system devices. 

For more information:

Error Log Analysis: http://evlog.sourceforge.net/ela.html

lsvpd: http://linux-diag.sourceforge.net/Lsvpd.html

Thanks,

Dan


-------------------------------------------------------
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Ìk
_______________________________________________
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 and the kernel's idea of a device

[Greg KH]

On Tue, Apr 06, 2004 at 05:14:33PM -0400, Bill Nottingham wrote:
> Greg KH (greg@kroah.com) said: 
> > > Off the top of my head, iostat, cdrom capability checkers, fbset
> > > and friends, etc. But, in the long run, see below.
> > 
> > But those apps want to know the /dev node, right?
> 
> Well, they want to know the dev node, and they use the device
> as a key to get auxillary information. For example, the framebuffer
> stuff has some limited auxillary information in /proc/fb, there's
> random CD-ROM info in /proc/sys/dev/cdrom/info, etc.

Well the fb stuff should be moving to the sysfs tree someday soon.  As
for the cdrom stuff, ide needs some major sysfs tweaking one of these
days for this very reason.

In the meantime, I don't really have any other suggestions, sorry.

greg k-h


-------------------------------------------------------
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