Thoughts of Emdebian.
So, I've been playing around with Emdebian for a few weeks, and have
become somewhat intimate with way the system works.
I'd like to have some discussion with some issues i have with Emdebian,
before i move forward on them, so that I have something that can further
Emdebian for the community, rather than just for my own use.
First off, i still love it. It will make life easier, once it moves
forward.
Second, i come from an x86 world; i haven't addressed the issues that
non x86 users will have, though i believe my following comments would
help those users.
My major complaint with Emdebian is that (besides documents) is that
everything is decentralized. There is no one, central, program to run
that can help me get an Emdebian system up and running.
First off, let's see if I understand Emdebian correctly.
I see Emdebian split up into 4 sections;
1. Setup
2. Configuration (cml2, cml2configure, LKC, qconf)
3 Generate rootfs (snp.py is excellent)
4. Testing and Installing
Step two is the an obvious problem, and hopefully my work to integrate
kbuild and LKC to emdebian has helped.
Documentation is another problem. In fact, a huge problem, as i
discovered, to truly using Emdebian quickly and efficiently. I'm not
complaining, as I do intend in the near-future to draft up some
documents that will help both users and developers of Emdebian.
I believe that Setup is the larger problem that is stopping Emdebian
from being useful to a large amount of people.
Here's what I see as being 'Setup':
a) Accept or hand-tweak, and manage, ./scripts
b) Accept or hand-tweak, and manage the instructions to compile sources
in ./scripts/src/
c) Make your own instructions to compile your own sources in
./scripts/src
d) Are you adding Debian binaries not in default config? Then edit
Kconfig, (or rules.cml & symbols.cml), AND ./snp/snp.conf.in AND re-run
gen_snp_conf.py, AND update ./templates and/or ./scripts.
e) Accept or hand-tweak, and manage ./scripts and ./templates
a), e) and b) are no big problem. With better documentation, or just a
casual reading of existing files in scripts/src/, c) is not that huge of
a hassle.
My biggest beef is with d) and e)
For example, to add something like, say, devfsd, one must have intimate
knowledge of an undocumented system to know that os-tree/deb/Kconfig (or
the correpsonding rules.cml and symbols.cml),
templates/somepath/somefile, and snp/snp.conf must be visited and
edited. One also needs to know that debian devfsd needs
/etc/devfs/devfsd.conf and other files in /etc/devfs/, and supplies an
entry in etc/init.d/devfs
When I first edited snp.conf, i expected all that information to be
auto-magically found out for me, and for the proper files to be
installed in rootfs/ for me. devfsd didn't work out of the box for me
because i only added /sbin/devfsd to snp.conf, forgetting to add
/etc/devfs/devfsd.conf, and a templates entry for /etc/devfs/ .
What would've made life easier for me if there was just ONE place i
could go to that would guide me in updating all these files. A script
that would've:
* asked me what I wanted to add. I'd reply, devfsd
* determine for me the name of the Debian package ( devfsd)
* snarf out the files provided by package devsfd, and _guide_ me in
determining what files are, and are not, essential to an embedded OS
(like take out all /usr/share/doc/ files), and create the updates to the
templates directory for me.
* automatically add the correct information to snp.conf.in for me
* run gen_snp_conf.py when finished.
* save everything, perhaps tarball it or as a patch.
At this point i could either keep my devfsd changes internal (ie it
obviously isn't useful for embedded devices, only usefull for my device
or application), or post this information to the Emdebian community,
which would debate which files were and were not needed, and whether or
not this package is essential for other embedded devices, and roll into
the next release.
What are your thoughts on this? I plan on addressing these issues
myself, as it would "scratch my own itch", making Emdebian useful tool
for both me and my customers. I'd like to get your input on these
issues, as well as how to address them, so that my work would help
Emdebian for the community, not just for me.
Reply to: