Re: [PATCH] PPC64 iSeries viodasd proc file

[Jeremy]

On Fri, 18 Jun 2004 16:17:53 +0100, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Fri, Jun 18, 2004 at 11:09:40AM -0400, Jeff Garzik wrote:
> > Stephen Rothwell wrote:
> > >This patch adds a proc file for viodasd so to make it
> > >easier to enumerate the available disks.  It is in a
> > >(somewhat) strange format to try for a simple level of
> > >compatability with the old viodasd code (that was in a
> > >couple of vendor's kernels).
> > 
> > Exporting redundant information from procfs is a step backwards, since
> > we have sysfs.
> >
> > I would prefer not to apply this.  Upstream is for 'getting it right',
> > not for dragging every little vendor kernel hack along.

It was in the tree for the platform, not just vendor trees.  ie,
anyone who wanted to use the platform with Linux would have had this
functionality.  If you'd argue that people shouldn't do that, then how
are platforms supposed to get to a point where they can be included in
the mainline tree?

Also, it's exactly the sort of thing that would have been accepted in
2.4 if the platform had tried to get included there.  So this is a bit
of bogus reasoning.  eg, if there was an attempt to include iSeries in
the 2.4 series now (or a year ago, when it might have been more
reasonable), this would have gone in.  It's an interface that users of
the platform have come to depend on, for better or for worse.

And the information is hardly redundant when the same information
isn't really available in /sys at present.  And before it's mentioned,
/sys/block isn't the same information.

> 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.  The mess of
symlinks present there is a disaster and disgusting for anyone who
wants to actually write clean probing code.    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.

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/