linux-kernel - Re: [PATCH] Fix capi devicenames

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Sep 2010 14:50:24 +0200
From:	"Marc - A. Dahlhaus" <mad@....de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org,
	isdn@...ux-pingi.de
Subject: Re: [PATCH] Fix capi devicenames

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/