Re: [PATCH] alternative dev patch

[Roman Zippel]

Hi,

On Fri, 21 Mar 2003, Greg KH wrote:

> > The BKL also shouldn't be a reason to make it unnecessary expensive? I 
> > don't understand your argument.
> 
> I was trying to point out that pre-mature optimiziation of this code
> should not be done before we get rid of the most expensive portion, the
> bkl.  That's all.

Can we at least note, that my patch has a performance advantage?
We can still deal with the BKL later.
I hope we can agree, that we should avoid adding premature new 
interfaces, which can be expensive later?

> So only tty drivers currently do this.  But that might just be because
> it's pretty hard to get a range of minors right now, as the api hasn't
> been present.  Once we expand the range, I bet it will get quite common
> (most character drivers only want from 1-16 minors normally.)

There are a few options:
1. Drivers can implement that themselves:
a) The driver allocates the major itself and opens the real minor device 
in its open function, (e.g. see the misc driver example). Especially tape 
drivers have to do this anyway, because they encoded the open mode in 
higher bits, so regions won't help you here at all.
b) The driver allocates the major itself and installs the file_operations 
directly in the char_device, e.g. that is something you might want to do 
in the usb driver:

register_usb_device(...)
{
	...
	cdev = cdget(dev);
	down(&cdev->sem);
	if (cdev->fops)
		...;
	cdev->fops = fops;
	up(&cdev->sem);
}
(see the misc driver again for a detailed example.)

2. If it should be really needed, we can add simple region support by 
adding a minor_shift argument to the major device, so get_chrfops() would 
first try (major, minor & ((1 << shift) - 1)), before it tries directly 
(major, 0).

So I really don't see why we should support arbitrary regions, since 
currently nobody needs it and if someone should need it in the future, he 
can easily do it himself.

> > /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.
> 
> I agree.  But again, 2.7.  Remember our feature freeze?

I agree too and nowhere in my patch did I change something about this.

bye, Roman