systemd 183 and /lib/udev/devices/

[Allin Cottrell]

I see in the NEWS file:

"udev: /lib/udev/devices/ are not read anymore;
systemd-tmpfiles should be used to create dead device nodes as
workarounds for broken subsystems."

What sort of "broken subsystems" are we talking about here?
I'm currently running systemd 44 and udev 182 (without init
scripts) and I have "pts" and "shm" under /lib/udev/devices/.
There's no reference to /dev/pts or /dev/shm in fstab, but at
run time /dev/pts is populated and there's a tmpfs mounted on
/dev/shm. How can I tell whether I need the systemd-tmpfiles
workaround? Thanks.

Allin Cottrell



--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Tom Gundersen]

Post by Allin Cottrell
There's no reference to /dev/pts or /dev/shm
in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.

[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n61>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Allin Cottrell]

Post by Tom Gundersen

Post by Allin Cottrell
There's no reference to /dev/pts or /dev/shm
in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.
[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n61>

Thanks, that's nice. One more question: in switching to make
/var/lock a symlink to /run/lock, how does/should /run/lock get
created? Is that also automagic via systemd? (I didn't find a
reference to "lock" in mount-setup.c.)

Allin Cottrell
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Tom Gundersen]

One more question: in switching to make /var/lock a
symlink to /run/lock, how does/should /run/lock get created? Is that also
automagic via systemd? (I didn't find a reference to "lock" in
mount-setup.c.)

This is done by systemd-tmpfiles [0].

Cheers,

Tom

[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/tmpfiles.d/legacy.conf>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Bryan Kadzban]

Post by Tom Gundersen

There's no reference to /dev/pts or /dev/shm in fstab, but at run
time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.

So... machines without systemd are screwed, unless they resurrect the
bootscripts that copied these nodes, from way back before udevd started
to do it itself?

[Paul Bender]

Post by Bryan Kadzban

Post by Tom Gundersen

There's no reference to /dev/pts or /dev/shm in fstab, but at run
time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.

So... machines without systemd are screwed, unless they resurrect the
bootscripts that copied these nodes, from way back before udevd started
to do it itself?

Yes.

Whenever someone decides to violate the separation of utilities that
make Unix like distributions so powerful, the end user is harmed. This
is what the people behind systemd has chosen to do, yet falsely claim
otherwise (after all, if you cannot use udev without building the rest
of systemd, they are not separate).

Given its current direction, I suspect that systemd will suffer the some
fate as Hal. That is, it will become something that the community
rejects because it attempted to absorb everything. Unfortunately, end
users suffer in the mean time.

The sooner we fork udev, the better.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Paul Bender

Post by Bryan Kadzban

Post by Tom Gundersen

There's no reference to /dev/pts or /dev/shm in fstab, but at run
time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.

So... machines without systemd are screwed, unless they resurrect the
bootscripts that copied these nodes, from way back before udevd started
to do it itself?

Yes.
Whenever someone decides to violate the separation of utilities that
make Unix like distributions so powerful, the end user is harmed.
This is what the people behind systemd has chosen to do, yet falsely
claim otherwise (after all, if you cannot use udev without building
the rest of systemd, they are not separate).

There is a long history of needing more tools on the system to build a
program, than to use them, see all of the different build system ways of
specifying just this very thing.

Post by Paul Bender
Given its current direction, I suspect that systemd will suffer the
some fate as Hal. That is, it will become something that the
community rejects because it attempted to absorb everything.
Unfortunately, end users suffer in the mean time.

The "community" didn't reject hal, the developers realized they got it
wrong.

Post by Paul Bender
The sooner we fork udev, the better.

Feel free to, no one is stopping you. Also, some people seem to like
mdev for some reason, perhaps you should try that out instead.

Best of luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Robby Workman]

On Sun, 27 May 2012 11:20:43 -0700

Post by Paul Bender
The sooner we fork udev, the better.

Well, I'm not pleased with the direction it's gone either, but I
am also aware that a fork to maintain udev is a lot of work that
will mostly be monotonous, boring, and time consuming. I don't
want to do it, and I doubt anyone else does either, especially
since it *is* possible to build standalone udev from the systemd
sources.

This is currently untested and should be considered a work in
progress, but it might serve as a useful starting point for
someone:

http://connie.slackware.com/~rworkman/standalone-udev-from-systemd/

-RW
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kay Sievers]

"udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles should be
used to create dead device nodes as workarounds for broken subsystems."
What sort of "broken subsystems" are we talking about here?

The only one still known is the parport driver, where cups might rely
on module-autoloading by accessing of /dev/lp0.

There are around 3 users in the world which need that. :)

I'm currently
running systemd 44 and udev 182 (without init scripts) and I have "pts" and
"shm" under /lib/udev/devices/. There's no reference to /dev/pts or /dev/shm
in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?

How can you run udev without an init script? It's usually 2-3 steps to
bring it up. What mounts devpts and the /dev/shm tmpfs? The same thing
that calls mount should just also do the mkdir before the mount.

We decided against putting device nodes anywhere else than /dev, so
the functionality was removed. If you want the whole
/lib/udev/devices/ functionality back, one line like "cp -ax
/lib/udev/devices/* /dev" should do it.

In the future, tools are expected to use tmpfiles to create things
like the /dev/lp0 stuff. The tmpfiles are used to properly set up
directories, files, file content with the proper permissions in
volatile filesystems like /dev, /run (/var/run), /tmp, /sys. It can
also be used to create device nodes.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Allin Cottrell]

Post by Kay Sievers

"udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles should be
used to create dead device nodes as workarounds for broken subsystems."
What sort of "broken subsystems" are we talking about here?

The only one still known is the parport driver, where cups might rely
on module-autoloading by accessing of /dev/lp0.
There are around 3 users in the world which need that. :)

Fine, I'm not one of them.

Post by Kay Sievers

I'm currently running systemd 44 and udev 182 (without init
scripts) and I have "pts" and "shm" under /lib/udev/devices/.
[...]

How can you run udev without an init script?

I mean with a scriptless systemd setup.

Allin Cottrell
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html