dev_printk output

dev_printk output

[Matthew Wilcox]

On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
> Funky how loading sd after sg changes the output ... and using the driver
> name as a prefix sometimes messes this up for scsi.
> 
> i.e. scan without sd_mod or sg loaded (and distro I'm using loads sg
> before sd_mod via udev rules):
> 
>  0:0:0:0: Attached scsi generic sg0 type 0
>  0:0:0:1: Attached scsi generic sg1 type 0
> 
> Then remove/add those devices, and sg lines become:
> 
> sd 1:0:0:0: Attached scsi generic sg0 type 0
> sd 1:0:0:1: Attached scsi generic sg1 type 0

I find that a bit confusing too.  Obviously, we should distinguish
different kinds of bus_id from each other somehow -- but isn't the
obvious thing to use the bus name?  That must already be unique as sysfs
relies on it.  ie this patch:

(seems that dev->bus isn't always set; I got a null ptr dereference when
booting without that check).

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

Index: include/linux/device.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/linux/device.h,v
retrieving revision 1.25
diff -u -p -r1.25 device.h
--- include/linux/device.h	13 May 2006 04:12:30 -0000	1.25
+++ include/linux/device.h	19 May 2006 19:54:04 -0000
@@ -412,7 +412,7 @@ extern void firmware_unregister(struct s
 
 /* debugging and troubleshooting/diagnostic helpers. */
 #define dev_printk(level, dev, format, arg...)	\
-	printk(level "%s %s: " format , (dev)->driver ? (dev)->driver->name : "" , (dev)->bus_id , ## arg)
+	printk(level "%s %s: " format , (dev)->bus ? (dev)->bus->name : "", (dev)->bus_id , ## arg)
 
 #ifdef DEBUG
 #define dev_dbg(dev, format, arg...)		\

Re: dev_printk output

[Greg KH]

On Fri, May 19, 2006 at 02:11:42PM -0600, Matthew Wilcox wrote:
> On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
> > Funky how loading sd after sg changes the output ... and using the driver
> > name as a prefix sometimes messes this up for scsi.
> > 
> > i.e. scan without sd_mod or sg loaded (and distro I'm using loads sg
> > before sd_mod via udev rules):
> > 
> >  0:0:0:0: Attached scsi generic sg0 type 0
> >  0:0:0:1: Attached scsi generic sg1 type 0
> > 
> > Then remove/add those devices, and sg lines become:
> > 
> > sd 1:0:0:0: Attached scsi generic sg0 type 0
> > sd 1:0:0:1: Attached scsi generic sg1 type 0
> 
> I find that a bit confusing too.  Obviously, we should distinguish
> different kinds of bus_id from each other somehow -- but isn't the
> obvious thing to use the bus name?  That must already be unique as sysfs
> relies on it.  ie this patch:
> 
> (seems that dev->bus isn't always set; I got a null ptr dereference when
> booting without that check).

Yes, not all devices are on a bus, so this will not work.  And we want
to know the driver that controls the device too.  So how about adding
the bus if it's not null?

Something like (untested):
	printk(level "%s %s %s: " format , (dev)->bus ? (dev)->bus->name : "", (dev)->driver ? (dev)->driver->name : "", (dev)->bus_id , ## arg)

thanks,

greg k-h

Re: dev_printk output

[Matthew Wilcox]

On Fri, May 19, 2006 at 01:28:47PM -0700, Greg KH wrote:
> On Fri, May 19, 2006 at 02:11:42PM -0600, Matthew Wilcox wrote:
> > On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
> > > Funky how loading sd after sg changes the output ... and using the driver
> > > name as a prefix sometimes messes this up for scsi.
> > > 
> > >  0:0:0:0: Attached scsi generic sg0 type 0
> > > sd 1:0:0:0: Attached scsi generic sg0 type 0
> > 
> > I find that a bit confusing too.  Obviously, we should distinguish
> > different kinds of bus_id from each other somehow -- but isn't the
> > obvious thing to use the bus name?  That must already be unique as sysfs
> > relies on it.  ie this patch:
> 
> Yes, not all devices are on a bus, so this will not work.  And we want
> to know the driver that controls the device too.  So how about adding
> the bus if it's not null?
> 
> Something like (untested):
> 	printk(level "%s %s %s: " format , (dev)->bus ? (dev)->bus->name : "", (dev)->driver ? (dev)->driver->name : "", (dev)->bus_id , ## arg)

Then we still get the inconsistency of device names changing as drivers
are loaded.  I think we should declare it a bug for devices to not be
on a bus.  The only example I have of devices not-on-a-bus are scsi
targets.  I would propose introducing a new scsi_target bus for them,
then removing the 'target' from the start of the bus_id.  Adding them to
the scsi bus looks like it'd be a lot of work.

Re: dev_printk output

[James Bottomley]

On Fri, 2006-05-19 at 22:55 -0600, Matthew Wilcox wrote:
> Then we still get the inconsistency of device names changing as
> drivers
> are loaded.  I think we should declare it a bug for devices to not be
> on a bus.  The only example I have of devices not-on-a-bus are scsi
> targets.  I would propose introducing a new scsi_target bus for them,
> then removing the 'target' from the start of the bus_id.  Adding them
> to
> the scsi bus looks like it'd be a lot of work.

It's not just the target.  All the intermediate devices in transport
classes don't have busses either.   The only reason scsi_device has a
bus is so we can use the driver model to bind the ULDs.

James

Re: dev_printk output

[Greg KH]

On Fri, May 19, 2006 at 10:55:44PM -0600, Matthew Wilcox wrote:
> On Fri, May 19, 2006 at 01:28:47PM -0700, Greg KH wrote:
> > On Fri, May 19, 2006 at 02:11:42PM -0600, Matthew Wilcox wrote:
> > > On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
> > > > Funky how loading sd after sg changes the output ... and using the driver
> > > > name as a prefix sometimes messes this up for scsi.
> > > > 
> > > >  0:0:0:0: Attached scsi generic sg0 type 0
> > > > sd 1:0:0:0: Attached scsi generic sg0 type 0
> > > 
> > > I find that a bit confusing too.  Obviously, we should distinguish
> > > different kinds of bus_id from each other somehow -- but isn't the
> > > obvious thing to use the bus name?  That must already be unique as sysfs
> > > relies on it.  ie this patch:
> > 
> > Yes, not all devices are on a bus, so this will not work.  And we want
> > to know the driver that controls the device too.  So how about adding
> > the bus if it's not null?
> > 
> > Something like (untested):
> > 	printk(level "%s %s %s: " format , (dev)->bus ? (dev)->bus->name : "", (dev)->driver ? (dev)->driver->name : "", (dev)->bus_id , ## arg)
> 
> Then we still get the inconsistency of device names changing as drivers
> are loaded.

The bus id doesn't change, just the "hint" as to who is controling it at
that point in time.  Which is something that is needed/wanted by a lot
of people.

> I think we should declare it a bug for devices to not be on a bus.

No!  We have a few places already that are devices with no related bus,
and are only getting more and more with the shift away from class_device
to device (see a patch in my quilt tree that allows this.)

thanks,

greg k-h

Re: dev_printk output

[Matthew Wilcox]

On Sat, May 20, 2006 at 02:21:35PM -0700, Greg KH wrote:
> On Fri, May 19, 2006 at 10:55:44PM -0600, Matthew Wilcox wrote:
> > On Fri, May 19, 2006 at 01:28:47PM -0700, Greg KH wrote:
> > > On Fri, May 19, 2006 at 02:11:42PM -0600, Matthew Wilcox wrote:
> > > > On Thu, May 18, 2006 at 01:09:57PM -0700, Patrick Mansfield wrote:
> > > > > Funky how loading sd after sg changes the output ... and using the driver
> > > > > name as a prefix sometimes messes this up for scsi.
> > > > > 
> > > > >  0:0:0:0: Attached scsi generic sg0 type 0
> > > > > sd 1:0:0:0: Attached scsi generic sg0 type 0
> > > 
> > > Something like (untested):
> > > 	printk(level "%s %s %s: " format , (dev)->bus ? (dev)->bus->name : "", (dev)->driver ? (dev)->driver->name : "", (dev)->bus_id , ## arg)
> > 
> > Then we still get the inconsistency of device names changing as drivers
> > are loaded.
> 
> The bus id doesn't change, just the "hint" as to who is controling it at
> that point in time.  Which is something that is needed/wanted by a lot
> of people.

Sure, but it's also unwanted by others ;-)  There's no reason we have to
have a 'one size fits all' solution.  Let's add a dev_bus_printk() (or
maybe just bus_printk()?) that does
	printk(level "%s %s: " format , (dev)->bus ? (dev)->bus->name : "", \
		(dev)->bus_id , ## arg)

or we could rename the current dev_printk() implementation to drv_printk()
and have dev_printk() do the above.  or we could do something like:

#define DEV_DRV(dev)	(dev)->driver ? (dev)->driver->name : ""
#define DEV_BUS(dev)	(dev)->bus ? (dev)->bus->name : ""
#define dev_printk(level, dev, format, arg...)  \
	printk(level "%s %s: " format, DEV_BUS(dev), (dev)->bus_id , ## arg)
#define drv_printk(level, dev, format, arg...)  \
	printk(level "%s %s %s: " format, DEV_DRV(dev), DEV_BUS(dev), \
		(dev)->bus_id , ## arg)

Obviously, we could argue about the exact naming until the cows come home, 
so let me say that I don't really care.  I just want something that
looks like "scsi 0:0:0:0" rather than "sd 0:0:0:0" or " 0:0:0:0",
depending on whether sd has been loaded or not.

If you're still reluctant, think about it this way.  There are bits of
the kernel which need to tell the user about a device that may, or may
not have a driver attached.  The scsi midlayer is one, and I'm sure
there are others.

Re: dev_printk output

[James Bottomley]

On Sun, 2006-05-28 at 21:57 -0600, Matthew Wilcox wrote:
> Obviously, we could argue about the exact naming until the cows come
> home, 
> so let me say that I don't really care.  I just want something that
> looks like "scsi 0:0:0:0" rather than "sd 0:0:0:0" or " 0:0:0:0",
> depending on whether sd has been loaded or not.

If we follow the recommendations of the storage summit, we'll have to
trash the scsi bus type to get ata an upper level driver, so even this
will eventually no longer print what you want ...

James