From: "Marc - A. Dahlhaus" <mad@wol.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
linux-kernel@vger.kernel.org, isdn@linux-pingi.de
Subject: Re: [PATCH] Fix capi devicenames
Date: Thu, 30 Sep 2010 14:50:24 +0200 [thread overview]
Message-ID: <1285851024.748.97.camel@marc> (raw)
In-Reply-To: <20100930122928.19e5ee84@lxorguk.ukuu.org.uk>
Am Donnerstag, den 30.09.2010, 12:29 +0100 schrieb Alan Cox:
> > In any case devices.txt should be fixed, it has not much to do with
> > the real world.
>
> If some distros chose not to follow devices.txt that is their problem.
>
> devices.txt is the specification, and its ABI.
>
> It is fixed and the kernel behaviour is to follow it. Those who didn't
> follow it, or who didn't propose a change back when it was specified in
> the first place have only themselves to blame.
>
> It isn't changing, and the ISDN code should follow the spec.
>
> How you sort out your userspace is a problem for those who dug holes and
> jumped down them.
Well, i doubt that any distro or hand crafted setup out there is using
anything else than the /dev/capi20 and /dev/capi/[0-9]+ devices for capi
interaction. Because the userspace (libcapi20 & capiinit) handle just
this devices. (i checked debian/ubuntu, fedora rawhide and gentoo and
all are not using other device node names...)
<minorrant>
The only setup that could get broken by this is the setup that uses udev
to handle the devices and gives the nodes different access rights or
something.
And that already happened by the time the rules used to create the capi
devices got removed from udev and it was right to remove them from udev
IMO.
What is a specification in devices.txt worth if nobody actually cares
about it in this case because it has evolved long time ago and nobody
cared to update the devices.txt file by then?
capifs is already deprecated and scheduled for removal soon because udev
is able to replace its functionality and fedora has a patch in srpm that
removes the capifs load from capiinit.
Userspace expects the capifs device nodes.
We are stuck by now. No matter what the specification states,
no setup will work with an up to date version of linux kernel, udev and
isdn4linux userspace now.
</minorrant>
Well, in the end, i don't get it:
How could we brake an already broken thing by fixing an broken
specification and make upstream respect what any distro out there does?
I could send a patch that "fixes" the device names according to the
broken specification in devices.txt and also send a rule for udev to
create symlinks that the userspace expects.
We would get useless kernel suggested devices for capi that nobody needs
because userspace will not use them, period. A well polluted /dev is the
end if this would be the right way to fix this case. Nice, isn't it ;)
I know the rules are made out of noble intends, but IMO the rule will
defeat the logical right fix for the problem that will not brake anyones
setup and there should be exception from the rule for this one case
because the things are how they are now. The spec will not help anyone
out there who is trying to use eg. his B1-ISDN card to receive a
faximile or to provide an old school dial-in access in cases where the
internet carrier is down once the upstream versions are used in the
distros...
Marc
next prev parent reply other threads:[~2010-09-30 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 19:21 [PATCH] Fix capi devicenames Marc - A. Dahlhaus
2010-09-30 9:30 ` Alan Cox
2010-09-30 10:08 ` Kay Sievers
2010-09-30 10:56 ` Alan Cox
2010-09-30 10:37 ` Marc - A. Dahlhaus
2010-09-30 10:50 ` Kay Sievers
2010-09-30 11:29 ` Alan Cox
2010-09-30 12:50 ` Marc - A. Dahlhaus [this message]
2010-09-30 17:35 ` Olivier Galibert
2010-09-30 19:20 ` Kay Sievers
2010-10-01 8:02 ` [PATCH] Fix capi devicenames v2 Marc - A. Dahlhaus
2010-10-01 8:36 ` [PATCH] Fix capi devicenames Marc - A. Dahlhaus
2010-10-01 9:20 ` Kay Sievers
2010-09-30 11:35 ` Alan Cox
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=1285851024.748.97.camel@marc \
--to=mad@wol.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=isdn@linux-pingi.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@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