Charles Steinkuehler wrote:
> The part to 'get' about using an off-the-shelf distribution aimed at
> embedded development is the tool chain. The typical embedded distribution
> installs on top of some other system...most support a wide variety of linux,
> and even Windows NT/2000 using the GNU compilers.
This makes me think of UserLinux (or whatever it is) - LEAF (Linux)
isn't running on top of anything....
> The big advantage to using something already setup with a cross compiling
> development environment is we don't have to worry about (and fix) the many
> little things that break when trying to build an environment like
> this...someone else did that work for us.
As long as I compile for the current environment, things don't break.
If I compile for an alternate library (which Red Hat provides RPMs
for) things don't <usually> break....
> Also, I guess I lean towards the embedded side of things, as I've done a lot
> of work with embedded processors. In addition, I guess it seems (at least
> to me) more likely to see a LEAF derivation in a stand-alone black-box
> router or VPN gateway (ie embedded system) than to see a LEAF derivation
> that is trying to be a full-blown desktop workstation with a self-hosted
> development environment.
I got to thinking about that.... a question to myself was: "What is
uClibc good for if you have to recompile 3,000 packages to use it?"
The answer - eventually and slowly arrived at..... - was that you
don't recompile 3,000 packages: just recompile the 40 that you
actually use in the system...
The more I think of it, I've actually been leaning towards a
micro-Linux distribution rather than an embedded appliance.
> Note that even if we can self-host a development system, we're STILL in a
> cross-compile environment, as the target install machine is typically NOT
> the machine you're compiling on, even though they may share the same CPU
> architecture.
But that's not really cross-compilation, since the binaries can be
executed on either machine, and the compiler is generating code
compatable with the compile-time environment.
> The more I think about it, the more I'm tempted to think we'll probably wind
> up with our own complete distribution, like it or not.
I'm leaning that way - the Oxygen configuration file enhancement is a
serious step away from traditional LRP.
> At a minimum, we'll
> probably need to re-package anything pre-made, unless we can get full
> support for creation & extraction of RPMs or DEBs small enough to fit on a
> floppy.
Wouldn't need to as long as one uses glibc or a library set that can
stand in for it completely.
> Also, I'd prefer to make a system flexible enough to handle:
>
> Base utilities...choice of:
> "Standard" binary
> BusyBox
> asmutils
> shell-script (POSIXness or similar)
> omitted entirely
>
> Libraries...choice of:
> ulibc
> glibc (various versions)
> newlib
> others?
...dietlibc...
What is the goal in doing all this? Isn't this wide latitude of
variation what is causing all the grief in the glibc versions? Trying
to compile something written for glibc 2.2 against glibc 2.0 can be
downright annoying...
> The other thing I'd like to see is an enhanced packaging system
> of some sort, that can handle a variety of boot and storage media...from the
> current floppy boot into a ramdisk, to CD or HDD boot into a hybrid system
> with volitle (ram-disk), non-volitle (flash/HDD), and read-only
> (CD-ROM/boot-ROM).
You lost me there. A package system has no concept of "boot" or
"media", only of files and compiles and makes and things like
/bin/sh...
There are several packaging formats that are interesting:
* RPM - unrpm (busybox)
* Deb - undeb (busybox)
...and something else to consider:
* Portage - this is used by Gentoo, and basically brings a form of the
FreeBSD ports tree to Linux. The concept is this: you change into a
directory, perform a "build", then the system fetches the source file
and compiles it for your environment. This has the benefit of
compiling the code for *YOUR* environment rather than relying on a
central packaging authority which may or may not run the same things
that you do.
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
