Messages in this thread | | | Date | Wed, 06 Oct 1999 14:24:53 +0200 | From | Marcin Dalecki <> | Subject | Re: USB device allocation |
| |
"H. Peter Anvin" wrote: > > Jeff Garzik wrote: > > > > "H. Peter Anvin" wrote: > > > Actually, the need is for a decent-sized dev_t. > > > > We're still pre-code-freeze... it would be great to change this before > > 2.4.0. > > > > What is a suitable replacement? Comments in asm-i386/posix_types.h, > > where __kernel_dev_t is defined, indicate that GCC cannot be assumed. > > Given that, I guess you can't use 'long long' to promote dev_t to > > 64-bits. > > > > Actually, that's not true -- glibc already uses a 64-bit dev_t, so > that's the logical size. Inside the kernel, the easiest is to make > kdev_t a pair of 32-bit integers. > > -hpa
In fact the biggest obstacle to provide 32 bit long minor major numbers is far much more given by the fact that many of the currently present device driver interfaces inside the kernel are relying on direct knowlendge of the minor number range in charge and direct indexing through it into some sparsely allocated minor device struct pointer array to "simulate different hardware ranges" just to dispatch into different device handlers.
This is fast indeed but it makes it really hard to work around... If one looks closer then one will find that the main problem here is the non homogenity between block sizes and major numbers in linux. (Since this is basically the information hold by the beforementioned arrays.)
In esp. as an example of the problem IDE HD and ATAPI CD-ROM devices should indeed resize on different major numbers and the physical block size should be a property of the device major number instead of a combination between major and minor. Insead of inventing "yet another" driver handler dispatch level.
However still basically this could be done easly. The main problem here would be that any changes would require severe changes in nearly every single device driver, so this is maybe the main reaons why nobody stood up and did it since already about 7 years. Yes if you read the comments around dev_t and MINOR() MAJOR() this had been realized as a problem even druing the very early days of the kernel.
There are some other minor issues involved too but those are the main ones as I see them.
--Marcin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |