Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> On Sun, Jun 03, 2012 at 07:13:03PM -0700, Bryan Kadzban wrote:
>> William Hubbs wrote:
>>> Actually other things could use it because of /tmp and /run and 
>>> creating/removing files/directories there on bootup.
>> Possibly, but the full functionality will require systemd anyway.
>> The program still has to be run by something; simply installing it
>> won't do anything useful.  Plus it will have to depend on having
>> mounted the various temporary filesystems that it changes.
> 
> I agree that just installing it does nothing. But, it can be run at
> the appropriate time by your boot scripts, so the other concerns you
> mention here would be taken care of that way.

Why put effort into bootscripts that run a random other tool, when
instead we can resurrect the single line cp from a few years back?

It's somewhat annoying that we have to do anything, but that's what happens.

>> Except that udev-182 and earlier *provided* an ABI.  "Put files in 
>> /lib/udev/devices and they'll be copied to /dev at boot time" was
>> the rule, just like "put programs in /lib/udev and refer to them in
>> rules you install with IMPORT{program}="" or RUN+="" without a
>> path" was the rule.
>> 
>> Now that rule has apparently been changed, so programs are going to
>> have to expend effort coping.  Unless I'm missing some
>> functionality of systemd-tmpfiles when I read the docs.
> 
> It has definitely been changed. See the systemd NEWS file. That is 
> exactly why I think we need the systemd-tmpfiles executable and man 
> page.

But see, the thing about ABIs is that they're not supposed to change.

What I will be doing in my own bootscripts is adding back the
single-line copy, to allow programs that are still using the old
interface to continue to work.  (Like old versions of the nvidia driver,
which dumped the nvidia0 / nvidia1 / nvidiactl character device files in
that directory, when they couldn't use the sysfs class functions in the
kernel directly.  It's been a while since that was happening, of
course.)

If you want to try to get systemd-tmpfiles to work, and figure out which
extra dependencies are needed (like, oh for instance, selinux or
libcap), feel free; that patch shouldn't be too hard to apply on top of
this one, if this gets committed.

>>> Gentoo relies on udev copying things from /lib/udev/devices,
>>> which is gone with this version of udev, so we need the new abi.
>> I think you need something in the bootscripts somewhere that
>> implements the *old* ABI.  Adding a line to the udev start script
>> that does the copy will give you that.
> 
> Also it will allow users to copy any kind of file they please into
> /dev, just by putting it in /usr/lib/udev/devices.

Well, /lib/udev/devices; there is no such thing as /usr/lib/udev unless
you're also buying into merging /usr, which I'm not yet.  And if your
system build has done it, then /lib/udev/devices will continue to work
as well.  That's the (previously-)accepted path.

But ignoring that -- yes, exactly, good point.  Some software (sysvinit,
sysklogd, gpm) puts named pipes or sockets in /dev -- although they do
it without support from the udev bootscript, so not supporting those
files would be OK for them.  I don't know what's running in the wild
that has relied on this behavior in the past, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html