Hi HPA, Linus, Alan, On Mon, May 14, 2001 at 12:19:34PM -0700, H. Peter Anvin wrote: > Linus Torvalds has requested a moratorium on new device number > assignments. His hope is that a new and better method for device space > handing will emerge as a result. > > Alan Cox has requested that I maintain a forked registry for his -ac > kernel patch tree. I have agreed to do so once I have forked off the > "final" version of the registry for Linus' tree. [...] I've been following the discussion and would like to throw in my few cents. First of all, I see perfectly Linus' point of disliking the manual maintenance of device numbers. As the current solution is not elegant and requires a lot of work by the device registrar and probably more and more work in the future, this should be replaced by a better - automatic and elegant - mechanism in the future. Point taken. But I'm really surprised reading that the device registry is about to close now. Well, we need the better mechanism, before doing so. At first sight, devfs looks like the solution to this. But, on a second sight, devfs looks like a compromise between a new system, which would completely abstract the details of the underlying hardware and just present the devices from a user interface point of view, and the current system. We get rid of static major/minors, but the naming scheme still imposes to know lots of details about the way your hardware is plugged together. Furthermore, it seems, many people dislike devfs a lot. Instead of fixing a few problems with devfs or (more likely) with devfsd, they seem to believe the concept is fundamentally broken, otherwise their behaviour could only be considered ridiculous. So, we currently don't have a solution to this problem. A lot of good ideas have been proposed in this thread, but no working code that addresses all the issues (autoloading of modules, repeatability of naming, devices needed early in boot stage, ...) is there or was at least designed to a point where implementation is just a question of writing it down. Furthermore, some userspace apps use the major no to determine the exact type of a (otherwise similar) device to decide what functionality to offer or how to implement certain operations. In short: This change breaks currently working things. This can all be fixed, of course, but I doubt it can happen in very short time. To be honest, I fail to believe that such a policy change is happening now, in the middle of a stable kernel series, and I fail to believe that this is really what Linus suggested. IMHO, this policy change affects the kernel more than a major rework of VM, to just give an example. It's very definitely not stuff for 2.4. As far as I know, HPA has not complained about his workload for the manual maintenance of the the LANANA. Currently, it still seems doable, and HPA is doing it, fortunately. Thanks! I've not seen anybody complain about the way he does it either. So, I would be very pleased if we could agree, that it's acceptable to go on with the old manual device registry of HPA for the rest of the 2.4 kernel series. Let's start the new policy with 2.5.1! And please no fork! Every fork splits the community in two parts and basically halves our power. I don't think this would help Linux to be accepted by more people or to be able to be used to solve more problems in a nice and efficient way. I think I do very well understand one of the reasons, why Alan wants to stay with the old scheme. It (still) works. How would you imagine to make a stable Linux distribution, if such a change happens now? I do not think that all apps can be fixed and a stable, reproducible and reliable mechanism to manage device nodes can be introduced within the time frame of 2.4 kernels. Even switching a distro to use devfs only looks easier than this. So, we would need to keep to the old mechanism, if we don't want to risk stability and manageability of a distro. Which is paramount ... I would not like to be forced to use -ac kernels. (Alan, don't get this wrong! It's great that you prepare kernels to test somewhat more experimental features or drivers, but I would like to have the choice.) If we start the new device management with 2.5.1, there's plenty of time to have the mechanism and the kernel stabilize, to get issues like automatic module loading sorted and to adapt distributions before 2.6/3.0 comes out. That's fine with me. Well, maybe you never considered applying this policy change right now within 2.4, Linus. Well, ignore my posting then, if you like. Best regards, -- Kurt Garloff [Eindhoven, NL] Physics: Plasma simulations [TU Eindhoven, NL] Linux: SCSI, Security [SuSE Nuernberg, FRG] (See mail header or public key servers for PGP2 and GPG public keys.)