On 10/24/07, Nick Piggin <[EMAIL PROTECTED]> 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. > 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. > 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/. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/