--7gGkHNMELEOhSGF6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 30, 2005 at 09:19:46PM +0100, tlaronde@polynum.com wrote:
> Hello,
>=20
> 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 t=
o=20
> > figure out where things are.
>=20
> 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,

The definition I use is that embedded systems are not general-purpose=20
systems, they are tasked to specific purposes. So far our definitions do=20
not disagree.

> 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

Here, however, they diverge. The main thing you ran into is that you are=20
dealing with reused desktop systems, not that you were using them as X=20
terminals. :-)

> 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].

I think what you describe is good. The reason I'm making this distinction=
=20
is that ANY desktop system can benefit from this discovery; the fact=20
you're dealing with random hardware is more significant to what you're=20
describing than the fact you use it as an X server or whatever. :-)

Take care,

Bill

--7gGkHNMELEOhSGF6
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDtZ2rWz+3JHUci9cRAu9MAJ9srhQf5LxB6cUD7Hx8Hrt0kXwI3gCcDo/s
iKo+xz0xT+eFtyZ+4gH2QgY=
=cvzd
-----END PGP SIGNATURE-----

--7gGkHNMELEOhSGF6--