lkml.org 
[lkml]   [2003]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] alternative dev patch
Hi,

On Thu, 20 Mar 2003, Greg KH wrote:

> 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 :(

This is currently required for either implementation and needs to be moved
to the driver.

> 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.

The BKL also shouldn't be a reason to make it unnecessary expensive? I
don't understand your argument.

> > 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.

Every single call to usb_register_dev in 2.5.65 uses exactly 1 minor
number. Block device drivers need regions because they have partitions
and we need to find out which device a partition belongs to. Where have
character devices such requirements?

> > 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.

I didn't mean that /proc/misc goes away, I meant the misc_list in misc.c.
They could be other ways to generate /proc/misc.
/proc/devices, /proc/misc, /proc/tty/drivers, ... is currently mostly
needed to generate device nodes for dynamic device numbers. This badly
needs a more generic mechanism.

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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.057 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site