Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon <alan.mckinnon@gmail.com>]

On 03/02/2013 16:54, Neil Bothwick wrote:
> This isn't about a lack of convenience, this upgrade WILL break a
> computer that was working beforehand, and not tell the user about it
> until after the damage is done. I'm not saying it is easy to find a
> solution that helps avoid breaking while not inconveniencing others, but
> that is no reason to not try.

OK.

So here's what we have. gentoo-dev thrashed this same conversation to death
with equally ambiguous results. There too a lot of people were saying

"But we shouldn't break user's machines!"

And there was vast consensus about that. The next post invariably said
something like

"We must do <insert current poster's bright idea here>!"

And the reply to that was almost always

"OK hotshot, you covered situation A (coincidentally your situation)>
Now, what about valid situations `seq B J` - *all of which are
supported*. Please provide a plan for those."

And the response to that usually started with "Um..." and didn't
actually contain an answer.

So I say to you

"Neil, what is your solution for all the myriad configurations possible
that DO NOT resemble your own? We know what your preferred solution is,
as you stated it clearly, but I am interested in all those other users
not covered by that. Please provide a well thought out solution that
works for them as well as yours would work for you."

I'll bet good money you come to the same conclusion I did (based on the
conclusions on gentoo-dev)::

- trying to infer something from the current running kernel, or
/usr/src/linux/.config or some magic name in /boot/ is pointless and
leads to so many false positives it isn't worth the effort in the
general case.
- a console message and an elog generated in one of the *pre hooks is
about as good as it gets ...
- ... backed up by a news item before the time so forewarned users are
forearmed users
- the devs did in fact cock up gloriously by omitting all prior
notification and learned a bitter lesson
- whatever the devs do, this version of udev is going to fuck things up
horribly for a lot of people
- despite what Lennart and co will whinge after the fact, the real
problem lies with udev and it's complete lack of any fallback
should DEVTMPFS not be available.

This last one is to my mind crucial. Who cares what kind of filesystem
/dev is mounted as? It's a filesystem, it's not uber-magic. it's a place
where udev can stick it's nodes. If it doesn't have a tmpfs, well then
it can wait till / is mounted and write it's stuff there. udev already
has a guarantee that /dev will exist as soon as / is mounted, even if
/dev is part of /

What's this mandatory tmpfs all about anyway? Why is a userspace daemon
dictating mandatory kernel behaviour, especially regarding something
that, by design (mount points), is supposed to be transparent to
everything under the sun moon earth and stars?

-- 
alan.mckinnon@gmail.com