On Thu, 20 Mar 2003 Andries.Brouwer@cwi.nl wrote:
> There was some unused code, and you decide to start using that
> in order to speed up the open() of a chardev. Is that urgent?
> Is the speed of opening a chardev a bottleneck?
Currently it isn't, but it shouldn't become one?
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. If drivers want to avoid this they have to
implement their own lookup function.
One other major reason for the "unused" code is to convert the 16/32/64bit
dev_t as early as possible to either struct block_device/struct
char_device, so the kernel mostly doesn't care about the dev_t resolution,
the character device core would match here the behaviour of the block
> > Further he introduces a new function register_chrdev_region(),
> > which is only needed by the tty code and rather hides the problem
> > than solves it.
> What does one want? A driver announces the device number regions
> that it wants to cover. Simple and straightforward.
> Hardly a new idea. How is this done for block devices?
> Using blk_register_region(). How is register_chrdev_region()
> hiding problems? It eliminates the tty kludges that you only
> move to a different file.
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.
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.
> > this patch helps drivers to manage them without huge tables
> > (this latter part is also missing in Andries patch).
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/