On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk@xxxxxxxxxx) wrote: > > On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote: > > On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk@xxxxxxxxxx) wrote: > > > > > kmod_setup(); <=== ??? > > > > We load a couple of kernel modules which systemd needs, and are > > sometimes compiled as module only and which cannot be autoloaded for a > > reason or another. This is ipv6, autofs4, unix.ko, and we load them > > explicitly so that we can use them. > > You assume that everyone uses IPv6. This is not true. No I am not. You can still blacklist the ipv6 module if you want to via the normal modprobe blacklisting mechanisms. (As mentioned, systemd passes -b to the modprobe command line to ensure that). I explicitly said that in a previous mail. > > > hostname_setup(); <=== ??? > > > > We invoke sethostname() from inside systemd since that is one of the > > most trivial system calls known to men and doing this with a separate > > binary is just absurd. This way we also can ensure that the hostname is > > always initialised which is very useful for early boot logging and other > > stuff. On systemd you get the guarantee that the hostname is always set > > up if you run in userspace, > > You can't possibly know what kind of (possibly dynamic) hostname > admin might want to assign to his machine. The static hostname > may be as useless as default "(none)" which is set by kernel. > Anyway, logging with default hostname is not a catastrophe. (none) is what the bash makes from empty hostname, which is the default. We just fill in one. Just because systemd sets up a hostname at boot it doesnt mean it couldn't be changed dynamically later on. In fact if you are into dynamic hostnames you should send me a big cake for my birthday as thank you, because I give you stuff like this for F16: https://fedoraproject.org/wiki/Features/nssmyhostname http://www.freedesktop.org/wiki/Software/systemd/hostnamed > Why do you set up stuff no one asked you to? Yeah, I explained that already. > > > machine_id_setup(); <=== ??? > > > > Similar to the hostname we ensure that the machine id is always > > initialized, and has the same lifetime and validity guarantees as the > > hostname. i.e. that it is simply usable by *every* process started, > > regardless when. > > Point me at one program which uses machine id. I never saw one. > And anyway, why do you set up stuff no one asked you to? /etc/machine-id is a generalization of the D-Bus machine id, which is used by quite a number of programs directly and indirectly. With systemd we try to make this available globally and independently of D-Bus and add new semantics for stateless systems. > > > "plymouth_running()"? Plymouth? Systemd knows about plymouth? Why? > > > > Because we need to constantly send updates to it. It's a trivial socket > > operation. It's a trivial thing and spawning a separate process to send > > those updates each and every single time is a major waste of resources > > and basically doubles the processes we have to spawn at boot. > > Plymouth is not a part of Unix. Init process has no business knowing > about distro specific stuff like that. Well, since you appear to have invented Unix I think we simply have to disagree here. > > > This is an antithesis to modular, Unix way of doing things. > > > > Just because you can turn each trivial operation into a separate binary > > you shouldn't necessarily do that. > > Where did I propose turning everything into a separate binary? Well, I say calling sethostname() is a syscall we should simply do in PID 1 and then forget about, but you want this in a separate process (hence separate binary). > > It is what makes your system slow and > > heavy-weight. Insisting that we invoke sethostname() in a separate > > process is just stupid. I am mean, come on, think about it. It is *ONE* > > system call to the the hostname with sethostname(). Invoking > > /bin/hostname instead is at least 40 or so (and many of those quite > > heavy weight). And really, why are we even discussing the frickin > > hostname like this? > > Because it's a perfect example of a thing init process has no business > doing. Ever. The lightness of the syscall is irrelevant. For example, > you also do modprobing of various things, which is far from being > "just one syscall", so this argument is moot. Well, I guess we simply have to disagree. My interest is a tighly integrated, small, minimal, lightweight system. Yours seem to be a big, archaic, chaotic, redundant, resource intensive system. But that's fine. > > Do you know what "mono" means? It's greek and means "one". And "lithic" > > means "stone". And if systemd communicates with Plymouth, then this is > > not monolothic at all, since systemd and ply are two processes, not > > one. > > Init process should not have intrinsic knowledge about splash screens! systemd knows nothing about splash screens. All it does is send status updates to Plymouth. > This is basic idea of modularity. This is how Unix always worked. > Things should not be *too* interconnected. Things should be modular. And they are. Plymouth and systemd are two separate modules, which however communicate with each other (actually, strictly one way). > In your presentation, you have "Integration" as slide 17 and > "Modularization" as slide 18. Do you realize that these are the opposite > things? "More integration" means "less modularization". You can't have > both. Oh, of course you have. You must have that. The kernel for example is one module of the OS, your syslog another, and and your cron another. And don't tell me they wouldn't communicate with each other. They do; *of course* they do. Modularization without communication is uselessness. > > systemd is not running Plymouth stuff in the same process, is it merely > > communicating with it. > > Thanks that at least for now you don't have plans to incorporate > Plymouth. Dude, "for now", thanks for that. I mean, thanks for implying I had evil plans which I just wouldn't show right now. I mean seriously dude, there's really no point in doubting everything I say. Because if you do I see little point in even bothering with responding to you. Because if you want to believe what you believe regardless what I say I see no point in saying it. > > No, systemd tries to load those modules but if you are into retro > > computing you can still blacklist them using the usual modprobe > > blacklisting, and systemd will honour that (i.e. by passing -b to > > modprobe). > > > > > Why it (a *program*) took upon itself to decide what modules should > > > be running? There decisions are traditionally up to *humans* > > > in Unix world. > > > > Nah. udev loads modules automatically. > > udev loads modules according to config file, not by hard-coding stuff in > C code. IOW: udev does not load modules which *udev developer* > wants, it loads modules which *admin* wants. (Of course, > admin might choose to use standard config, but he does this > on his own volition). That is simply not true. Of course the autoloading rules are all compiled into the kmods. > > In fact on almost all systems > > there should be no need to ever load a module manually. > > Maybe. It's not up to a piece of software to decide. > In Unix, admins should have power to decide, not programs. > Programs provide the means, they don't dictate policies. Dude, systemd requires the functionality of the three modules it loads explicitly. It needs it at a time where udev is not running, hence autoloading doesn't work. There is *no* *other* *option* to work properly than to explicitly load those modules. And really, systemd honours the modprobe blacklist, and does so explicitly (i.e. the modprobe -b switch), so systemd enforces very little. it just makes sure it works properly in the default case on distros which do not compile the modules in question into the kernel. > > > Today I can remove CK from my Fedora install if I want to. > > > > You'll be left with very little if you do that. > > Try "rm /usr/sbin/console-kit-daemon". Works like a charm. Yeah, and equally well or badly "rm /lib/systemd/systemd-logind" will work. > > But why would you even want to remove that? > > If I would be willing to work in an OS with attitudes like this, > I'd be hacking in Windows. I don't. You apparently have very little idea how Windows works. > > > > I think systemd is much more optimized that what existed > > > > previously. (what else is parallelization but optimization?) I bet with > > > > you that a systemd system (modulo SELinux) can be built in a way that > > > > uses much less resources and boot time than one built on Upstart. > > > > > > I never used upstart. I used daemontools. I bet you can't beat *that* > > > on resource front. Boot time is comparable. > > > > daemontools does not support socket activation for parallelizing > > execution of servers with its clients. So yes, we can beat *that*. > > I said "you can't beat *that* on resource front". On resource front. > Can you beat it on resource front? I mean, this is like comparing apples and oranges. systemd gives you an OS building box, daemontools nothing but a service supervisor. If you use daemontools you also need an init system, and boot scripts, and everything else. So yeah, if you compare systemd and daemontools+sysvinit+initscripts then, hell yeah, I can beat that. > > Hmm? systemd is an init system, so it is of course PID 1. > > Again. *Why it has to have PID 1* to spawn and control services? > Can you please answer this? Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized processes. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
