lkml.org 
[lkml]   [1999]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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