Re: emdebian development model
Hi,
hum I didn't expect this discussion to take this direction but it's
interesting..
On Mon, Apr 27, 2009 at 3:58 AM, Prince Riley <wmarketing3@gmail.com> wrote:
> If you check in with a few more Emdev engineers, those putting consumer
> products and firmware out, you'll find that too often embedded engineers and
> chip makers shudder at using OSD project code as a platform because their
> dev system based on GNU tools sets which they feel have too steep a learning
> curve and too many gaps and holes in it.
>
> That's may sound wrongheaded, but they would rather pay 25K to 50K for a
> license for a tool with all the pieces in place than muck about with GNU TTY
> tools these days. All the major em dev houses use GNU toolchains with GUI
> frontends tools and sell them, so its not very easy to get them to look at
> anything but something that puts all the code cycle tools together wrapped
> tight with no heavy lifting.
>
I think there are _two_ issues here:
1) Integrating the installation of all the bits [tool chain, user space, ...]
2) GUI front ends.
I think Emdebian already addresses 1) quite well. In the old days you
used to have to start by compiling your compiler; with Emdebian all
this is just an aptitude install away. Also remember that, on your dev
workstation, you have all the power of Debian to compose everything
you need from Debian packages.
I sometimes wonder how much of the GUI usage is "developer pull" and
how much is "marketing push". Its a bit like point and click system
administration tools - look great when the salesman does the demo but
when you have to create 1000 new accounts for the new students a
command line and a scripting language starts to look a lot nicer. Even
Microsoft, after years of trying to write off the command line as 'has
been', has started to provide reasonable shell interfaces in their
latest products.
Like many others I'm not a great fan of GUIs either. In my experience
the "better" devs [the ones that everyone goes to when it doesn't
work...] tend not to like / use gui tools either. In particular I
don't like debuggers (at least not used in the classic step/breakpoint
mode) because they don't promote an efficient work cycle - you tend to
end up always stepping through the same code. They also hide timing
problems. I find it much more efficient to add code instrumentation
(printk, debugfs or equivalent) which can then be analysed off line
with scripts if needed and sometimes even used in field. They are
sometimes useful for initial bootloader startup and post mortem
analysis of panics etc.
That said if Emdebian wants to provide GUI wrappers why not - but I
strongly suspect the team has more important things to do.
Another thing is that I expect any dev environment to be scriptable
and all the tools to be installable from Debian packages.
For any project I want the bare PC to working dev environment process
to look like:
1) Install base Debian
2) Add entry to sources.list for in house repository
3) aptitude update && aptitude install my-project-dev-env
4) svn co <url> [or git clone..]
5) make kernel && make rootfs
[in the above my-project-dev-env is a mostly empty package that just
depends on all the packages that may be required and maybe includes a
few helper scripts].
I have, unfortunately, seen GUI based projects where the equivalent of
the above is a 100 page MS Word document explaining in click by click
detail how to install eclipse and all the other tools.
And once its all installed the build should be one or two commands
like the above [so that it can be automated on a continuous
integration build server if required]. Any GUI wrapper really must be
a _wrapper_ that runs the same scripts so as to have _one_
reproducible, way of building not the "command line way" and the "gui
way" [or more likely 'GUI way as setup by Tom', 'GUI way as setup by
Dick' ...]
> Just take a look at the Beagle board and Gumstik projects. What are the
> serious developers using.? You'll quickly see that you won't get many of
> them to adopt much less even look at this kernel for embedded work unless
> the tools are all there,idot proof, well supported and fully developed.
>
I don't know, please tell me.
> If you ask on a few of the mailing lists for these and other projects,
> you'll hear back that embedded Debian has a great deal of potential. At the
> same time it also has a great deal of competition. There are just too many
> other embedded kernels with full dev sets already out there to really
> bother going back to square one.
>
Emdebian doesn't provide a kernel (and IMHO nor can it or should it)
I also don't want my userspace and toolchain to be closely tied to the kernel.
When switching projects I prefer to keep the userspace tools.
To be honest I don't like vendor supplied kernels at all - you tend to
locked into old code [for instance the Freescale BSP for i.MX21 is
2.4.24 !]
That does depend on your product lifecycle though - if your doing a
"ship it and forget it" product thats going to last 12 months it might
be acceptable - the stuff I work on has to be maintained for 10 years.
Martin
Reply to: