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
| ||
|
Message-Id: <200710251231.07185.nickpiggin@yahoo.com.au> Date: Thu, 25 Oct 2007 12:31:06 +1000 From: Nick Piggin <nickpiggin@...oo.com.au> To: "Kay Sievers" <kay.sievers@...y.org> Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, "Takenori Nagano" <t-nagano@...jp.nec.com>, "Greg KH" <greg@...ah.com> Subject: Re: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2) On Wednesday 24 October 2007 21:12, Kay Sievers wrote: > On 10/24/07, Nick Piggin <nickpiggin@...oo.com.au> wrote: > > On Tuesday 23 October 2007 10:55, Takenori Nagano wrote: > > > Nick Piggin wrote: > > > > One thing I'd suggest is not to use debugfs, if it is going to > > > > be a useful end-user feature. > > > > > > Is /sys/kernel/notifier_name/ an appropriate place? > > > > I'm curious about the /sys/kernel/ namespace. I had presumed that > > it is intended to replace /proc/sys/ basically with the same > > functionality. > > 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). > > I _assume_ these are system software stats and > > tunables that are not exactly linked to device drivers (OTOH, > > where do you draw the line? eg. Would filesystems go here? > > We already have /sys/fs/ ? > > > Core network algorithm tunables might, but per interface ones probably > > not...). > > We will merge the nonsense of "block/", "class/" and "bus/" to one > "subsystem". The block, class, bus directories will only be kept as > symlinks for compatibility. Then every subsystem has a directory like: > /sys/subsystem/block/, /sys/subsystem/net/ and the devices of the > subsystem are in a devices/ directory below that. Just like the > /sys/bus/< name>/devices/ layout looks today. All subsystem-global > tunables can go below the /sys/subsystem/<name>/ directory, without > clashing with the list of devices or anything else. Makes sense. > > I don't know. Is there guidelines for sysfs (and procfs for that > > matter)? Is anyone maintaining it (not the infrastructure, but > > the actual content)? > > Unfortunately, there was never really a guideline. > > > It's kind of ironic that /proc/sys/ looks like one of the best > > organised directories in proc, while /sys/kernel seems to be in > > danger of becoming a mess: it has kexec and uevent files in the > > base directory, rather than in subdirectories... > > True, just looking at it now, people do crazy things like: > /sys/kernel/notes, which is a file with binary content, and a name > nobody will ever be able to guess what it is good for. That should > definitely go into a section/ directory. Also the VM stuff there > should probably move to a /sys/vm/ directory along with the weird > placed top-level /sys/slab/. Top level directory IMO should be kept as sparse as possible. If you agree to /sys/mm for example, that's fine, but then slab should go under that. (I'd prefer all to go underneath /sys/kernel, but...). 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). For that matter, this should be the case for *all* userspace API changes (kernel-user-api@...r.kernel.org?) - 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