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]

Message-ID: <20100930123537.165375de@lxorguk.ukuu.org.uk>
Date:	Thu, 30 Sep 2010 12:35:37 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Marc - A. Dahlhaus" <mad@....de>
Cc:	linux-kernel@...r.kernel.org, kay.sievers@...y.org,
	isdn@...ux-pingi.de
Subject: Re: [PATCH] Fix capi devicenames

> The Documentation doesn't even represent what is in the code right now.
> kernelcapi.ko creates /dev/capi as the capi control device
> and /dev/capi[0-9]+ for the applications. Documentation states the
> Devices are /dev/capi20 and /dev/capi20.[0-9]+ for applications.

Ok that much needs sorting out.

> Because of this udev removed the possibility to change devicenodes to new names without
> keeping the kernels suggested devicenode name. I hope i got this right.

Not my problem. Udev can do what it likes

> So IMO the documentation is wrong. And also the kernelcapi module is
> wrong about that node it creates.

The problem is that the current default naming is ABI. The fact someone
screwed it up years ago and never fixed it merely makes it worse. At the
very least we need to sort out what the naming should be and support
*both* sets of names for a while. That would I think be an acceptable
path.

> I just want that it works with the latest upstream sources out of the
> box and this isn't the case right now.

That is fine, but I also want it to work on whatever random setups people
have had for the past ten years and on other distros which may be using
the kernel default names.

If we really do have a mess of that scale here then we need to follow the
proper sequence of things for obsoleting an interface, and that is

- Document it
- Add the new one
- Wait a long time
- Remove the old one

Alan
--
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/