Re: [PATCH] PPC64 iSeries viodasd proc file
From: Jeff Garzik
Date: Wed Jun 23 2004 - 19:39:30 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/