Hello people, It has been a while I�ve done some usefull work butI have been very busy. Well now time to start discussing things that I talked and thought about recently.
First of all it would be nice to think about the init system of our embedded system. I already discussed it with several people and the main ideas are: Keep the normal Debian init system. This would make Debian and Emdebian packages easier to mix, reduce the work on preinst, postinst,... scripts in the package to a minimum, and make it possible to use Emdebian as a fully fledged mini-debian. Change the init system. Busybox doesn know runlevels anyway (correct me if I am wrong here). An embedded system does not need a complex init system because it mainly focusses on one or a few specific tasks. Also the hardware and its possibilities are more defined than in a normal PC system, which would justify a more generic approach. Bootup and initialisation is potentially faster than a full Debian init system. And a less complex system makes it easier for developers to do whatever they want with their system. On the other hand it would mean we have to change a lot of postinst and other scripts when Emdebianizing Debian packages. It also potentially breaks the ability to mix certain Debian packages with Emdebian ones. My proposition would be a simpler one along the lines of: - use /etc/init.d for keeping the startup scripts - use /etc/rc for keeping application or device specific scripts - starting through /etc/inittab - use rcS for calling different configurational scripts (see next points) and start a shell (if desired) - use /etc/init.d/network for starting networks interfaces and services - use/etc/init.d/apps for starting applications needed for the services your system will provide - use /etc/init.d/X for X oriented or graphical aimed dealings (for example for PDA's) - use /etc/init.d/security for security related apps (encryption, etc...) - use /etc/init.d/hardware for initialising other hardware (loading modules or initialising FPGA's) An other subject that came up recently was to identify relations between packages not by name but by a set of flags. This way you could have a set of arm packages optimized for Xscale for example. This way you could mix it with generic ARM ones, but not with packages which have optimalisations for say a Strongarm. This way you could also play with no-fpu or fpu, uclibc, glibc,... without having to change namespaces and making it easy to mix existing Debian packages with Emdebian ones. I do not really have a good idea to implement this, so any idea is welcome. Third point is adapting the building system so that it will be able to build a Debian source package with the same cross-compiler in one go, together with Emdebian source packages so to keep maximum compatibility. This is being worked on, and is not to hard to implement, so keep your eyes open. Hopefully I can find more time to work on it agian soon, greets, Philippe -- | Philippe De Swert -GNU/linux - uClinux freak- | | Stag developer http://stag.mind.be/ | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/
