linux-kernel - Re: [PATCH 31/31] CAPI: Officially claim char major 191

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4B5B0C8A.7090603@web.de>
Date:	Sat, 23 Jan 2010 15:49:46 +0100
From:	Jan Kiszka <jan.kiszka@....de>
To:	Marcel Holtmann <marcel@...tmann.org>
CC:	isdn@...ux-pingi.de, Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, i4ldeveloper@...tserv.isdn4linux.de,
	isdn4linux@...tserv.isdn4linux.de, netdev@...r.kernel.org,
	Alan Cox <alan@...ux.intel.com>
Subject: Re: [PATCH 31/31] CAPI: Officially claim char major 191

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


Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)