Harald Braumann wrote:
> On Tue, 3 Feb 2009 11:14:03 -0800
> Paul Menage <men...@google.com> wrote:
>
>
>> On Tue, Feb 3, 2009 at 10:51 AM, sean finney <sean...@seanius.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, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
