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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ