Hans de Goede wrote:
> And please don't give me the initrd attached to kernel image argument,
> that sucks from a maintainance point of view. What if each system needs
> a different initrd because the initrd contains some specific info? With
> tftp this is trivial.
This is a misconception. You use the same initrd to tftp a second
initrd. If you really think there have to be differences at that level,
the in-kernel solution is going to need the same differences because
they do exactly the same thing.
> Well from an embedded system point of view, having bootp and tftp done
> through a ramdisk attached to the kernel also clearly is not the way
> because: -the ramdisk will always be bigger then the in kernel code
> (both can be freed after usage, I'm talking storage here not runtime)
A userspace ELF binary needn't be much larger than the equivalent kernel
code, if they're using the same API (syscalls). With the new cramfs,
the ramdisk would actually be smaller than the kernel code because every
file is stored compressed.
Not that it matters. A tftp client is a tiny program compared with the
kernel itself.
> -its a kudge, it's not nice and crispy
> -since it's a kludge it's a pain to maintain
initrd contents:
/linuxrc (one file)
linuxrc == executable which does tftp, then mounts a new ramdisk, then
runs /linuxrc on the new ramdisk. Uses standard syscalls. Contents of
/linuxrc more or less the same as the initrd-tftp code.
Results: exactly the same as initrd-tftp patch.
You can even debug the client before deploying it.
Doesn't get much crispier than that.
> Trust us (the embedded system developers) that the features we want are
> really usefull. If it could be done nice and crunchy in userspace, I
> would prefer it too, then I could easily maintain it myself and all
> would be happy. But the userspace solution is a kludge and will always
> be a kludge.
Have you /tried/ writing the userspace solution?
> using linux in embedded systems, embedded systems aren't taken seriously
> be the core kernel developers since they aren't sexy enough or
> whatever.
No, it's because those patches are totally unnecessary. Good solutions,
and much more flexible ones, already exist in user space. If you're
having trouble using initrd, then perhaps you should be supplying
patches to make initrd more friendly for embedded systems?
> I'm sorry if I sound a bit harsh but sofar we have, a lott of very
> usefull embedded system patches which all haven't made it into the
> kernel, or there is talk of taking them out:
> -devfs
Sexiness is not the objection here.
> -bootp (Yeah sure can be done through an initial ramdisk too, which
> can then do the tftp stuff too, which then can become the real initrd,
> which then can do some other stuff, sounds very much to me like it's
> very easy to break this scheme, and thus not nice to support)
This solution will not break from kernel version to kernel version as
it's based on standard APIs, unlike the in-kernel clients which do seem
to break whenever the network code breaks. So, nicer to support :-)
> So to build a kernel I need to apply devfs and initrd-tftp support and
> in the future hopefully someone in the embedded community will
> maintain a bootp patch if this is really removed.
That's your choice not to use the mechanism which /is/ supported for
this purpose: initrd.
> -uniform ide patches (some of these embedded devices have the weirdest
> ide chips, with strange
> ide emulating flash)
> -lm_sensors
These seem like reasonable things to go in if they're ready.
> Now if you could find a significant number of embedded system developers
> saying, we don't need that that is kernel polution, then I would be
> impressed.
What you have is a significant number of kernel developers saying "use
what we've provided, it works fine". It's up to you to prove us wrong,
by trying it and showing that it doesn't work. You haven't done that.
Why not try porting the initrd-tftp client to linuxrc?
enjoy,
-- Jamie
-
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:14 EST