On Mar 14, 2012 7:10 AM, "Canek Peláez Valdés" <can...@gmail.com> wrote: >
---- >8 snippage > So, you need something to handle device files on /dev, so you don't > need every possible device file for every possible piece of hardware. > But then you want to handle the same device with the same device name, > so you need some kind of database. Then for the majority of users, > they want to see *something* happen when they connect aa piece of > hardware to their computers. So you need to handle the events > associated with the connections (or discovery, for things like > Bluetooth) of the devices, and since udev is already handling the > database and the detection of connections/discovery, I agree with the > decision of leting udev to execute programs when something gets > connected. You could get that function in another program, but you are > only moving the problem, *and it can also happen very early at boot > time*, so lets udev handle it all the time. > > I hope you see where I'm going. As I said before, mdev could (in > theory) do the same that udev does. But then it will be as complicated > as udev, *because it is a complicated problem* in general. And I again > use my fuel injection analogy: it is not *necessary*. It is just very > damn convenient. > FWIW, mdev is perfectly capable of handling device events, and (optionally) firing an arbitrary script. The way I see it, udev is trying to be everything regarding devices, while mdev is purposefully limiting itself to creating proper nodes under /dev. That (udev's wanting to do *everything*) to me seems counter against the philosophy of Unix-y apps: do one thing, and do it well. And that's why I don't like udev; for it to be able to do everything under the sun, it needs stuffs. Rgds,
