On Sun, Apr 26, 2009 at 05:54, Michael Biebl <[email protected]> wrote: > 2009/4/6 Kay Sievers <[email protected]>: >> >> But the base DeviceKit daemon, that is just an event multiplexer, may >> go away and get replaced by udev itself. We will send an update on >> this the next weeks, when we do a final decision. > > Any updates on this? Would be nice what you guys are planning and in > which direction it is heading.
Still all in an experimental state. We are not in a hurry, because almost everything works already with the current HAL stuff, and we don't need to break things in a rush anymore. It will still be almost the same model, with some mistakes removed, and have different interfaces. The transition from non-HAL to HAL was much more painful. This will just replace HAL bit by bit, cut stuff in independent pieces. It can run with HAL in parallel as long as needed. We will disable pieces in HAL, when they are properly replaced by new stuff. > Would this be part of udev/udev-extras? Would udev become dependend on D-Bus? No. If things work out as planned, DeviceKit, the main daemon, will go away. Subsystem daemons will subscribe directly to device evens with libudev. Udev/the kernel will do the event multiplexing/filtering, there will be no D-Bus involved. It will be part of main udev, not udev-extras. DeviceKit-disks will use libudev, and take over the block device part of HAL completely, and do the polling/mounting/disk-format/disk-setup interface. At that point, the block stuff will be disabled in HAL. DeviceKit-power will use libudev, and take over the all the power/battery/UPS handling from HAL. At this point, the part of HAL will be disabled. Pulseaudio uses libudev, there will be no other common sound interface, or totally stupid things like we pretend to do today for audio with HAL. X will likely be converted to use libudev directly instead of HAL. Wayland the experimental next-generation Display server, which might take over the low-level parts of X some day, already uses libudev. X will likely take over most of the input handling. Udev-extras may get the quirks database, and maybe the key mapping table handling, which it can upload to the kernel, based on the quirk database information. Device Access Control Lists, the stuff that grants access to devices like the cdrom, the webcam, the camera, ... will likely be part of udev-extras integrating with ConsoleKit. It is not implemented at all at the moment. NetworkManager will likely be converted to use libudev when HAL goes away. Connman, the stuff moblin uses instead, already uses libudev. There is not much useful stuff left in HAL after that, and most of the remaining pieces, like the device property cache and such, will die for good. Users of libudev connect to a netlink socket where udev passes the events. Any user can listen to these events, no privileges are required. The events can be pre-filtered by subsystem/devtype with an in-kernel socket filter. The listener will not wake up for events it has requested to be filtered out. If you want to look at the code, you can play around with the most recent libudev and the "udevadm monitor" program while plugging/unplugging devices. You can also enumerate devices and access the udev database with libudev. The "udevadm monitor" code looks like this: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=udev/udevadm-monitor.c;h=27520f70614f90d25076d0452790d26a2c3777b0;hb=HEAD#l148 Thanks, Kay _______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
