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). 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. -- Tim ============================= Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment ============================= _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
