From: Greg KH <greg@kroah.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-kernel@vger.kernel.org, mochel@digitalimplant.org,
axboe@suse.de
Subject: Re: /sys/block vs. /sys/class/block
Date: Tue, 21 Dec 2004 22:20:57 -0800 [thread overview]
Message-ID: <20041222062057.GC31513@kroah.com> (raw)
In-Reply-To: <20041222153449.46da0671.sfr@canb.auug.org.au>
On Wed, Dec 22, 2004 at 03:34:49PM +1100, Stephen Rothwell wrote:
> On Tue, 21 Dec 2004 08:07:50 +0100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > Because /sys/block happened before /sys/class did. Al Viro converted
> > > the block layer before I got the struct class stuff working properly
> > > during 2.5.
> > >
> > > And yes, I would like to convert the block layer to use the class stuff,
> > > but for right now, I can't as class devices don't allow
> > > sub-classes-devices, and getting to that work is _way_ down on my list
> > > of things to do.
> >
> > but can't we at least artificially move it down to /sys/class anyway for
> > the sake of a sane userland API ?
>
> Can I then make the obvious suggestion: add a symlink in /sys/class
> linking to /sys/block and then reverse the symink once the above work has
> been done and /sys/class/block has been created?
>
> Or is that too gross? :-)
It is gross.
But I guess I should ask, who really cares about this, so late in the
sysfs structure game? Is /sys/block/ really a big problem for anyone?
And if it is, I'd much rather someone make the required driver core
changes to fix this up properly, than just put a symlink to paper over
some userspace issue.
And as Dan said, libsysfs already handles /sys/block just like any other
class structure, so a "sane" userland API already exists that fixes this
issue for you.
thanks,
greg k-h
next prev parent reply other threads:[~2004-12-22 6:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-20 7:08 /sys/block vs. /sys/class/block Benjamin Herrenschmidt
2004-12-20 8:16 ` Nick Piggin
2004-12-20 9:29 ` Benjamin Herrenschmidt
2004-12-20 9:44 ` Nick Piggin
2004-12-20 9:45 ` Jens Axboe
2004-12-20 11:37 ` Jan Engelhardt
2004-12-20 14:08 ` Jens Axboe
2004-12-20 22:49 ` Greg KH
2004-12-21 7:07 ` Benjamin Herrenschmidt
2004-12-22 2:34 ` Daniel Stekloff
2004-12-22 4:34 ` Stephen Rothwell
2004-12-22 6:20 ` Greg KH [this message]
2004-12-23 6:39 ` David Weinehall
2004-12-23 6:55 ` Benjamin Herrenschmidt
2005-01-06 23:14 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041222062057.GC31513@kroah.com \
--to=greg@kroah.com \
--cc=axboe@suse.de \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.