Re: Announce: initrd-tftp 0.1

From: Khimenko Victor (khim@dell.sch57.msk.ru)
Date: Sat Jan 08 2000 - 18:40:42 EST


On Sat, 8 Jan 2000, Erik Andersen wrote:

> On Sun Jan 09, 2000 at 01:24:59AM +0300, Khimenko Victor wrote:
> >
> > > I really don't think obscure features for big iron systems are any different
> > > then obscure features for embedded systems.
> >
> > They ARE. You can do what you want from userspace. You can not support obscure
> > CD-ROM's, 64GiB RAM, etc. in sane way without kernel modifications. If (and
> > ONLY if!) some obscure feature for embedded system can not be done outside of
> > kernel in sane way it'll be included. But you should at least consider ALL
> > known userspace solutions and show how they ALL are failing to fill the
> > bill...
>
> I know all about Linux cdrom drivers. :)
>
> Now, show me the user space solution that lets me tftp
> an initrd without having to glob it into the kernel.
>
Do you really NEED to tftp an initrd - that's the question. As Cox's
written 10 times (or so) you can solve you problem with other tools.
I've yet to see computer-dumb end-user who screamed "oh, how to tftp
initrd". Obviously initial task was NOT to tftp an initrd. And that
initial task can be solved without changes in kernel. You can put tftp
client in initrd and fill initrd with other stuff with that client. You
can attach ot link initrd to kernel image (you do NOT need full binutils
suite and/or gcc to do this). And so on. Perhaps adding tftp support to
kernel was even right choice (GPL is all about freedom after all). But
it's YOUR choice. And you should maintain that patch in this case. If you
want such patch is official kernel then you should PROVE that it's right
choice. That's explain why all other ways to solve your problem (and no,
your problem is NOT "how to tftp an initrd" but "how to add changeable
initrd to embedded system" - it was initial problem AFAIK) can not be used.

This is Linux development process: if you want something in kernel you
should explain why it's so important to change kernel and not to create
small user-level tool. If (and ONLY IF!!!) you can convinience Linus that
the only sane way to solve problem is to add something to kernel then such
additions will be done. No matter how small and simple additions are.
Sometimes things perfectly doable from userspace (like rarpd) slipped via
Linus's censorship. Only to be removed later.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:13 EST