From: Greg KH <greg@kroah.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org, akpm@digeo.com
Subject: Re: [PATCH] alternative dev patch
Date: Thu, 20 Mar 2003 17:24:55 -0800 [thread overview]
Message-ID: <20030321012455.GB10298@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0303202314210.5042-100000@serv>
On Fri, Mar 21, 2003 at 12:03:57AM +0100, Roman Zippel wrote:
> I'm unsure how your code will scale. It depends on how that code will be
> used. If drivers register a lot of devices, your lookup function has to
> scan a possibly very long list of minor devices and that function is
> difficult to optimize.
And then we grab the BKL :(
Hint, optimizing the open() path for char devices is not anything we
will probably be doing in 2.6, due to the BKL usage there. It's also
not anything anyone has seen on any known benchmarks as a point of
contention, so I would not really worry about this for now.
For 2.7, when we want to drop the BKL, then we can worry about this.
> char devices don't have partitions, so you hardly need regions. The
> problem with the tty layer is that the console and the serial devices
> should have different majors.
There are a number of char drivers that have "regions". The tty layer
support them, and the usb core supports them as two examples. I'm sure
there are others. Personally, I like the symmetry with the block device
function the way Andries did it.
> Even for block devices blk_register_region() is not the preferred
> interface, you should use alloc_disk/add_disk instead. This will make it
> easier to assign dynamic device numbers later.
True, but dynamic device numbers can be built on top of the *_region()
calls as it is today. Anyway, dynamic numbers are for 2.7 :)
> > I am not sure I understand. Where are these huge tables?
> > And how did you remove them?
>
> See the misc device example. It doesn't have a table, but the list is now
> only needed to generate /proc/misc. As soon as character devices are
> better integrated into the driver model, even this list is not needed
> anymore. This means for simple character devices, we can easily add a
> alloc_chardev/add_chardev interface similiar to block devices.
No, I don't see /proc/misc going away due to the driver model, I imagine
there are too many users of it to disappear. Also, the driver model
doesn't care a thing about major/minor numbers so I don't understand how
you think it can help in this situation.
thanks,
greg k-h
>
> bye, Roman
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2003-03-21 1:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-20 21:50 Andries.Brouwer
2003-03-20 23:03 ` Roman Zippel
2003-03-21 1:24 ` Greg KH [this message]
2003-03-21 9:08 ` Roman Zippel
2003-03-22 1:38 ` Greg KH
2003-03-22 13:02 ` Roman Zippel
2003-03-23 8:19 ` Greg KH
2003-03-23 8:30 ` Christoph Hellwig
2003-03-23 15:05 ` Roman Zippel
2003-03-23 16:32 ` Christoph Hellwig
2003-03-23 8:50 ` Christoph Hellwig
2003-03-23 8:46 ` Christoph Hellwig
2003-03-23 15:11 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2003-03-20 0:57 Roman Zippel
2003-03-20 20:40 ` Roman Zippel
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=20030321012455.GB10298@kroah.com \
--to=greg@kroah.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.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
all inboxes | Powered by JetHome®