public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: cascardo@holoscopio.com
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <gregkh@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, rubini@gnudd.com
Subject: Re: [PATCH 3/3] misc: use a proper range for minor number dynamic allocation
Date: Wed, 16 Dec 2009 21:14:51 -0200	[thread overview]
Message-ID: <20091216231451.GC7791@holoscopio.com> (raw)
In-Reply-To: <20091215235639.25e841f1@lxorguk.ukuu.org.uk>

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.

  reply	other threads:[~2009-12-16 23:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10  0:30 [PATCH 1/3] misc: clear allocation bit in minor bitmap when device register fails Thadeu Lima de Souza Cascardo
2009-11-10  0:30 ` [PATCH 2/3] misc: use bitmap/bitops functions for dynamic minor number allocation Thadeu Lima de Souza Cascardo
2009-11-10  0:30   ` [PATCH 3/3] misc: use a proper range for minor number dynamic allocation Thadeu Lima de Souza Cascardo
2009-11-10  0:34     ` H. Peter Anvin
2009-11-10 10:19       ` Alan Cox
2009-11-10 16:45       ` Thadeu Lima de Souza Cascardo
2009-11-11 23:36       ` Andrew Morton
2009-12-15 22:34         ` Andrew Morton
2009-12-15 22:42           ` H. Peter Anvin
2009-12-15 22:56             ` Greg KH
2009-12-15 23:56               ` Alan Cox
2009-12-16 23:14                 ` cascardo [this message]
2009-12-16 22:51             ` cascardo
2009-12-15 23:37           ` Alan Cox
2009-12-15 23:41             ` Andrew Morton
2009-12-16 18:01             ` David Teigland
2009-12-16 17:10               ` H. Peter Anvin
2009-12-16 23:21               ` cascardo
2009-12-16 23:05             ` cascardo

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=20091216231451.GC7791@holoscopio.com \
    --to=cascardo@holoscopio.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rubini@gnudd.com \
    /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