Re: [PATCH] PPC64 iSeries viodasd proc file

[Jeff Garzik <jgarzik@pobox.com>]

Greg KH wrote:
> On Wed, Jun 23, 2004 at 05:15:54PM -0400, Jeremy Katz wrote:
> 
>>For example, /sys/bus/ide/devices/* and then symlinks forever... lots
>>of readdir, readlink, etc makes probing far slower and more complex
>>than the simple /proc/ide/ide?/*/ that could be used before.
> 
> 
> Yes, ide never got completly moved over to sysfs like scsi did.  We
> never had the time to do this work, sorry.
> 
> But now your parsing should be easier with the one-value to one-file
> rule, right?  And libsysfs should help out here with all of the symlinks
> and readdir, etc calls.
> 
> 
>>>>Also, things in sysfs aren't exactly stable enough to count on as a
>>>>dependable interface, but that's something the kernel has never
>>>>reliably exported to userspace.
>>>
>>>Why isn't sysfs stable enough?  You can find any driver instantly.  And
>>>any device bound to that driver in a stable and repeatable manner.
>>
>>Again, not sysfs itself.  How information is exported via sysfs.  I'm
>>not saying that things exported via /proc are always the picture of
>>stability here (cf the recent change from /proc/scsi/usb-storage-$host
>>to /proc/scsi/usb-storage/$host), but at the same time, things in
>>/proc have tended to settle down in the general case.  This just isn't
>>true yet with sysfs and is only the sort of thing that can happen with
>>time.
>>
>>There are also other things; I guess consistency is a better word. 
>>People like to say use /sys/block to show block devices, but that
>>shows a lot of "useless" block devices from the point of view of
>>trying to show disks.
> 
> 
> But all of those devices are block devices.  You want a hardware
> picture, right?  sysfs never said it would show you just that, but it
> makes it easier to determine.
> 
> For this specific instance, just look for block devices that have a
> device symlink that points to a real device.
> 
> 
>>>So, give me specific examples, or stop ranting for no reason.
>>
>>And to be more constructive (after a discussion with Jeff this
>>afternoon which is when I realized the reply didn't go out), what
>>would be _very_ useful to have from a "probing disks" perspective
>>would be a way to enumerate easily and simply from within sysfs the
>>disks that are associated with a specific controller.
> 
> 
> Hm, I think libsysfs can give you this, if you ask for the block devices
> that are associated with each individual device associated with a
> driver.
> 
> The whole "what driver controls what devices" is not a simple one to one
> mapping all the time, with drivers that work on multiple types of
> busses, and drivers that control devices that contain multiple class
> devices, etc.  It's not a simple thing to solve, sorry.

SET_BLKDEV_DRIVER(), SET_NETDEV_DRIVER(), ...

We need a struct driver just like we have a struct device.

Then binding registered interfaces, of any type, to the driver.


> But what you can use is the MODULE_DEVICE_TABLE() information in the
> modules to try to help you out here.  That details a mapping of what
> kind of devices that specific driver supports.

No, it details what devices a driver supports, not what _type_ of 
devices the driver supports.


>>Note: this should not mean that we then go and remove currently
>>existing stuff in /proc.  Deprecate it and then it can go away in time
>>as people switch.  Having to have a flag day is very painful.  It's
>>far easier to deprecate in one stable series with a new interface
>>available and then start removing the old ones as things start to
>>switch over.  If it really is an improvement, then getting people to
>>change won't be difficult.
> 
> 
> I agree, I don't think that many things have disappeared from /proc just
> yet, right?  You should just have more information than what you
> previously did, right?  Or did scsi drop their /proc support fully?

Concrete example:  modprobe sx8.  Now, what block devices did it detect?

	Jeff