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] [day] [month] [year] [list]

Message-ID: <20090206230038.166d4f7f@sbs173>
Date:	Fri, 6 Feb 2009 23:00:38 +0100
From:	Harald Braumann <harry@...eit.net>
To:	José Luis Tallón 
	<jltallon@...-solutions.net>
Cc:	debian-devel@...ts.debian.org, linux-kernel@...r.kernel.org
Subject: Re: cgroup mount point

On Thu, 05 Feb 2009 22:19:37 +0100
José Luis Tallón <jltallon@...-solutions.net> wrote:
> [...]
> 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.

Agreed. Semantically /sys is probably the place for cgroups. 

> 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.

Yes, folks have brought forth this technical difficulty and that's why
I initially thought /dev to be a better place.

For me, either would be OK. I don't care that much as long as it's not
mounted in root.

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

Agreed. I think the trend is to remove things not related to processes
from /proc. Of course not everything can be removed immediately, but at
least no new things should be added.

Cheers,
harry

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)