| 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: <6599ad830902030855h1753f4a4o3a303b4dbddf10de@mail.gmail.com> Date: Tue, 3 Feb 2009 08:55:34 -0800 From: Paul Menage <menage@...gle.com> To: Gustavo Noronha <kov@...ian.org> Cc: debian-devel@...ts.debian.org, linux-kernel@...r.kernel.org Subject: Re: cgroup mount point On Tue, Feb 3, 2009 at 6:38 AM, Gustavo Noronha <kov@...ian.org> wrote: > On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote: >> I agree with all that Thadeu Lima says here. I would add that cgroups >> are nothing to do with device nodes, so definitely don't belong in >> '/dev/' either. >> >> Since they're a filesystem mapping "for browsing and manipulation >> from user space" of a kernel facility, I think '/sys/cgroups/' is >> appropriate. > > I agree with this point of view. I believe /sys/cgroups is the way to > go. Now, of course this has the drawback of shadowing something future > versions of Linux would make available at that same path, but I am > pretty sure they would be careful not to do that after distributions > have settled on a standard path. Having one virtual filesystem mounted on top of another virtual filesystem seems like a recipe for problems. /dev/cgroup or /dev/cgroup/<hierarchy_name> sounds more reasonable to me (although if anyone is still using devfs that would suffer from the same drawbacks) Paul -- 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