[dm-devel] Re: [klibc] initrd / initramfs future
Olaf Hering
olh at suse.de
Wed Sep 15 21:06:07 UTC 2004
On Wed, Sep 15, H. Peter Anvin wrote:
> OK... now I'm confused. Your paragraphs 2 and 3 seem to directly
> contradict each other. Are you saying it should or should not be part
> of the kernel tarball?
Distros have to use the same stuff, and installing the kernel-sources
just to get the initramfs image done isnt the brightest idea. Thats the
reason why having an external project 'which does it all' is a better
choice.
> For the time being, my main concern has been to get a compatibility
> platform off the ground so we can do gradual migration of functionality.
> This means dropping something into the kernel tree which supports all
> current functionality, in a compatible fashion (sometimes the hard
> part!) but has at least some of that functionality implemented in
> userspace -- nfsroot being the obvious choice.
prepare_namespace does more, you would need something like /sbin/udev to
create the current device nodes. The kernel must be buildable by a user,
so mknod will not work. Having the special case for /dev/console is
certainly ok, but for more device nodes like /dev/hdaN?
> What you have done above seems like a lot more abitious; this is a good
> thing because it gives more of a concrete benefit. What I'm not clear
> on is what you're suggesting:
>
> - Should be drop the idea of putting it into the kernel and maintain it
> as a separate project forever? (Not that that isn't a legitimate option.)
For a start it is probably ok, but its already legacy when it hits
kernel.org. People will scream if you remove klibc again, I'm sure :)
Better check if doing an external project in the first place is better,
for whatever reason.
> - Should I continue down the compatibility route, and gradually migrate
> your functionality into that solution?
It depends, if klibc itself becomes that solution? I havent thought
about it that much.
> - Should we do the compatiblity thing, but really recommend that people
> use the standalone solution?
>
> - Should we try to do the "big bang" type patch which does everything
> coming out the chute?
Maybe we should first define what is needed, beside the current klibc
functionality (shell + tools, ipconfig, nfsmount, mount):
/sbin/udev to generate devnodes on the fly inside the initramfs
module handling
uuid + label handling
libdevmapper
lvm
software raid
evms
"that hardware raid stuff"
Too bad, having all these tools as static klibc binaries will duplicate
much tools. To pick one random example:
If you upgrade evms, the klibc version should be updated as well. Will
evms provide its own way to build also a klibc binary?
If yes, it should probably a static one. If klibc gets updated, the
klibc-$foo.so interpreter will change $foo, and the just built evms
tools will not run anymore.
Or, a copy of some evms release is shipped inside klibc.
I havent followed the lvm, evms and devicemapper stuff, how incompatible
are the different releases? I see a device-mapper-1.00.09 on my
workstation. If 1.00 is a stable interface, no problem. If there are
subtle differences between 1.00.09 and 1.00.42, it would be a minor
problem.
Maybe there can be a distro-wide mkinitramfs project. It would get us
closer to the day where prepare_namespace() is removed from the kernel.
I see, that looks already like a fun project...
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
More information about the dm-devel
mailing list