/sys/block vs. /sys/class/block

/sys/block vs. /sys/class/block

[Benjamin Herrenschmidt]

I'm trying to understand why we have /sys/block instead
of /sys/class/block, and so far, I haven't found a single good argument
justifying it... It just messes up the so far logical layout of sysfs
for no apparent reason.

I also didn't find where /sys/block is created, but that's maybe because
I didn't search too hard :) So I'm not coming up with a patch yet, but
unless somebody can convince me it should stay here, I'll do so soon.

If the reason not to fix it is backward compatibility, then that would
really be a shame we managed already to turn the brand new sysfs into a
mess with no hope of fixing it... If there is really a problem there,
maybe we could move it and keep a compat symlink for a few kernel
revs... ?

Ben.

Re: /sys/block vs. /sys/class/block

[Nick Piggin]

Benjamin Herrenschmidt wrote:
> I'm trying to understand why we have /sys/block instead
> of /sys/class/block, and so far, I haven't found a single good argument
> justifying it... It just messes up the so far logical layout of sysfs
> for no apparent reason.
> 
> I also didn't find where /sys/block is created, but that's maybe because
> I didn't search too hard :) So I'm not coming up with a patch yet, but
> unless somebody can convince me it should stay here, I'll do so soon.
> 
> If the reason not to fix it is backward compatibility, then that would
> really be a shame we managed already to turn the brand new sysfs into a
> mess with no hope of fixing it... If there is really a problem there,
> maybe we could move it and keep a compat symlink for a few kernel
> revs... ?
> 

Seems like that's where it belongs.

The reason why it is in /sys/block is because it is apparently a "subsystem",
and using decl_subsys - drivers/block/genhd.c

Nick

Re: /sys/block vs. /sys/class/block

[Benjamin Herrenschmidt]

> Seems like that's where it belongs.
> 
> The reason why it is in /sys/block is because it is apparently a "subsystem",
> and using decl_subsys - drivers/block/genhd.c

I'm not convinced ... If you look at how /sys is organized, it really
doesn't make any sense ... block devives are really devices of "class
block", wether we have a block "subsystem" in there is irrelevant imho.

Ben.

Re: /sys/block vs. /sys/class/block

[Nick Piggin]

Benjamin Herrenschmidt wrote:
>>Seems like that's where it belongs.
>>
>>The reason why it is in /sys/block is because it is apparently a "subsystem",
>>and using decl_subsys - drivers/block/genhd.c
> 
> 
> I'm not convinced ... If you look at how /sys is organized, it really
> doesn't make any sense ... block devives are really devices of "class
> block", wether we have a block "subsystem" in there is irrelevant imho.
> 

Sorry to be unclear: I was agreeing with you ;)

I was just pointing out that the reason it is currently /sys/block is
that decl_subsys call.

Re: /sys/block vs. /sys/class/block

[Jens Axboe]

On Mon, Dec 20 2004, Nick Piggin wrote:
> Benjamin Herrenschmidt wrote:
> >>Seems like that's where it belongs.
> >>
> >>The reason why it is in /sys/block is because it is apparently a 
> >>"subsystem",
> >>and using decl_subsys - drivers/block/genhd.c
> >
> >
> >I'm not convinced ... If you look at how /sys is organized, it really
> >doesn't make any sense ... block devives are really devices of "class
> >block", wether we have a block "subsystem" in there is irrelevant imho.
> >
> 
> Sorry to be unclear: I was agreeing with you ;)
> 
> I was just pointing out that the reason it is currently /sys/block is
> that decl_subsys call.

Ditto, the question is how to move it with as little pain as possible...
I think the symlink approach would be fine.

-- 
Jens Axboe

Re: /sys/block vs. /sys/class/block

[Jan Engelhardt]

>Ditto, the question is how to move it with as little pain as possible...
>I think the symlink approach would be fine.

Wow.. I don't even have /sys/class/block (2.6.9-rc2)



Jan Engelhardt
-- 
ENOSPC

Re: /sys/block vs. /sys/class/block

[Jens Axboe]

(please follow list etiquette, don't trim cc lists)

On Mon, Dec 20 2004, Jan Engelhardt wrote:
> >Ditto, the question is how to move it with as little pain as possible...
> >I think the symlink approach would be fine.
> 
> Wow.. I don't even have /sys/class/block (2.6.9-rc2)

That is Ben's point, it is currently misplaced.

-- 
Jens Axboe

Re: /sys/block vs. /sys/class/block

[Greg KH]

On Mon, Dec 20, 2004 at 08:08:52AM +0100, Benjamin Herrenschmidt wrote:
> I'm trying to understand why we have /sys/block instead
> of /sys/class/block, and so far, I haven't found a single good argument
> justifying it... It just messes up the so far logical layout of sysfs
> for no apparent reason.

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.

thanks,

greg k-h

Re: /sys/block vs. /sys/class/block

[Benjamin Herrenschmidt]

On Mon, 2004-12-20 at 14:49 -0800, Greg KH wrote:
> On Mon, Dec 20, 2004 at 08:08:52AM +0100, Benjamin Herrenschmidt wrote:
> > I'm trying to understand why we have /sys/block instead
> > of /sys/class/block, and so far, I haven't found a single good argument
> > justifying it... It just messes up the so far logical layout of sysfs
> > for no apparent reason.
> 
> 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 ?

Ben.

Re: /sys/block vs. /sys/class/block

[Daniel Stekloff]

On Mon, 2004-12-20 at 23:07, Benjamin Herrenschmidt wrote:
> On Mon, 2004-12-20 at 14:49 -0800, Greg KH wrote:
> > On Mon, Dec 20, 2004 at 08:08:52AM +0100, Benjamin Herrenschmidt wrote:
> > > I'm trying to understand why we have /sys/block instead
> > > of /sys/class/block, and so far, I haven't found a single good argument
> > > justifying it... It just messes up the so far logical layout of sysfs
> > > for no apparent reason.
> > 
> > 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 ?


Just as a note, libsysfs treats /sys/block as a class, as if under
/sys/class. We felt that's where it belonged and that's where it will
end up.... eventually.

Thanks,

Dan

Re: /sys/block vs. /sys/class/block

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

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? :-)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: /sys/block vs. /sys/class/block

[Greg KH]

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

Re: /sys/block vs. /sys/class/block

[David Weinehall]

On Tue, Dec 21, 2004 at 10:20:57PM -0800, Greg KH wrote:

[snip]

> It is gross.

Indeed.

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

Maybe because *for once* it'd be nice to actually have inconsistencies
gotten rid of in their relative infancy instead of waiting 10 years
and then having to explain them as existing only for hysterical
raisins...

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: /sys/block vs. /sys/class/block

[Benjamin Herrenschmidt]

> > 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.
> 
> Maybe because *for once* it'd be nice to actually have inconsistencies
> gotten rid of in their relative infancy instead of waiting 10 years
> and then having to explain them as existing only for hysterical
> raisins...

Agreed.

Ben.

Re: /sys/block vs. /sys/class/block

[Greg KH]

On Thu, Dec 23, 2004 at 07:55:33AM +0100, Benjamin Herrenschmidt wrote:
> 
> > > 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.
> > 
> > Maybe because *for once* it'd be nice to actually have inconsistencies
> > gotten rid of in their relative infancy instead of waiting 10 years
> > and then having to explain them as existing only for hysterical
> > raisins...
> 
> Agreed.

-ENOPATCH  :)