* dev_printk output [not found] ` <20060518200957.GA29200@us.ibm.com> @ 2006-05-19 20:11 ` Matthew Wilcox 2006-05-19 20:28 ` Greg KH 0 siblings, 1 reply; 7+ messages in thread From: Matthew Wilcox @ 2006-05-19 20:11 UTC (permalink / raw) To: Patrick Mansfield; +Cc: linux-scsi, Greg KH, linux-kernel 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...) \ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-19 20:11 ` dev_printk output Matthew Wilcox @ 2006-05-19 20:28 ` Greg KH 2006-05-20 4:55 ` Matthew Wilcox 0 siblings, 1 reply; 7+ messages in thread From: Greg KH @ 2006-05-19 20:28 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Patrick Mansfield, linux-scsi, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-19 20:28 ` Greg KH @ 2006-05-20 4:55 ` Matthew Wilcox 2006-05-20 13:46 ` James Bottomley 2006-05-20 21:21 ` Greg KH 0 siblings, 2 replies; 7+ messages in thread From: Matthew Wilcox @ 2006-05-20 4:55 UTC (permalink / raw) To: Greg KH; +Cc: Patrick Mansfield, linux-scsi, linux-kernel 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-20 4:55 ` Matthew Wilcox @ 2006-05-20 13:46 ` James Bottomley 2006-05-20 21:21 ` Greg KH 1 sibling, 0 replies; 7+ messages in thread From: James Bottomley @ 2006-05-20 13:46 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Greg KH, Patrick Mansfield, linux-scsi, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-20 4:55 ` Matthew Wilcox 2006-05-20 13:46 ` James Bottomley @ 2006-05-20 21:21 ` Greg KH 2006-05-29 3:57 ` Matthew Wilcox 1 sibling, 1 reply; 7+ messages in thread From: Greg KH @ 2006-05-20 21:21 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Patrick Mansfield, linux-scsi, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-20 21:21 ` Greg KH @ 2006-05-29 3:57 ` Matthew Wilcox 2006-05-29 16:30 ` James Bottomley 0 siblings, 1 reply; 7+ messages in thread From: Matthew Wilcox @ 2006-05-29 3:57 UTC (permalink / raw) To: Greg KH; +Cc: Patrick Mansfield, linux-scsi, linux-kernel 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dev_printk output 2006-05-29 3:57 ` Matthew Wilcox @ 2006-05-29 16:30 ` James Bottomley 0 siblings, 0 replies; 7+ messages in thread From: James Bottomley @ 2006-05-29 16:30 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Greg KH, Patrick Mansfield, linux-scsi, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-05-29 16:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060511150015.GJ12272@parisc-linux.org>
[not found] ` <20060512170854.GA11215@us.ibm.com>
[not found] ` <20060513050059.GR12272@parisc-linux.org>
[not found] ` <20060518183652.GM1604@parisc-linux.org>
[not found] ` <20060518200957.GA29200@us.ibm.com>
2006-05-19 20:11 ` dev_printk output Matthew Wilcox
2006-05-19 20:28 ` Greg KH
2006-05-20 4:55 ` Matthew Wilcox
2006-05-20 13:46 ` James Bottomley
2006-05-20 21:21 ` Greg KH
2006-05-29 3:57 ` Matthew Wilcox
2006-05-29 16:30 ` James Bottomley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox