The 18/09/11, Duncan wrote: > > I don't see any added benefit from using DBUS on my servers.
Insterstingly, Duncan just answered your question... > Interesting question. I hadn't seen the suggestion until this thread, > either, and it bothered me too. >From here: > With a moment's thought, I decided I could probably return to a semi- > static dev setup reasonably easily. I'd potentially turn on the early-dev > option in the kernel that I still have off, ATM, which presumably would > mount a tmpfs on dev and populate it with the earliest devices. After > that, if necessary, I'd copy the existing udev-created nodes out to a > persistent state dir, and copy them back in with a little init-time > script of my own. As long as the device ordering remains stable, this > could include by-label, etc, symlinks, or I could simply kill the by- > label, by-uid stuff in fstab, and go back to traditional devices there, > too. > > Either that, or simply go back to a static /dev entirely. > > People with dynamic ordered devices may have to devise their own scripts, > tho, or perhaps more likely, fork off udev from the pre-union state. ...to here. > But it's also possible that's far enough in the future that we can't > really answer the question now, since technology will have changed enough > to make an answer now look senseless, then. Consider trying to answer > the question in terms of the kernel devfs back before udev. The tech > simply changed and those answers wouldn't really work, today. Upstream changes the init process is done. So, you're free to either: stick to upstream (with best long term support); or fork off upstream (requires knowledges, manpower and time); or go back to 1960 with a full/partial static /dev (asking to manually maintain the crap). See the benenfit, now? -- Nicolas Sebrecht
