Subject: Re: [alpine-devel] udev replacement on Alpine Linux
To: alpine-devel@lists.alpinelinux.org
References: <CAO6-m02qfTUZeW9a0+WZY9eqEgnr50T27m4vPy5Y6unc64kNeA@mail.gmail.com>
 <20150727103737.4f95e523@ncopa-desktop.alpinelinux.org>
 <20150728052436.GC1923@newbook>
 <CAO6-m02gSo0CeP7F=gTpsMukiNj+CUTM+FkJG86k-kGU=ZjVFA@mail.gmail.com>
 <20160112153804.GI32545@example.net> <56953ABE.5090203@skarnet.org>
 <CAFsQEP2Cx23cGcCTZ8e1RK+LOPtbvi=H6xUwuPH=9WqFQYg51A@mail.gmail.com>
From: Laurent Bercot <ska-devel@skarnet.org>
Message-ID: <56958E22.90806@skarnet.org>
Date: Wed, 13 Jan 2016 00:37:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
Precedence: list
MIME-Version: 1.0
In-Reply-To: <CAFsQEP2Cx23cGcCTZ8e1RK+LOPtbvi=H6xUwuPH=9WqFQYg51A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/01/2016 21:06, Jude Nelson wrote:
> I've been using vdev and libudev-compat it on my production machine
> for several months.

  Sure, but since you're the author, it's certainly easier for you
than for other people. ;)


>  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.

  That's neat, and very promising.
  I doubt you're the right person to ask, but do you have any
experience running libudev-compat with a different hotplug
manager than vdev ? I'd like to stick with (s)mdev as long as
I can make it work.


> 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).

  That may be OOT, but I'm interested in hearing the rationale for
that choice. An event is ephemeral, a file is (relatively) permanent;
recording events as regular files does not sound like a good match,
unless you have a reference counting process/thread somewhere that
cleans up an event as soon as it's consumed.

  Anyway, unless I'm misunderstanding the architecture completely,
it sounds like leaks could be prevented by wrapping programs you're
not sure of.


>  My plan is to have libudev-compat store
> its events to a special-purpose FUSE filesystem called eventfs [1]
> that automatically removes orphaned files and denies all future
> access to them.

  Unfortunately, FUSE is a deal breaker for the project I'm working on.

  I'm under the impression that you're slightly overengineering this;
you shouldn't need a specific filesystem to distribute events. My
s6-ftrig-* set of tools distribute events to arbitrary subscribers
without needing anything specific - the mechanism is just directories
and named pipes.
  But I don't know the details of libudev, so I may be missing
something, and I'm really interested in learning more.


> Instead, I've been running a script
> every now and then that clears out orphaned directories in
> /dev/metadata/udev/events.

  A polling cleaner script works if you have no sensitive data.
A better design, though, is a notification-based cleaner, that
is triggered as soon as a reference expires. And I'm almost
certain you don't need eventfs for this :)

-- 
  Laurent


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---