Messages in this thread | | | From | Nick Piggin <> | Subject | Re: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2) | Date | Thu, 25 Oct 2007 16:12:04 +1000 |
| |
On Thursday 25 October 2007 15:45, Greg KH wrote: > On Thu, Oct 25, 2007 at 12:31:06PM +1000, Nick Piggin wrote: > > On Wednesday 24 October 2007 21:12, Kay Sievers wrote: > > > On 10/24/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > > It was intended to be something like /proc/sys/kernel/ only. > > > > Really? So you'd be happy to have a /sys/dev /sys/fs /sys/kernel > > /sys/net /sys/vm etc? "kernel" to me shouldn't really imply the > > stuff under the kernel/ source directory or other random stuff > > that doesn't fit into another directory, but attributes that are > > directly related to the kernel software (rather than directly > > associated with any device). > > What would you want in /sys/net and /sys/dev and /sys/vm? I don't mind > putting subdirs in /sys/kernel/ if you want it.
I guess potentially things that are today in /proc/sys/*. Sysfs is much closer to the "right" place for this kind of attributes than procfs, isn't it?
> > It would be nice to get a sysfs content maintainer or two. Just > > having new additions occasionally reviewed along with the rest of > > a patch, by random people, doesn't really aid consistency. Would it > > be much trouble to ask that _all_ additions to sysfs be accompanied > > by notification to this maintainer, along with a few line description? > > (then merge would require SOB from said maintainer). > > No, I would _love_ that. We should make the requirement that all new > sysfs files be documented in Documentation/API/ like that details.
Obviously I'm for that too. A mandatory cc to a linux-abi list, documentation, and an acked-by from the relevant API maintainers, etc. All it needs is upstream to agree and sometime to implement it.
> I'll be glad to review it, but as it's pretty trivial to add sysfs > files, everyone ends up doing it :)
If it fits with the overall direction that yourself / Kay / everyone else has in mind, then yes. Problem is that if this stuff goes unreviewed, or reviewed by different people who don't have a coherent idea of what the API should look like, then it ends in a mess that you can't fix easily. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |