On Tue, Jan 12, 2016 at 12:41 PM, Laurent Bercot <ska-devel_at_skarnet.org>
> On 12/01/2016 16:38, u-ztsd_at_aetey.se wrote:
>> I would love to get rid of udev but isn't libudev the harder part?
> Yes, libudev is definitely the harder part. Handling hotplug
> events via netlink is easy, and has been done several times over
> already; but libudev introduces policy in software, and most of
> the work is providing a compatible interface.
> I have my eyes set on libudev-compat from vdev:
> but I don't know how much of a drop-in it is, or how production-
> ready it is. I'll be asking people around who have experience with it.
I've been using vdev and libudev-compat it on my production machine for
several months. I use it with heavily with Chromium (YouTube and Google
Hangouts work) and udev-enabled Xorg (hotplugged input devices work as
expected). My encrypted swap partition's device-mapped nodes and
directories show up where they should, and my Android development tools
work with my Android phone when I plug it in.
I wouldn't say it's ready for prime time just yet, though. In particular,
because libudev-compat uses (dev)tmpfs to record and distribute event
messages as regular files (under /dev/metadata/udev/events), a program can
leak files and directories simply by exiting without shutting down libudev
(i.e. failing freeing up the struct udev_device). My plan is to have
libudev-compat store its events to a special-purpose FUSE filesystem called
eventfs  that automatically removes orphaned files and denies all future
access to them. Eventfs works in my tests, but I have yet to move over to
using it in production. Instead, I've been running a script every now and
then that clears out orphaned directories in /dev/metadata/udev/events.
> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
> Help: alpine-devel+help_at_lists.alpinelinux.org
Received on Tue Jan 12 2016 - 15:06:33 GMT