On Fri, 28.02.14 20:45, WaLyong Cho (walyong....@samsung.com) wrote: > On 02/28/2014 06:16 PM, Thomas Bächler wrote: > > Am 28.02.2014 10:02, schrieb WaLyong Cho: > >> systemd is already provide a special unit. If the type of unit is > >> service then that is 'basic.target'. Additionally default extra > >> dependency can be listed in system.conf and then other service unit will > >> have "After=" dependency implicitly. > >> In config directory /etc/systemd/default-extra-dependencies, if a > >> service unit is listed ignore-units or exist symlink in ignore-units.d > >> then the service units can be launched before extra dependencies. > > > > I am confused about the motivation here. This change adds several extra > > configuration primitives - one in system.conf, a new directory, and a > > mechanism to opt out of the new configuration. This is quite a lot for > > something that I find marginally useful at best. I think this > > functionality even enables an administrator to unwillingly break his > > system - setting this option likely has many unforeseen consequences, > > depending on the installed services. > > > This is just for optimizing boot up speed extremely. systemd said > "systemd provides aggressive parallelization capabilities," and > according to this too many service could race each on boot up time. This > functionality may be useless in desktop environment. However, it is > different in the embedded environment. Generally, in embedded, system is > made up with lower performance hardware. But User want to boot up his > device in short time. Actually, the boot up may be continued after some > of service(what listed config). But if the others are not important to > user then this functionality will be useful. > > As we are concerned, this functionality can break boot order. > But, unlike desktop, additional package will rarely NOT be installed > after product in embedded device. So in embedded environment, > administrator(s) will try to rearrange service launching order (like > me). If some of services wants be started before others then this > functionality can be useful. If not, that service should list others on > "Before=".
But if you do this on an embedded system you can do DefaultDependencies=no for all services where you want this and place them manually? Also, are you sure that you really want to solve this with manual deps? I mean, the kernel already has a CPU scheduler and an IO scheduler. Maybe it would be better to simply dump all the scheduling work on the kernel as far as that is possible, start everything in parallel, but then also tell the kernel what matters more, and what matters less. We already expose CPUShares= and BlockIOWeight= for services. Maybe we should duplicate these as StartupCPUShares= and StartupBlockIOWeight= which could set different values to apply only while the boot process is not complete yet. Or something like that. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
