Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[Kurt H Maier]

On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
> 
> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
> 

This would be fantastic.

Kurt H Maier

Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[Emmanuel Benisty]

On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
> On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
>>
>> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>>
>
> This would be fantastic.

And that would solve this very much worrying issue [1], quoting:
"(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[david]

> On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
>> On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
>>>
>>> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>>>
>>
>> This would be fantastic.
>
> And that would solve this very much worrying issue [1], quoting:
> "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
> haven't noticed it yet. I am looking forward to the day when we can drop
> that support entirely.)"
>
> [1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

I think it's worth noting that even though udev 189 was recently released, 
the not-yet-released Ubuntu 10.10 is going to be including udev 175.

David Lang

Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

[Henrique de Moraes Holschuh]

On Fri, 05 Oct 2012, david@lang.hm wrote:
> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
> >>On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
> >>>Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
> >>
> >>This would be fantastic.
> >
> >And that would solve this very much worrying issue [1], quoting:
> >"(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
> >haven't noticed it yet. I am looking forward to the day when we can drop
> >that support entirely.)"
> >
> >[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
> 
> I think it's worth noting that even though udev 189 was recently
> released, the not-yet-released Ubuntu 10.10 is going to be including
> udev 175.

So is Debian.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: udev breakages -

[Nix]

On 5 Oct 2012, Henrique de Moraes Holschuh told this:

> On Fri, 05 Oct 2012, david@lang.hm wrote:
>> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
>> >>On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
>> >>>Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>> >>
>> >>This would be fantastic.
>> >
>> >And that would solve this very much worrying issue [1], quoting:
>> >"(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
>> >haven't noticed it yet. I am looking forward to the day when we can drop
>> >that support entirely.)"
>> >
>> >[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>> 
>> I think it's worth noting that even though udev 189 was recently
>> released, the not-yet-released Ubuntu 10.10 is going to be including
>> udev 175.
>
> So is Debian.

I'm a bit surprised they didn't stick with 168, really. Even udev 175
requires a /usr mount in the initramfs, and devtmpfs (though the latter
is easy to replace). The former is probably a good idea anyway. The
latter... for any system other than the very largest, or embedded
systems that must boot in a second or less, I can't see a benefit.

-- 
NULL && (void)

Re: udev breakages -

[Eric W. Biederman]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote:
>> There are still quite a few interesting cases that devtmpfs does not
>> even think about supporting.  Cases that were reported when devtmpfs was
>> being reviewed. 
>
> Care to refresh my memory?

Anyone who wants something besides the default policy.   Containers
chroots anyone who doesn't want /dev/console to be c 5 1.

>> Additionally the devtmpfs maintainership has not dealt with legitimate
>> concerns any better than this firmware issue has been dealt with.  I
>> still haven't even hear a productive suggestion back on the hole
>> /dev/ptmx mess.
>
> I don't know how to handle the /dev/ptmx issue properly from within
> devtmpfs, does anyone?  Proposals are always welcome, the last time this
> came up a week or so ago, I don't recall seeing any proposals, just a
> general complaint.

The proposal at that time was to work around the silliness with a little
kernel magic.

To recap for those who haven't watched closely.  devpts now has a ptmx
device node and it would be very nice if we were to use that device
node instead of /dev/ptmx.

Baically it would be nice to tell udev to not create /dev/ptmx, and
instead to make /dev/ptmx a symlink to /dev/pts/ptmx.

I got to looking at the problem and if I don't worry about systemd and
just look at older versions of udev that are out there in the wild it
turns out the following udev configuratoin line does exactly what is
needed.  It creats a symlink from /dev/ptmx to /dev/pts/ptmx.  And if
on the odd chance devpts is not mounted it creates /dev/pts/ptmx as
well.

KERNEL=="ptmx" NAME:="pts/ptmx" SYMLINK="ptmx"

Does assigning to NAME to specify the device naming policy work in
systemd-udev or has that capability been ripped out?

Thinking about it.  Since systemd-udev no longer supports changing the
device name.  And likely it no longer even supports assigning to NAME
even for purposes of changing the target of the symlink.  Then I expect
what we want to do is:

diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index 147d1a4..7dc5bed 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -377,6 +377,7 @@ static int devtmpfsd(void *p)
                goto out;
        sys_chdir("/.."); /* will traverse into overmounted root */
        sys_chroot(".");
+       sys_symlink("pts/ptmx", "ptmx");
        complete(&setup_done);
        while (1) {
                spin_lock(&req_lock);



Eric

Re: udev breakages -

[Geert Uytterhoeven]

On Wed, Oct 10, 2012 at 5:19 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> I don't know how to handle the /dev/ptmx issue properly from within
>>> devtmpfs, does anyone?  Proposals are always welcome, the last time this
>>> came up a week or so ago, I don't recall seeing any proposals, just a
>>> general complaint.
>>
>> Is it really a problem - devtmpfs is optional. It's a problem for the
>> userspace folks to handle and if they made it mandatory in their code
>> diddums, someone better go fork working versions.
>
> If only there was a viable alternative to udev.
>
> Distributions are being pushed around by the udev+systemd project
> precisely because of this reason; udev maintainers have said that udev
> on non-systemd systems is a dead end, so everyone that uses udev
> (everyone) is being forced to switch to systemd if they want to
> receive proper support, and at some point there might not be even a
> choice.
>
> I for one would like an alternative to both systemd and udev on my
> Linux systems, and as of yet, I don't know of one.

A few years ago, the OpenWRT people pointed me to hotplug2 when I mentioned
udev made my poor m68k box with 12 MiB of RAM immediately go OOM.
Don't know if it's suitable for "bigger" machines, though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: udev breakages -

[Felipe Contreras]

On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I don't know how to handle the /dev/ptmx issue properly from within
>> devtmpfs, does anyone?  Proposals are always welcome, the last time this
>> came up a week or so ago, I don't recall seeing any proposals, just a
>> general complaint.
>
> Is it really a problem - devtmpfs is optional. It's a problem for the
> userspace folks to handle and if they made it mandatory in their code
> diddums, someone better go fork working versions.

If only there was a viable alternative to udev.

Distributions are being pushed around by the udev+systemd project
precisely because of this reason; udev maintainers have said that udev
on non-systemd systems is a dead end, so everyone that uses udev
(everyone) is being forced to switch to systemd if they want to
receive proper support, and at some point there might not be even a
choice.

I for one would like an alternative to both systemd and udev on my
Linux systems, and as of yet, I don't know of one.

Cheers.

-- 
Felipe Contreras

Re: udev breakages -

[Alan Cox]

> I don't know how to handle the /dev/ptmx issue properly from within
> devtmpfs, does anyone?  Proposals are always welcome, the last time this
> came up a week or so ago, I don't recall seeing any proposals, just a
> general complaint.

Is it really a problem - devtmpfs is optional. It's a problem for the
userspace folks to handle and if they made it mandatory in their code
diddums, someone better go fork working versions.

Alan

Re: udev breakages -

[Greg KH]

On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote:
> There are still quite a few interesting cases that devtmpfs does not
> even think about supporting.  Cases that were reported when devtmpfs was
> being reviewed. 

Care to refresh my memory?

> Additionally the devtmpfs maintainership has not dealt with legitimate
> concerns any better than this firmware issue has been dealt with.  I
> still haven't even hear a productive suggestion back on the hole
> /dev/ptmx mess.

I don't know how to handle the /dev/ptmx issue properly from within
devtmpfs, does anyone?  Proposals are always welcome, the last time this
came up a week or so ago, I don't recall seeing any proposals, just a
general complaint.

thanks,

greg k-h

Re: udev breakages -

[Eric W. Biederman]

Kay Sievers <kay@vrfy.org> writes:

> If that works out, it would a bit like devtmpfs which turned out to be
> very simple, reliable and absolutely the right thing we could do to
> primarily mange /dev content.

ROFL.

There are still quite a few interesting cases that devtmpfs does not
even think about supporting.  Cases that were reported when devtmpfs was
being reviewed. 

Additionally the devtmpfs maintainership has not dealt with legitimate
concerns any better than this firmware issue has been dealt with.  I
still haven't even hear a productive suggestion back on the hole
/dev/ptmx mess.

As it happens devtmpfs wound up being a userspace process that happens
to reside in the kernel and call mknod.  How it makes sense two layers
of messaging and device management instead of just one I don't know.
Certainly I would not crow about that being a success of anything except
passing the buck.

There is debacle written all over the user space interface for dealing
with devices right now.

Eric

Re: udev breakages -

[Nix]

[Kay removed because I don't like emailing arguable flamebait directly
to the person flamed.]

On 4 Oct 2012, nix@esperi.org.uk stated:

> By udev 175 I, and a lot of other people, had simply stopped upgrading
> udev entirely on the grounds that we could no longer tolerate the
> uncertainty over whether our systems would boot every time we upgraded
> it, for no discernible benefit. Yes, all the incompatible changes are
> (or were, as of udev 175) called out in the release notes -- but there
> are so *many* of them, it's easy to miss one. And they all seem so
> completely unnecessary, and their implications for your system
> configuration grow more and more invasive all the time.

In the bright light of day I realize that this post is not as off-topic
for this thread as it appears. This is all of a piece. The udev
maintainer insists that everyone else adapt to udev's demands: before
now, it has been users, sysadmins, and userspace who must adapt, but now
is is pushing its demands in the other direction as well: this thread is
the result.

-- 
NULL && (void)

Re: udev breakages -

[Nix]

On 3 Oct 2012, Al Viro spake thusly:

> Looks sane.  TBH, I'd still prefer to see udev forcibly taken over and put into
> usr/udev in kernel tree - I don't trust that crowd at all and the fewer
> critical userland bits they can play leverage games with, the safer we are.  
>
> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...

<flamebait type="heartfelt" subtype="fever-induced">

Please! It has already been forked at least once in userspace by people
who have the temerity to *not use systemd*, imagine that! and still want
a udev that is up-to-date in other ways. (We are now being told that,
contrary to what was said when udev was migrated into the systemd tree,
running udev without systemd is now deprecated and untested and might go
away completely. How surprising, nobody ever predicted that when it
migrated in, oh wait yes we did, and were assured that we were wrong,
that standalone udev would always be supported for those of us who
weren't using systemd. Way to destroy your userbase's trust in you...)

Possibly udev 175, the last standalone udev as far as I know, is a good
place to start from: but you might want to go back a release or two
before that, since 174 was where they started doing insane
backward-compatibility breaks. By 175 they were requiring devtmpfs, no
longer creating device nodes (which I thought was the original *point*
of udev), moving lots of install locations on the assumption that / and
/usr were on the same filesystem, and migrating udevd from /sbin into
/lib/udev without bothering to provide a backward-compatibility symlink.
Net benefit of all this thrashing about to udev users: nil. Net sysadmin
overhead on upgrade: substantial, oh and if you don't do it your system
won't boot.

By udev 175 I, and a lot of other people, had simply stopped upgrading
udev entirely on the grounds that we could no longer tolerate the
uncertainty over whether our systems would boot every time we upgraded
it, for no discernible benefit. Yes, all the incompatible changes are
(or were, as of udev 175) called out in the release notes -- but there
are so *many* of them, it's easy to miss one. And they all seem so
completely unnecessary, and their implications for your system
configuration grow more and more invasive all the time.

When gregkh was maintaining udev it was nicely robust and kept working
from release to release, and just did its job without requiring us to
change the way our system booted in backwardly-incompatible ways on
every release, merge filesystems together or mount /usr in early boot
(which is SSH-tunneled over a network in the case of one of my systems,
that was fun to do in the initramfs), or install invasive packages that
extend tentacles throughout the entire system, require a complete
rewriting of my boot process and require millions of kernel features
that may not always be turned on.

I'd like those days back. I can trust the kernel people to maintain some
semblance of userspace compatibility between releases, as is crucial for
boot-critical processes. It is now quite clear that I cannot trust the
present udev maintainers, or anyone else involved in the ongoing Linux
desktop trainwreck, to do any such thing.

</flamebait>

-- 
NULL && (void)