Re: [PATCH] PPC64 iSeries viodasd proc file

[Greg KH]

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.

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.

> 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?

thanks,

greg k-h
-
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/