From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Stekloff Date: Tue, 06 Apr 2004 21:43:09 +0000 Subject: Re: udev and the kernel's idea of a device Message-Id: <200404061443.09474.dsteklof@us.ibm.com> List-Id: References: <20040406192223.GA4853@nostromo.devel.redhat.com> In-Reply-To: <20040406192223.GA4853@nostromo.devel.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org 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 err= or=20 message by dev_printk() macros and uses it as a key to query specific devic= e=20 information. We are using Martin Schwenke's lsvpd package to get all the=20 Vital Product Data (VPD) about a device. His package currently builds a db = of=20 system devices, pulling information from various places like sysfs and=20 sg3_utils, and provides commands for retrieving that information.=20 We are working with Martin to increase the usability of lsvpd and its devic= e=20 database. Martin plans to hook lsvpd up to hotplug events for adding and=20 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=20 querying device information so we have *one* place to go for getting a=20 device's vital data.=20 I had originally thought an API would be needed for udev, but it can be don= e=20 outside udev. Udev is for naming certain devices. What we need is an API fo= r=20 retrieving information from *all* system devices.=20 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=1470&alloc_id638&op=CCk _______________________________________________ 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