On Sat, Feb 12, 2005 at 09:30:54AM +0100, Harald Dunkel wrote:
If it is not possible to use klibc together with a non-Linux system (e.g. FreeBSD or Mach), then I would suggest to make klibc an optional kernel patch and drop it from udev and hotplug.
But it is not possible to use udev or hotplug-ng on a non-Linux system, right?
Thats not the point. The point is to remove the copy of the klibc sources from packages like udev and hotplug-ng and to use the existing klibc sources or binaries on the target system instead. Just to keep it modular.
As far as "optional kernel patch"? What do you mean? People are working on adding klibc to the main kernel tree, nothing optional about that.
I do not know the internals of klibc that much. Is it possible to use klibc on non-Linux systems, e.g. on Mach or FreeBSD? Maybe by adding some #ifdefs to klibc's kernel interface?
If yes, then making klibc an integrated part of the Linux kernel source tree and dropping the independent development tree would be a restriction to the use of klibc.
AFAIK the plan for initramfs is to move as much functionality as possible from kernel to user space. Why not do the same thing for the sources? Everything that is supposed to be run in user space could be removed from the kernel source tree and managed seperately, either in a set of userspace modules like klibc, hotplug, udev, initramfs, etc., or in a monolithic "userspace-tools" source tree.
Surely klibc belongs to the user space.
Regards
Harri
signature.asc
Description: OpenPGP digital signature
