linux-kernel - Re: cgroup mount point

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 Feb 2009 22:19:37 +0100
From:	José Luis Tallón <jltallon@...-solutions.net>
To:	debian-devel@...ts.debian.org
CC:	linux-kernel@...r.kernel.org
Subject: Re: cgroup mount point

Harald Braumann wrote:
> On Tue, 3 Feb 2009 11:14:03 -0800
> Paul Menage <menage@...gle.com> wrote:
>
>   
>> On Tue, Feb 3, 2009 at 10:51 AM, sean finney <seanius@...nius.net>
>> wrote:
>>     
>>> or /proc/bus/usb or /dev/shm or /dev/pts... :)
>>>
>>>       
>> /dev is a bit different though - even if it's mounted as a udev fs,
>> you can create a new directory in there to act as a mount point.
>>     
>
> So, what's the problem with /dev/cgroups then? If shm/ and pts/
> are allowed under /dev, wouldn't it be discriminating against
> cgroups/, to not allow it there?
>   
/dev/pts refers to the virtual pseudo-tty subsystem
    i.e. virtual pseudo-tty devices

/dev/shm refers to the "shared memory" device
    (ok, this is a bit forced)

/dev/log refers to the "log" device
    it could perfectly well be just a file. The fact that it is actually
a socket (more like a pipe to the logging daemon) does not hinder its
equivalence to a logfile.

whereas I can't fathom why a cgroup "feels" like a /device/.

I admit not being an expert in virtualization abstraction (I do run a
significant number of virtual machines, tough), but in fact /sys seems
to be a much better place for it. Please feel free to argue against if
my proposal does not in fact make sense.
While it does indeed feel "hackish", mounting a tmpfs on /sys/cgroups
and then creating as many subdirs as/if necessary is indeed achievable,
practical and flexible.

/proc might be useable though, but it has historically been associated
with "processes" and the information related to them. And yes, that
means that /proc/cpuinfo, /proc/meminfo, and /proc/bus would actually be
out of place there... but keeping backwards compatibility and not
surprising users is most important.

IMHO, other mount points (/var/run/cgroups maybe?) might make sense too.
However the fact that the most common use of cgroup is to split the
system into virtual "partitions" in some way suggests it belongs in /sys.

In any case, I want to show my appreciation and gratitude to all kernel
hackers out there. You're doing a great job, people.

Regards,

    J.L.
--
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/