Followup to: <[email protected]>
By author: Roman Zippel <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > Actually, that isn't quite true. One of the ways klibc is kept small
> > is by not guaranteeing a stable ABI... and not having compatibility
> > support for older kernels. This is one of the kinds of luxuries that
> > bundling offers.
>
> It's indeed more of a luxury than a necessity.
> How often does that really change?
A lot more often than you'd think.
> If you wouldn't remove all old init code at once it would still be
> possible to build a kernel this way. Why are you making it mandatory? Why
> don't you leave it optional for a while and only gradually remove the old
> code? This way distributions/users can experiment with it regarding their
> current initrd/boot setups.
Linus vetoed that option years ago. Anyway, the standalone version of
klibc has been available for almost three years, and has been used by
at least Debian for their initramfs code for a considerable amount of
time. It's not like it's an untested piece of code.
> Why shouldn't klibc be part of the basic build tools? I asked this already
> earlier: where do you draw the line regarding duplication?
Judgement call. I'm not sure I have done the best possible job,
either, but you have to call it somewhere.
> Are you going to duplicate every single tool, which might be needed
> to build the kernel only to reduce outside dependencies? IMO that's
> illusory for more complex setups anyway.
Hyperbole.
FWIW, I've worked in environments where you pull a single source tree
and get the compilers as well as the code you build them with. It is
*wonderful* for reproducibility, but I don't think that's going to
happen with respect to Linux, and noone is calling for that.
> Let's take booting from raid, in this case you need to install
> mdadm anyway, which could also provide an initramfs version. This
> way the setup tools can be generated from the same source, which
> reduces duplication and maintenance overhead.
You don't need mdadm to boot from RAID. kinit handles it just fine.
At the same time, I do intend to continue to maintain the standalone
klibc, which can be used to produce external binary trees.
> Just to be clear here, I really appreciate the work you've done, but I'm
> not exactly comfortable with merging a huge patch, which completely
> changes the boot sequence at once, without any clear plan of what's coming
> next. It would be a lot less problematic if the transition would be more
> gradually, which IMO is very well possible. Usually it's a requirement to
> split large patches, why should klibc be special?
When I asked Andrew how he'd like me to pass him the code, he said he
was happy pulling my git tree. This saved time for both of us, and
made it easier and quicker for me to integrate fixes. You can do so
too, which will get you a full history of the development, in about
1,400 pieces.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
