lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 25 Oct 2007 16:12:04 +1000 From: Nick Piggin <nickpiggin@...oo.com.au> To: Greg KH <greg@...ah.com> Cc: Kay Sievers <kay.sievers@...y.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Takenori Nagano <t-nagano@...jp.nec.com> Subject: Re: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2) 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@...oo.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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists