Not logged in
Log in now
Create an account
Subscribe to LWN
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
There is kernel space and there is user space.
The kernel exports a feature called cgroups and this is found useful and used in user space.
It is of absolutely no consequence whether the kernel code is ugly, pretty, has a nicely proportioned ankle or is downright gorgeous. It has an interface, and that is what is used.
To denigrate a user space system by arguing that the kernel implementation that it relies on is flawed is ludicrous to the point of disbelief.
Debian debates systemd
Posted Jul 31, 2011 0:50 UTC (Sun) by viro (subscriber, #7872)
I don't give a rat's arse for denigrating or lauding systemd, its author or its fanboys (OK, beyond the usual allergy to fanboys of any persuasuion). The trouble with systemd is as pragmatic as it gets - due to architecture decision by systemd author(s), running it means that several really badly-written pieces of code will be executed in kernel mode all the time. It doesn't matter how the blame is to be distributed - I simply don't care. Not interesting. It's not about judging Lennart (FWIW, my opinion is simple - (a) obnoxious luser; (b) not my luser, thanks $DEITY), it's not about something systemd might "deserve". The only thing I do care about in that story is what code ends up running on my boxen and what can I do about that.
Posted Jul 31, 2011 11:59 UTC (Sun) by anselm (subscriber, #2796)
It isn't quite clear to me whether you have a problem with the idea of cgroups in principle, or with the current implementation of cgroups.
If it's the latter, then with all possible respect why is committing to producing your own distribution (if only for your own personal use) for the indefinite future a better course of action than (contributing to) cleaning up or replacing the current cgroups implementation and being done with the issue? If nothing else it would be good for the Linux community at large, either by improving a feature that many people want to use (even though it is implemented badly), or else by making a feature that some people don't want to use (because it is implemented badly) more acceptable.
Also, many other parts of the kernel are »optional« in the sense that there is a switch in the config file that would make them disappear, but that doesn't mean it's a good idea to do so. Some of these might even be badly implemented (I'm not a kernel hacker, so probably wouldn't be able to tell), or might have been badly implemented when they were new and have since been cleaned up. If people are not supposed to make use of »optional« kernel features because they're, well, optional, why offer them in the first place?
Posted Jul 31, 2011 14:27 UTC (Sun) by riel (subscriber, #3142)
This is a serious lack of robustness for something that's supposed to replace /sbin/init...
Posted Jul 31, 2011 15:52 UTC (Sun) by anselm (subscriber, #2796)
The traditional SysV init itself can fail in all sorts of interesting ways if its components aren't in the correct place or otherwise broken. Most distributions have figured out by now that depending on bash-specific stuff in »#!/bin/sh« scripts called during the init process is a bad idea if people install a different (POSIX-compatible) shell as /bin/sh, but it was not an obvious thing at the time. Personally I wouldn't look to SysV init as a paragon of robustness.
OTOH, it is reasonable to assume that distributions that come with systemd as the default init subsystem will make sure that the kernels provided with the distribution have the necessary features enabled. This is no more or less reasonable than to assume that distributions that come with a DHCP client have networking enabled in the kernel. It is also reasonable to assume that people who insist on tweaking their kernels will leave cgroups etc. in if they expect to use systemd, much like they will leave networking in if they expect to use TCP/IP.
Posted Jul 31, 2011 16:39 UTC (Sun) by viro (subscriber, #7872)
Look, I've dealt with more than one entangled mess in the kernel code, thank you very much. I am *not* volunteering to fix cgroups; it's not just badly written kernel/cgroup.c - the interfaces on *both* sides (userland and the rest of kernel) are seriously misdesigned. As far as I'm concerned, configuring it out solves my problem nicely and those who want it are welcome to produce and submit patches. l-k is over -> that way...
And as for fanotify... *shudder* No way in hell I'm taking over that one. Eric is whole-heartedly welcome to that monster; as long as that fuckup can be configured away, I definitely will do so. On all my boxen.
Posted Aug 1, 2011 8:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
You will lose reliable kill support, but it'd still work.
Posted Aug 2, 2011 3:35 UTC (Tue) by FraGGod (subscriber, #63193)
systemd ties units to a processes via cgroups and cgroups only, it's an absolute requirement for systemd to run. No cgroups support in kernel = no systemd. Period.
That said, you can disable resource controllers, like cpu, blkio, etc, they are indeed optional, but not the cgroups feature itself.
Posted Aug 2, 2011 6:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Maybe he's incorrect, I've no idea.
Posted Aug 2, 2011 7:46 UTC (Tue) by rahulsundaram (subscriber, #21946)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds