From: Jan Kiszka <jan.kiszka@web.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: isdn@linux-pingi.de, Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org,
i4ldeveloper@listserv.isdn4linux.de,
isdn4linux@listserv.isdn4linux.de, netdev@vger.kernel.org,
Alan Cox <alan@linux.intel.com>
Subject: Re: [PATCH 31/31] CAPI: Officially claim char major 191
Date: Sat, 23 Jan 2010 15:49:46 +0100 [thread overview]
Message-ID: <4B5B0C8A.7090603@web.de> (raw)
In-Reply-To: <1264256908.3469.58.camel@violet>
[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-01-23 14:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 23:03 [PATCH 00/31] CAPI: Major rework, tons of bug fixes Jan Kiszka
2010-01-06 10:43 ` [PATCH 01/31] CAPI: Fix leaks in capifs_new_ncci Jan Kiszka
2010-01-06 10:47 ` [PATCH 05/31] CAPI: Reduce chattiness during module loading/removal Jan Kiszka
2010-01-06 13:38 ` [PATCH 02/31] CAPI: Sanitize capifs API Jan Kiszka
2010-01-06 13:49 ` [PATCH 03/31] CAPI: Eliminate capifs_root variable Jan Kiszka
2010-01-06 14:03 ` [PATCH 04/31] CAPI: Pin capifs instead of mounting it Jan Kiszka
2010-01-06 18:02 ` [PATCH 07/31] CAPI: Convert capi drivers rwlock into mutex Jan Kiszka
2010-01-06 18:55 ` [PATCH 06/31] CAPI: Call a controller 'controller', not 'card' Jan Kiszka
2010-01-07 10:53 ` [PATCH 08/31] CAPI: Rework capi_ctr_ready/down Jan Kiszka
2010-01-07 11:04 ` [PATCH 10/31] CAPI: Rework locking of controller data structures Jan Kiszka
2010-01-07 12:36 ` [PATCH 11/31] CAPI: Rework application locking Jan Kiszka
2010-01-07 17:42 ` [PATCH 12/31] CAPI: Reduce #ifdef mess around CONFIG_ISDN_CAPI_MIDDLEWARE Jan Kiszka
2010-01-07 18:16 ` [PATCH 13/31] CAPI: Convert capidev_list_lock into a mutex Jan Kiszka
2010-01-07 18:24 ` [PATCH 14/31] CAPI: Clean up capi_open/release Jan Kiszka
2010-01-07 19:12 ` [PATCH 15/31] CAPI: Rework locking of capidev members Jan Kiszka
2010-01-07 19:21 ` [PATCH 16/31] CAPI: Use non-atomic allocation during NCCI setup Jan Kiszka
2010-01-07 19:38 ` [PATCH 17/31] CAPI: Fix racy capi_read Jan Kiszka
2010-01-07 20:52 ` [PATCH 18/31] CAPI: Switch NCCI list to standard doubly linked list Jan Kiszka
2010-01-08 9:45 ` [PATCH 19/31] CAPI: Fix locking around glueing capiminor and capidev Jan Kiszka
2010-01-08 10:38 ` [PATCH 20/31] CAPI: Drop atomic ttyopencount Jan Kiszka
2010-01-08 11:00 ` [PATCH 21/31] CAPI: Remove useless checks for tty->driver_data or hung up state Jan Kiszka
2010-01-08 11:39 ` [PATCH 23/31] CAPI: Rename datahandle_queue -> ackqueue_entry Jan Kiszka
2010-01-08 11:46 ` [PATCH 24/31] CAPI: Use atomics for capiminor's datahandle and msgid Jan Kiszka
2010-01-08 11:57 ` [PATCH 25/31] CAPI: Drop capiminor's unused inbytes counter Jan Kiszka
2010-01-08 12:43 ` [PATCH 26/31] CAPI: Fix locking around capiminor's output queue Jan Kiszka
2010-01-08 12:49 ` [PATCH 27/31] CAPI: Clean up capiminor_*_ack Jan Kiszka
2010-01-08 13:38 ` [PATCH 22/31] CAPI: Rework tty locking in RX and TX path of capiminor Jan Kiszka
2010-01-08 14:11 ` [PATCH 28/31] CAPI: Drop handle_minor_send return value Jan Kiszka
2010-01-10 10:24 ` [PATCH 09/31] CAPI: Rework controller state notifier Jan Kiszka
2010-01-10 13:07 ` [PATCH 29/31] CAPI: Drop special controller lookup from capi20_put_message Jan Kiszka
2010-01-10 13:12 ` [PATCH 30/31] CAPI: Remove experimental tag from middleware feature Jan Kiszka
2010-01-23 12:23 ` Alan Cox
2010-01-23 13:13 ` Jan Kiszka
2010-01-23 13:56 ` Alan Cox
2010-01-10 13:21 ` [PATCH 31/31] CAPI: Officially claim char major 191 Jan Kiszka
2010-01-23 12:24 ` Alan Cox
2010-01-23 12:48 ` Marcel Holtmann
2010-01-23 13:13 ` Jan Kiszka
2010-01-23 14:25 ` Marcel Holtmann
2010-01-23 13:32 ` Karsten Keil
2010-01-23 14:28 ` Marcel Holtmann
2010-01-23 14:49 ` Jan Kiszka [this message]
2010-01-23 9:18 ` [PATCH 00/31] CAPI: Major rework, tons of bug fixes David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B5B0C8A.7090603@web.de \
--to=jan.kiszka@web.de \
--cc=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=i4ldeveloper@listserv.isdn4linux.de \
--cc=isdn4linux@listserv.isdn4linux.de \
--cc=isdn@linux-pingi.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).