Debian debates systemd

Posted Jul 30, 2011 16:31 UTC (Sat) by viro (subscriber, #7872)
In reply to: Debian debates systemd by patrick_g
Parent article: Debian debates systemd

I have - many times. It hasn't seen an extension it wouldn't love; unfortunately, quite a few of those are badly written and Lennert doesn't seem to be able to realize that such a thing is possible at all. Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code. Yes, it got into the kernel. The best thing to say about it is that it can be configured away, but only if userland does not rely on it. Another equally nasty piece is fanotify, and IIRC systemd also relies on that one. D-bus is spectaculary ugly as well, and contrary to the claims in this thread there *is* a saner replacement - plumber, that is. Yes, it would depend on kernel being Linux (or something supporting 9p), so it probably wouldn't make kFreeBSD crowd any happier, but porting 9p to FreeBSD kernel is not impossible (or to Hurd, for that matter, assuming that anybody cares; I definitely do not).

It's not about using non-POSIX stuff; there are perfectly POSIX-enshrined FPOS APIs - look at POSIX ipc for starters (interface and, unfortunately, implementation as well). And I've no problem whatsoever with Linux-specific things being used - I could hardly claim that after having done Linux implemantation of namespaces, after all. Or after having helped Ram Pai with shared subtree implementation - the latter being unique to Linux, as far as I know (Plan 9 has namespaces, albeit somewhat different, but not this one).

The problem is that Lennert seems to treat everything in the kernel, no matter how optional and badly written, as fair game for making mandatory. And _that_ is a bloody bad idea, no matter how many deficiencies sysvinit has. Init replacements are not optional, thus pinning their dependencies down.

If you want kernel/cgroup.c code review, I can probably post it a bit after -rc1. Assuming I survive writing it - high blood pressure and all such... Not sure if lwn would be the right place for that, though.

Debian debates systemd

Posted Jul 30, 2011 16:39 UTC (Sat) by viro (subscriber, #7872) [Link]

gyah... s/Lennert/Lennart/; I definitely need more coffee. My apologies...

Debian debates systemd

Posted Jul 30, 2011 19:04 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (13 responses)

It is upto user space developers to cross check which kernel API's are bad or not. If they are bad, kernel developers shouldn't have merged it. Besides, cgroups *is* a optional dependency for systemd.

Debian debates systemd

Posted Jul 30, 2011 20:23 UTC (Sat) by viro (subscriber, #7872) [Link] (12 responses)

I agree that shit shouldn't be merged. Mistakes happen; some of them - with worse reasons than other. It doesn't make stepping into a pile of shit any smarter, especially with this kind of exhuberance, but Lennart's lack of taste is his problem; having to enable that crap on my boxen is mine and maintaining a set of patches to affected packages in Debian I happen to care about + running autobuilders to generate binaries is more attractive for me than paying that kind of price.

Debian debates systemd

Posted Jul 30, 2011 21:37 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

Let's say I am a user space developer who isn't knee deep in kernel politics and I have no idea which interfaces are considered a terrible mess or which is awesome. If I like the functionality that cgroups offers (and my understanding is that even kernel developers who say it is bad code recognize the value of the functionality), I will use it and let the developers worry about the implementation details. I will trust kernel developers not to merge crappy code. Blaming user space developers for using interfaces that are merged and advertised as available in the kernel seems like just passing around blame. If it just the implementation that is problematic, it can be fixed although you will have to keep compatibility at the interface level. It is not ideal but not the first time it has happened either.

Debian debates systemd

Posted Jul 30, 2011 21:47 UTC (Sat) by riel (subscriber, #3142) [Link]

There should be no reason to keep compatibility in the kernel/user API for something as specialized as cgroups. There is a reason libcgroup abstracts that stuff away.

Debian debates systemd

Posted Jul 31, 2011 0:01 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (9 responses)

... and you sir are spot on.

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.

Cheers
Jon

Debian debates systemd

Posted Jul 31, 2011 0:50 UTC (Sun) by viro (subscriber, #7872) [Link] (8 responses)

What the fuck? The interface in question is optional; it's *NOT* guaranteed to be present in any kernel. Disbelieve all you want, but that fact does depend upon your beliefs. Incidentally, the code behind that interface is a misdesigned piece of shit, best configured out unless there are extremely strong reasons to enable it. Not everything that can be enabled should be.

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.

Debian debates systemd

Posted Jul 31, 2011 11:59 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

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?

Debian debates systemd

Posted Jul 31, 2011 14:27 UTC (Sun) by riel (subscriber, #3142) [Link] (2 responses)

The problem is with systemd not running when one of the optional kernel features it depends on is configured out (or the interface changes).

This is a serious lack of robustness for something that's supposed to replace /sbin/init...

Debian debates systemd

Posted Jul 31, 2011 15:52 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

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.

Debian debates systemd

Posted Jul 31, 2011 16:39 UTC (Sun) by viro (subscriber, #7872) [Link]

And vice versa, the people who don't want to enable cgroup/fanotify/whatever weird shit Lennart decides to use today won't use systemd. Exactly my point...

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.

Debian debates systemd

Posted Aug 1, 2011 8:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

systemd can work just fine without cgroups.

You will lose reliable kill support, but it'd still work.

Debian debates systemd

Posted Aug 2, 2011 3:35 UTC (Tue) by FraGGod (guest, #63193) [Link] (2 responses)

What on earth gave you guys that idea?

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.

Debian debates systemd

Posted Aug 2, 2011 6:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Systemd maintainer in Fedora: http://lwn.net/Articles/441149/

Maybe he's incorrect, I've no idea.

Debian debates systemd

Posted Aug 2, 2011 7:46 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

I just did the initial packaging work and got it into the distribution and wrote up the feature page so Lennart and others have time to do the real work. Feel free to look at the source when in doubt. These patches will get you a system that boots but won't have all the functionality that relies on cgroups.

https://bugzilla.redhat.com/show_bug.cgi?id=628004

http://cgit.freedesktop.org/systemd/patch/?id=e5a53dc7463...

http://lists.freedesktop.org/archives/systemd-devel/2011-...

Debian debates systemd

Posted Jan 23, 2013 10:21 UTC (Wed) by pgoetz (subscriber, #4931) [Link]

> If you want kernel/cgroup.c code review, I can probably post it

Did this ever happen? Also, I'm curious to know your reasons for why plumber is better than D-bus.

Debian debates systemd

Posted Jan 23, 2013 15:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Plumber? What is that? Care to provide a URL?

DBUS is _used_. It's actually _used_ in the freaking _real_ _world_. At that point saying it's "ugly" and everyone should just rewrite all their software to use my-obscure-and-useless-implementation is, shall we say, madness.

Debian debates systemd

Posted Jan 23, 2013 16:46 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (3 responses)

Which says approx. nothing about a) the need to put into kernel, b) the quality of the patches submitted.

Debian debates systemd

Posted Jan 23, 2013 17:26 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

a) It's pretty clear - kernel message routing implementation reduces context switch overhead and the number of data copies.
b) Last time network subsystem maintainer refused even the idea of AF_DBUS - we evidently should use IP multicast. So people went the usual way - write something, ship 10 million devices with it and present it as a fait accompli.

Debian debates systemd

Posted Jan 23, 2013 18:30 UTC (Wed) by rleigh (guest, #14622) [Link] (1 responses)

Being in (allegedly) wide use has zero bearing on the quality or suitability of the code for going into the kernel. It's good to see that at least the networking maintainer has an ounce of sanity here. Being pressurised to include this on merits other than quality does not paint this (or the people doing it) in a good light. It's not good to see things being pushed hard by people with agendas which don't necessarily align with what's technically the best path to take, circumventing the review and criticism such a drastic change would normally have.

Debian debates systemd

Posted Jan 23, 2013 18:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Code quality is not the problem here (it can be reworked, patches are not that big), it's the opposition to the idea itself.

Debian debates systemd

Posted Jan 23, 2013 17:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

So, I found the documents about the plumber (http://doc.cat-v.org/plan_9/4th_edition/papers/plumb). What a freaking POS.

How is it even _comparable_ to DBUS? It can't be used to send file descriptors or credentials, it has no schema support for messages (they are free-form text), it has no central naming directory, it has no support for activation (though we can probably use systemd's socket activation for it). Oh, and it also mixes in weird routing rules that work on the basis of regex matching.

Do you even *know* how and why DBUS is used out there in the real world?

Debian debates systemd

Posted Jan 23, 2013 22:33 UTC (Wed) by raven667 (subscriber, #5198) [Link]

While a bikeshed argument on whether you like the style of plumber or DBUS better is probably not worthwhile I think there is an interesting point worth making and that is that even 15+ years ago the creators of UNIX thought that a system wide standard IPC protocol and daemon was an important thing to have, such that they implemented it. That's an important point to highlight because there are still so many who believe that the idea of a standard IPC system is non-UNIX and some sort of abomination and it should be pointed out how wrong that is.

Debian debates systemd

Posted Mar 15, 2013 21:59 UTC (Fri) by pgoetz (subscriber, #4931) [Link]

> Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code.

That's completely irrelevant. cgroups are an absolute necessity in modern multi-user systems.