On Sun, Sep 21, 2014 at 10:02 PM, Frank Peters <frank.pet...@comcast.net> wrote: > On Sun, 21 Sep 2014 20:45:17 -0400 > Rich Freeman <ri...@gentoo.org> wrote: >> You can create device nodes using mknod, and I'd be >> shocked if that ever went away. >> > > But now certain static USB nodes, in particular those for > scanners, have been removed in favor of dynamic allocation > using udev or its equivalents. When this happened I was > certainly shocked, and it could be the beginning of a trend.
Fair point, although to some extent this reflects the nature of how modern devices work. Back in the day you had a few serial/parallel ports and you could tell which one was which because they all used different IO ports or IRQs that were hard-coded into the designs. Now you just have one USB host controller which is really the only actual true hardware device on the system and everything that is hooked up to it is virtualized. Plug-and-play really did away with the way device nodes tended to work, and systems like udev are probably the cleanest solution. I for one am happy that I haven't had to configure an IRQ since the 90s. > >> >> Just what is it that you actually >> need the kernel to do for you that you don't think will still be >> around in 20 years? Linus is VERY conservative about removing system >> calls. >> > > There are things which are not system calls that could easily be > changed. It is not too far fetched to consider a time if and when > systemd became so popular and entrenched that the kernel would be > hard-coded to pass control only to systemd and nothing else. That seems extremely unlikely. How many people ran anything other than sysvinit as their init for the 15 years or so before upstart came along? Making the kernel dependent on systemd would defeat the whole purpose of having a separation between userspace and kernelspace. > >> >> If the whole world moves to systemd the biggest problem you'll have is >> that you'll have to write your own service startup scripts, but from >> the sound of things you're doing that anyway. Most of the services >> you probably run aren't linux-exclusive either, so while it seems >> likely that many will start reporting their status to systemd it seems >> unlikely that they will refuse to work without it. >> > > There are a growing number of applications that will no longer compile > without either dbus or udev. In fact, even though I don't use them, > I had to install both eudev and dbus in order to be able to use certain > applications (I just substituted a symlink to /bin/true in place of > dbus-launch to keep that unnecessary daemon from starting). Well, it seems likely that dbus will be a kernel module before long, so it will be readily available. I'm sure there are plenty of programs that don't work if you don't have any number of kernel options disabled. Kdbus is viewed as the future standard mechanism for linux inter-process communication, so programs relying on it should be as surprising as programs that rely on ptys. Much of the issue boils down to the linux world becoming more complex/functional. Back when you could assume that your printer was attached to a parallel port and spoke postscript things were simpler. Today people want to plug in their USB headset and have the computer know to use the USB headset for their teleconference and put the output in the speakers when the phone rings. That just isn't going to work with a world where you output a sound by directing a .au file to a device node. -- Rich
