Re: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel <harald.dunkel@t-online.de>]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Greg KH wrote:
> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]