On Wed, 22.10.14 13:36, David Herrmann (dh.herrm...@gmail.com) wrote: > Hi > > On Wed, Oct 22, 2014 at 1:33 PM, Lennart Poettering > <lenn...@poettering.net> wrote: > > On Thu, 11.09.14 10:49, Alexander Larsson (al...@redhat.com) wrote: > > > >> Hi, I'm looking at creating a runtime/app thing for Gnome in the style > >> of: > >> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html > >> > >> However, I noticed that some core dependencies like mesa uses libudev. > >> And in fact, needs user-set additional info not in sysfs. In particular, > >> it reads ID_PATH_TAG on render device nodes to pick what GPU to use in > >> multi-gpu situations (PRIME): > >> http://lists.freedesktop.org/archives/mesa-dev/2014-June/061798.html > >> > >> It seems to me that this means I need the host /run/udev inside the > >> application. I know that the udev database format changed in the past, > >> but can I rely on it being stable in the future, even if the host udev > >> is rev:ed to a later version than what is in the application runtime? > >> > >> Of course, there is also the question of /dev and /sys management in > >> sandboxed apps in general. Clearly any "modern" app will require some > >> real devices for things like direct rendering. But it would be ideal to > >> not expose "everything". How do we see this working? > > > > Good question. Ideally we wouldn't expose any raw devices to apps, but > > I figure this is not going to suffice (already with video4linux and > > things). > > This is not just about libudev. sd-login and friends are also > affected, as we expect libsystemd to be the same version as the binary > that generated the files in /run.
For the sd-login and friends case I am reasonably sure we can keep compat, the files are used for serialization of state for upgrades too, hence version compat already matters to us. Also the parsers are quite permissive, so this is something we should be able to make guarantees about. Also the stuff is old enough to know that we so far where good enough to not break things, which makes me confident for the future too. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel