From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 28 Apr 2005 14:43:40 +0000 Subject: Re: udev & kernel names Message-Id: <1114699420.4212.20.camel@localhost.localdomain> List-Id: References: <20050426231516.GD2740@us.ibm.com> In-Reply-To: <20050426231516.GD2740@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 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?id5hix _______________________________________________ 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