On 06/15/2012 02:10 PM, Tim Bird wrote: > On 06/14/2012 12:11 AM, Tomas Frydrych wrote: >> A system that runs nothing but a shell is really not useful for anything >> all, everyone using it will be adding some sort of services, so the >> question of how the extending works (or does not work), needs to be in >> the forefront of the design. My main reservation is that you are >> suggesting to break one of the basic premisses behind the whole >> ecosystem, namely that if I add a package that provides a service to an >> image, I get that service running; 'fix by documentation' is never a fix. > > I didn't address this in my other response, and I > think it's a valid observation. I agree that > everyone will want to add something to the init, > and that 'fix by documentation' is, in general, a > poor solution. > > I don't have any good solution here (one that scales, > or is likely to be adopted widely.) You don't really > need documentation, if you have the few lines of shell > script that are necessary to start a service in minimal > mode. The standard init scripts handle lots of interactions > with other services and runtime conditions. This is why > they are bloated (and the abstractions in them are > almost incomprehensible to read.) > > At Sony we've tried various things - like automatically > stripping init scripts of uncalled branches, removing > conditionals that don't apply, etc. We've also looked > at automatically converting init scripts to C code, to > speed up execution. You still end up with gobs of code > that doesn't apply to your situation getting executed > at boot time, an overly-complicated test scenario, and a > certain fragility in the overall init system. > > One of our early efforts, getting busybox > to not fork commands in init scripts that it had as > builtins, proved to be a significant feature that is still > valuable today to improve boot time. > > What we have settled on as a generic solution is basically > what I described in response to Darren's initial post. > You have a list of the short shell snippets required to start > commonly-used services in /etc/rc.local. These > are commented out by default, but a developer or product > team can uncomment them to enable the associated services. > This keeps everything in one place and provides developers > the commands needed to start things. Customization to > handle interactions or special cases can proceed from > there. It's not ideal, in that a developer may have to > re-create or rediscover some configuration, setting, or > start sequence to handle a more complicated usage scenario. > But in order to hit our targets for size or boot time, it > has been helpful to do things this way. The developer is > forced to manually enable each service, and the start > sequence, commands and command parameters are obvious > from the script. (This is rarely true of init scripts). >
Does this mean you just don't worry about respawning services? If the.... I dunno... ambient-light-sensor-daemon crashes, is the user expected to just reboot the device? > If anyone has good ideas or other experience for > the init sequence for highly customized, > resource-constrained products, I'd like to hear about > them. So Systemd does great things for deterministic boot with clearly defined dependencies between services which also allows for as much parallelism as possible (maybe that doesn't matter for your devices). I haven't looked at how big systemd is what how much it would bloat my kernel to support it. Have you? As I understand it, it brings in things like udev and basically starts to make my system look like a desktop/server. systemd-tiny ftw! -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
