On Sun Jan 09, 2000 at 02:12:09PM +0100, Werner Almesberger wrote:
>
> > I'll commit myself to maintaining the driver if that's what you're worried
> > about. It's not exactly large or complex.
>
> The crucial problem I see is that it sets the wrong precedent. Next
> month, somebody will need DHCP too. Then somebody else will require
> SSH for secure communication. The next one will want to do it all
> via HTTP. Maybe name resolution will be next. Then everything with
> IPv6. Etc.
>
> If a clean user-space solution is implemented now, all those
> extensions can be built on what is ultimately a more scalable basis.
> In my opinion, it would make sense for the work on the user-space
> utilities to come from people working on embedded systems, because
> you're the experts for building unbloated versions of tools already.
Ok. You have me convinced. I had not considered a user space tool run
as /linuxrc that acts as (to give it a name) a third stage boot loader
which in turn loads up the final root device in any of 68 kinds of
strange ways. Clearly, there are so many variants on this theme that
adding it into the mainstream kernel could become a regular pandora's
box. The mechanism of the initrd provides for a /linuxrc which could
be used to download/mount/set up the final root device, so the kernel
wouldn't need to do any of that stuff.
>
> As an added bonus, you can probably undo yet another bad precedent
> and kill kernel-based NFS root when you're done with this little
> project ;-)
Good point. I remember reading fs/super.c mount_root() and thinking,
yuck. Busybox supports nfs mounts (20k for mount+nfs support with
everything else turned off)... Oh, but in an initrd it would need to be
staticly linked -- 308k then. Gzipped into an initrd then it would be
an extra 150k globbed into the kernel as a third stage bootloader. I
suppose I could live with that. Busybox doesn't support tftp yet, but
that shouldn't be hard to add (and would certainly be smaller then nfs).
For deeply embedded stuff, where an extra 300k is unacceptable, a
patched up kernel will need to be used, as I can see that this stuff is
not likely to end up in Linus' kernel.
-Erik
--
Erik B. Andersen Web: http://www.xmission.com/~andersen/
email: [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
