CAPI: Officially claim char major 191
in [Kernel]
|
Prev: [28/29] perf events: Dont report side-band events on each cpu for per-task-per-cpu events
Next: CAPI: Remove experimental tag from middleware feature
From: Alan Cox on 23 Jan 2010 07:30 On Sun, 10 Jan 2010 14:21:31 +0100 Jan Kiszka <jan.kiszka(a)web.de> wrote: > I found no trace of this mysterious "pcl181" device, neither in-tree nor > out there in the wild. At the same time, the in-tree CAPI middleware is > using major 191 for many years now and obviously without any conflict. > Let's officially claim this major number. This is not the way it should have been done but whoever needs spanking got away with it years ago. Given that this seems the best way forward. With LANANA hat on Acked-by: Alan Cox <alan(a)linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcel Holtmann on 23 Jan 2010 07:50 Hi Alan, > > I found no trace of this mysterious "pcl181" device, neither in-tree nor > > out there in the wild. At the same time, the in-tree CAPI middleware is > > using major 191 for many years now and obviously without any conflict. > > Let's officially claim this major number. > > This is not the way it should have been done but whoever needs spanking > got away with it years ago. Given that this seems the best way forward. > > With LANANA hat on actually in the days of udev, the capifs is not really needed anymore. The right choice would be to remove it. I haven't been enabling it since years. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Kiszka on 23 Jan 2010 08:20 Marcel Holtmann wrote: > Hi Alan, > >>> I found no trace of this mysterious "pcl181" device, neither in-tree nor >>> out there in the wild. At the same time, the in-tree CAPI middleware is >>> using major 191 for many years now and obviously without any conflict. >>> Let's officially claim this major number. >> This is not the way it should have been done but whoever needs spanking >> got away with it years ago. Given that this seems the best way forward. >> >> With LANANA hat on > > actually in the days of udev, the capifs is not really needed anymore. > The right choice would be to remove it. I haven't been enabling it since > years. First of all, the capifs story is orthogonal to the major claim. But basically you are right, capifs is likely not needed anymore. The only user visible change - and that was holding me back to suggest its removal - is the time when the NCCI minor ttys show up under /dev/capi/ (or wherever you direct them to). If I didn't miss something about udev, it will make all possible minors pop up once the major is registered. However, I'm not sure if there is some userland actually relying on this. Jan
From: Karsten Keil on 23 Jan 2010 08:40 On Samstag, 23. Januar 2010 13:48:12 Marcel Holtmann wrote: > Hi Alan, > > > > I found no trace of this mysterious "pcl181" device, neither in-tree > > > nor out there in the wild. At the same time, the in-tree CAPI > > > middleware is using major 191 for many years now and obviously without > > > any conflict. Let's officially claim this major number. > > > > This is not the way it should have been done but whoever needs spanking > > got away with it years ago. Given that this seems the best way forward. > > > > With LANANA hat on > > actually in the days of udev, the capifs is not really needed anymore. > The right choice would be to remove it. I haven't been enabling it since > years. > So far I understand, the pppd capiplugin is the only user of it, so it could be disabled for most users without any problems, as long they are not using PPP connections via CAPI. I never understand capifs very well, I think that it can be dropped because of udev, but maybe need some adjustment in user space as well (make sure that udev did create the node before open it). I f I remember correctly, here was some proposal to replace the /dev/capi/ nodes with devpts, this would remove the complete capi_tty device major as well. Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcel Holtmann on 23 Jan 2010 09:30
Hi Jan, > >>> I found no trace of this mysterious "pcl181" device, neither in-tree nor > >>> out there in the wild. At the same time, the in-tree CAPI middleware is > >>> using major 191 for many years now and obviously without any conflict. > >>> Let's officially claim this major number. > >> This is not the way it should have been done but whoever needs spanking > >> got away with it years ago. Given that this seems the best way forward. > >> > >> With LANANA hat on > > > > actually in the days of udev, the capifs is not really needed anymore. > > The right choice would be to remove it. I haven't been enabling it since > > years. > > First of all, the capifs story is orthogonal to the major claim. my point here is merely that when using udev, you need to fixed assigned major number. Dynamic major numbers will just work fine. > But basically you are right, capifs is likely not needed anymore. The > only user visible change - and that was holding me back to suggest its > removal - is the time when the NCCI minor ttys show up under /dev/capi/ > (or wherever you direct them to). If I didn't miss something about udev, > it will make all possible minors pop up once the major is registered. > However, I'm not sure if there is some userland actually relying on this. That is just an issue with the current code. There is no requirement to create all minors are at the same. You can create/remove minors on demand as you please. And udev will take care of the device nodes for you. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |