On Sun, Sep 29, 2013 at 12:36:43AM +0200, Alan McKinnon wrote > The actual problem is better stated something like this: > > In the early stages of user-land setup (around the time when udev is > getting it's act together), arbitrary code can run and that code can be > in any arbitrary place, but there is no guarantee that that code is even > accessible at the point when it is needed. The actual cause of this mess > is the lack of standards on where to put stuff on Linux systems, and it > forms a classic bootstrap problem. > > There has only ever been one way around that problem - define an exact > entry point that is guaranteed to be in a specific state. For current > userland this effectively means that everything that has traditionally > been in bin, sbin and lib in / and /usr must be available as step 1. > Technically, you could include /var/lib/ and maybe even /opt in there. > but we can safely exclude those at this time as only a brain-dead moron > would ever put init-critical code there.
Separate /usr worked for many years, even with udev. The question I have is why is udev *NOW* monkeying around with a whole bunch of additional stuff before mounting partitions? If you have an NFS-mounted /usr, I can see needing to have network services running first. Ditto for /usr being in an LVM or encrypted partition, you need LVM and/or decryption running first. There is no excuse for anything else breaking a separate /usr. Then again, separate /usr isn't the first thing Kay Sievers has broken since he took over udev, and I wouldn't be surprised if he one day "just happens to break openrc"... https://lkml.org/lkml/2012/10/2/303 > From Linus Torvalds <> > Date Tue, 2 Oct 2012 09:33:03 -0700 > Subject 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() > On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab > <mche...@redhat.com> wrote: > > > I basically tried a few different approaches, including deferred > > probe(), as you suggested, and request_firmware_async(), as Kay > > suggested. > > Stop this crazy. FIX UDEV ALREADY, DAMMIT. > > Who maintains udev these days? Is it Lennart/Kai, as part of systemd? > > Lennart/Kai, fix the udev regression already. Lennart was the one > who brought up kernel ABI regressions at some conference, and if > you now you have the *gall* to break udev in an incompatible manner > that requires basically impossible kernel changes for the kernel to > "fix" the udev interface, I don't know what to say. > > "Two-faced lying weasel" would be the most polite thing I could say. > But it almost certainly will involve a lot of cursing. > > > However, for 3.7 or 3.8, I think that the better is to revert > > changeset 177bc7dade38b5 and to stop with udev's insanity of > > requiring asynchronous firmware load during device driver > > initialization. If udev's developers are not willing to do that, > > we'll likely need to add something at the drivers core to trick > > udev for it to think that the modules got probed before the probe > > actually happens. > > The fact is, udev made new - and insane - rules that are simply > *invalid*. Modern udev is broken, and needs to be fixed. > > I don't know where the problem started in udev, but the report I > saw was that udev175 was fine, and udev182 was broken, and would > deadlock if module_init() did a request_firmware(). That kind of > nested behavior is absolutely *required* to work, in order to not > cause idiotic problems for the kernel for no good reason. > > What kind of insane udev maintainership do we have? And can we fix it? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
