udev rules files

[Kay Sievers]

On Sun, Apr 26, 2009 at 05:54, Michael Biebl <mbiebl at gmail.com> wrote:
> 2009/4/6 Kay Sievers <kay.sievers at vrfy.org>:
>>
>> 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