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

Re: udev in initrd



On Mon, 2004-07-05 at 18:32 +0200, Florian La Roche wrote:
> > (*) I know some people (yes, you, Jeremy) have serious reservations
> >     about the details of how udev is implemented. And I really
> >     just mean "dynamic creation of device nodes on a ram filesystem".
> >     But I don't think the fact that udev is too 
> >     bloated/complex/policyless/whatever to run in Anaconda should keep
> >     us from trying to start fixing these problems for installed
> >     systems.
> 
> If HAL is also a daemon, then it could also provide the same functionality
> as udev? Or could dbus-support be added to udev, too?
> 

udev is not a daemon; it does contain udevd that can optionally be used
to serialise the hotplug events etc., but udev can also be run instead
of /sbin/hotplug. 

And when you build with klibc, then udev is very small.

> I also haven't looked at this myself, but AFAIK udev is collecting the
> information to maintain /dev and hal is a daemon providing information
> on available hardware. Hmmm...
> 

HAL and udev solves two completely different problems. 

It's true, yes, that HAL uses udev to name device nodes using the /etc/
dev.d callouts (to send a message to the HAL daemon through the system
message bus (D-BUS) using the hal.dev program), but that's about it. 

We could do device node naming and creation in HAL[1] but udev already
exists and works very well. And you want to use udev for installations
where a desktop isn't required because then you probably wouldn't like
to have HAL installed.

I hope this clarifies.

Thanks,
David

[1] : And if fact, one of the fundamental ideas about HAL is that
(desktop) applications should never care about device nodes, they are
merely cookies obtained when the (desktop) application queries the HAL
daemon for devices of a certain type.



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