On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <a...@muc.de> wrote: > Hello, Canek > > On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: >> On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <a...@muc.de> wrote: > >> > The new hardware will "just work" if there are the correct drivers >> >built in. That's as true of udev as it is of mdev as it is of the old >> >static /dev with mknod. > >> No, it is not. You are letting out the sine qua non of the matter: the >> device has to be built, *and the /dev file should exists*. I hope you >> are not suggesting that we put *ALL* the possible files under /dev, >> because that was the idea before devfs, and it doesn't work *IN >> GENERAL*. > > Previously you made appropriate /dev entries with mknod, giving the > device major and minor numbers as parameters. This appeared to work in > general - I'm not aware of any device it didn't work for.
Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. >> 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. > > That happened under the old static /dev system. What was that /dev > system, if not a database matching /dev names to device numbers? I'm not > sure what you mean by "same device" and "same device name". That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. >> 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. > > Early in boot time, you only need things like disk drives, graphic cards > and keyboards. Anything else can be postponed till late boot time. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. >> 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. > > It may be a complicated problem in general, but many people do not need > that generality. ^^^^^ That's your mistake! (IMHO). I explain below. > I suspect the vast majority don't need it. Neither the > typical desktop, the typical server, nor typical embedded devices like > routers. Alan, the "vast majority" of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are "regular" users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. >> I have a really time understanding why you don't see the complexity on >> the problem. I explained above: it is a complicated problem (when >> dealing with the general case), and therefore the (general) solution is >> bound to be also complicated. > > I've had a hard time understanding, because up till now, nobody's > described the problem in detail - there's only been hand-waving. > >> You want it simple? Tha'ts fine, it is possible. It's just that it >> will not solve the general problem, just a very specific subset of it. > > That subset used by the vast majority of Linux users. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. > And yes, I do want > it simple, because elegant simplicity is the best way, IMAO. You, on the > other hand, seem to love complicated solutions because they are "the way > forward". We'll have to agree to disagree on this one. No, it's not a matter of "that's the way forward". It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a solution that in the end will not solve the general problem. Of course, as I have been saying from the beginning, this is OpenSource. Want to pour some effort into solving the simple cases that will not help all the community, and that it will only help in fact a minority, that's your prerogative (and Walt's, and Vapier's, and everyone else that don't like the "complex" but complete solution). Go nuts with it if you want. But please don't dismiss the general solution as "unnecessary" complex when it's not the case, and don't think that the "simple" setups (whatever that means) are the majority. Again, think phones and tablets: those *are* the majority. >> Just as mdev is doing; Walt just posted an email explaining that if >> you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. > > Walter is, I believe, mistaken here. I can mount and use my LVM2 > partitions. Gnome looks like it comes up OK, but that could be moot, > since right now I haven't got keyboard/mouse drivers under the X server. Oh, for sure you can modify LVM2 to work under mdev. Also GNOME/KDE/XFCE, and everything under the sun. You have the source; you can do *anything* you want with it. But the effort wasted^^^^^Hpoured in that excercise will only serve a handful of users, and it will be never accepted upstream, because upstream is (rightfully) concerned with the general problem. Again, this is OpenSource: go nuts with any problem you find "interesting" (I really don't understand why solving a particular case of the general problem will be more interesting that solving the former, but that is maybe the Computer Scientist in me). I'm more interested in the general solution that will work not only for my current machines, but also for the ones I'm planning to have in the future. I'm dying to get a tablet where I can put GNOME 3 on it; I can bet you another beer that mdev will be not enough to handle that. >> I will not be surprised if in the future the list of programs "not for >> mdev" only grows. > > There's a difference between "needed by portage" and "doesn't work under > mdev". As I say, it will all be moot if the evdev driver won't work > under mdev. With all due respect, Alan (and this is completely sincere, in this list you are of the guys I respect the most), I believe you are thinking too small. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. To accomplish that we need udev; mdev it's just not enough. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
