[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Re: [klibc] initrd / initramfs future



 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]