(Adding vger to Cc: list, so as to spread the joy around.)
On Thu, 7 Jul 2005, Greg KH wrote:
> >
> > Moving the individual bond directories to a bonds/ directory
> > is problematic. Because each bond shows up a just another network
> > interface, they show up in /sys/class/net automatically. We'd have to
> > make a bunch of changes to the device model to account for bonding, and
> > we'd break the semantics of the /sys/class/net hierarchy.
>
> Why not just put them in /sys/class/bond/ instead?
As Aaron Brown noted in another reply, it's inappropriate for bonding to
do this. Bonding is really just another network driver, and its
interfaces show up in /sys/class/net courtesy of the device model. We
don't need to replicate this capability; we just need to extend it a bit.
Adding /sys/class/bond/ would cause a much larger protest that what we're
dealing with now (i.e. pretty much only you).
> > reading of Documentation/filesystems/sysfs.txt indicates that such a usage
> > is "socially acceptable". (Or at least it was to Patrick Mochel back in
> > January of 2003.)
>
> Pat was just trying to be nice. I'm not. :)
Well, if "nice" isn't the policy any more, then the doc needs to change.
> Just don't make them readable. Lots of sysfs files are write only.
OK, you got me there. I did some poking and you are absolutely correct.
However, I did a little more poking, and found a bunch of files that have
more than one item in them. HW resource listings, block device scheduling
stuff, plenty of examples. Are they socially acceptable?
> > bonding_masters. This currently is a problem, since sysfs itself does not
> > handle appends properly.
>
> Because you are not supposed to do that.
Sysfs will happily accept O_APPEND opens, and will happily report success
on seek attempts, although neither operation is permitted. Whether or not
you're supposed to, this behavior is just plain wrong.
|