--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

On Fri, Dec 30, 2005 at 10:53:40AM -0800, Bill Studenmund wrote:
> On Fri, Dec 30, 2005 at 03:17:08PM +0100, tlaronde@polynum.com wrote:
>=20
> [snip]
>=20
> > 2) extended facilities (a bootloader being a minimal kernel running on
> > the bare metal for debugging/fixing/exploring) would be better handled
> > by working on the NetBSD kernel and framework (libstand, both for MI and
> > reuse of existing code is already there for example). This all
> > has to do with embedded system and will benefit embedded system work;
>=20
> How exactly does this help an embedded system?
>=20
> All the embedded systems I've worked with either were evaluation boards,=
=20
> where something like a generic or custom kernel was fine, or were=20
> products. In your products, you know what you have where and so you=20
> can/should use a wired-down kernel. Thus you don't need a baby kernel to=
=20
> figure out where things are.

There is a lack in the chain of my explanations (plus the fact that I'm
not an english native speaker): implicitely (in my mind), talking about
"embedded" has something to do with "firmware" and "more limited memory"
plus a X terminal can be thought (once more for me)
as some kind of embedded device: in this sense,
discovering with a limited kernel a hardware you have no information
about (not a device you devise) [the example in my mind comes from a
project I once worked about aiming to reuse old i386---without
informations---to verify they were sane and turn them into X
Terminals---a la LTSP].=20

Hence, facilities in the kernel and in the NetBSD framework for embedded
work (limited memory constraint, stripping down the kernel and so on)
can probably be used to build a minimal kernel able to identify the
hardware (not to drive all the hardware) to give information about the
kernel to build specifically for it [from the example above, I used GRUB
plus network drivers from netboot just to send information about the
hardware discovered to a vulcan which built a kernel able to drive this
network card; GRUB then downloaded a small Linux distribution
with this minimal kernel to do a complete check up of the system; GRUB
plus a large part of the network drivers were only some tens of=20
kilobytes].

So: booting choices are a bootloader problem, but more extended
facilities (as aimed by GRUB) are already in the kernel, so if one wants
them one should work with the kernel and the framework already existing
for stripping down the size and fitting it in small memory system, hence
look at what is done for embedded systems with NetBSD or others.
Creating a bootloader that is a kind of general raw firmware CLI is
reinventing what already exists: kernels.

I hope I'm not saying too many stupidities (a couple of ones would be
enough to end this year: my quota for 2005 has already been reached...).

Regards,
--=20
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDtZZiUrGulWAG9AwRAuiAAKDGLmpz34mRtYMbH2Suo/ZflN7s0ACffyZ3
dclYwzCovrKAePL05Pr3Ck4=
=14gk
-----END PGP SIGNATURE-----

--tThc/1wpZn/ma/RB--