linux-kernel - Re: [PATCH 3/3] misc: use a proper range for minor number dynamic allocation

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: <20091216231451.GC7791@holoscopio.com>
Date:	Wed, 16 Dec 2009 21:14:51 -0200
From:	cascardo@...oscopio.com
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Greg KH <gregkh@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, rubini@...dd.com
Subject: Re: [PATCH 3/3] misc: use a proper range for minor number dynamic
 allocation

On Tue, Dec 15, 2009 at 11:56:39PM +0000, Alan Cox wrote:
> What I have been doing in response to requests for misc device
> allocations is to suggest people simply go and allocate some dynamic
> device space. There are very very few cases a misc device needs a
> specific minor and the large dynamic device space has really made misc a
> "historical" entity which should be treated that way.
> 
> If you want 2048 minors for a random new device, the kernel will just
> magic them for you, udev will magic the device nodes, and the tmpfs will
> handle it nicely
> 
> (and if your udev isn't on its own private file system then I hope its an
> old one, because the current one has a hole in it, which doesn't seem to
> have been fixed yet)
> 
> Alan

I have one "issue" to raise about using anything else: misc devices are
easy to register: they have a class of its own, you don't need to
allocate a range and, then, create the device with its respective file
operations and all that. For one-shot devices, they are really a good
thing.

Does it make sense to create an easier and simpler API for creating
character devices that does not allocate a major with minor 0 and 255
minors which also creates your own class?

I think many device driver writers go for proc filesystem these days
because you just have to call a function with your file name and file
operations and that's it. Most of these people are damn lazy people, I
would agree. But, perhaps, we should make it easier for these lazy
people to write better interfaces. Or perhaps this would spoil them and
they would not do their homework and use the right interface anyway.

I've seen code that should have been using the input subsystem and was
using proc files. And that's why I'm saying they could be spoiled with
such an easy interface. They would still use the wrong interface anyway,
with character devices instead of using the input subsystem.

Well, I'll have a go for such an interface and request comments. It
would not be much different from the misc system anyway, but would allow
more than one device, any (dynamic) major to be used, and a class name
for each registerer.

Regards,
Cascardo.
--
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/