| Message ID | 445e1bf881b6f8b6a5886d6eee70f6435a5619d6.1264201408.git.jan.kiszka@web.de |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
On Sun, 10 Jan 2010 14:21:31 +0100 Jan Kiszka <jan.kiszka@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@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Karsten, > > > > 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. PPP connection via CAPI works just fine without capifs. You just need udev to create the device nodes. > 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 am pretty sure that I send a patch for that a long long time ago. I haven been using CAPI + PPP without capifs. > 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. Don't remember anything like this. However extending the kernel code with a CAPI PPP channel type would be better actually. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann wrote: > Hi Karsten, > >>>>> 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. > > PPP connection via CAPI works just fine without capifs. You just need > udev to create the device nodes. > >> 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 am pretty sure that I send a patch for that a long long time ago. I > haven been using CAPI + PPP without capifs. > >> 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. > > Don't remember anything like this. However extending the kernel code > with a CAPI PPP channel type would be better actually. Not sure how much of pppdcapiplugin would have to be moved into the kernel then, but if it allows us to even drop that thing, it might be worth it. In any case, I think we first need a solution for existing user space. So if pppdcapiplugin can be safely considered the only user of /dev/capi/*, I will rework my series to use a dynamic major and will file a patch to first deprecate and then remove capifs. What would be a reasonable warning period? Something like 3 kernel releases? Jan
diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 53d64d3..4dfc2a0 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -403,7 +403,7 @@ Your cooperation is appreciated. 188 = /dev/smbusbios SMBus BIOS 189 = /dev/ussp_ctl User space serial port control 190 = /dev/crash Mission Critical Linux crash dump facility - 191 = /dev/pcl181 <information missing> + 191 = /dev/capi/[0-9]* CAPI 2.0 middleware, NCCI TTYs 192 = /dev/nas_xbus NAS xbus LCD/buttons access 193 = /dev/d7s SPARC 7-segment display 194 = /dev/zkshim Zero-Knowledge network shim control @@ -2618,7 +2618,10 @@ Your cooperation is appreciated. 1 = /dev/kctt1 Second KCT/T card ... -191 char Reserved for PCMCIA +191 char CAPI 2.0 middleware, NCCI TTYs + 0 = /dev/capi/0 TTY for NCCI ID 0 + 1 = /dev/capi/1 TTY for NCCI ID 1 + ... 192 char Kernel profiling interface 0 = /dev/profile Profiling control device
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. CC: Alan Cox <alan@linux.intel.com> Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- Documentation/devices.txt | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)