Re: [PATCH] PPC64 iSeries viodasd proc file

[Jeremy Katz]

Oops, I can't use gmail and sent this just to Greg originally...  Greg
-- I've added a little bit more from my original mail

On Sun, 20 Jun 2004 23:04:35 -0700, Greg KH <greg@xxxxxxxxx> wrote:
> On Sun, Jun 20, 2004 at 03:52:33PM -0400, Jeremy wrote:
> > > Agreed.  And the old viodasd reason was rejected exactly because it was
> > > such a f***ing mess.
> >
> > The argument could be made that sysfs is similarly a f***ing mess and
> > that instead of solving problems, it creates more.
>
> It does?  Have you brought this up to the sysfs / kobject / driver model
> authors?  I think they would be open to any critiques of the current
> code, especially if such critique contains patches.

My argument isn't around the code... I haven't looked at it enough to
say one way or another.  Although it does seem to duplicate plenty of
things that were available before and then drivers start to drop
random bits that other people depended on being in /proc with the
"well, it should be in sysfs now" argument.  Unfortunately, it wasn't
a clean break and instead it's a very meandering migration.  Which
makes things a bit more difficult to deal with.

> > The mess of symlinks present there is a disaster and disgusting for
> > anyone who wants to actually write clean probing code.
>
> What do you mean by this.  Any examples?

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.

> > 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.  Block devices also ends up including things
like loop devs (which are all always there), ramdisks, nbd and
probably other things I'm not thinking of.  There's also some
variation in what drivers show -- eg, iseries!vda vs carmel_0 for
device names...  the directory separator used being different points
at how there's a bit of ad-hocness to it.

> 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.  Not entirely
sure where under sysfs this would go, but to be able to easily see
that for block device type foo, I have disks disk0, disk1 and disk2. 
The vio sysfs stuff actually works kind of nicely like this, but it
would be more useful as a generic thing rather than not being able to
depend on it.

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.

Jeremy
-
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/