> That seems like a ridiculously large space. 4096 major devices is NOT
> that large a space, and no real machine is going to dynamically load
> 2048 device drivers -- devoting half the space to them seems like a
> bad idea. Also, I see no reason at all for this coding mechanism. I
> mean, sure, it reminds you of class A, B, & C IP addresses, but who
> needs it?

Hm.   Depends on how things are done in the future.   Imagine a kernel
where _all_ device drivers are LKMs and are loaded at probe time to do
a probe and then unloaded if the probe doesn't match.   Now do we do
some kind of dynamic MAKEDEV on system startup?   I mention this as a
degenerate case, but it's fairly applicable to the current problem:
should LKM-loaded devices really have major numbers that change
depending on the order in which they are loaded?

I think this question can be legitimately answered "yes" or "no", but
if it's answered "yes", then we need to do some thinking about what
/dev really looks like before diving into an address space split.   I
mean, if LKM major device numbers are dynamically allocated, why not
dynamically allocate major numbers of statically linked devices as
well?   Then you don't need to split this address space at all - just
allocate majors on startup and make /dev dynamic.

On the other hand, why not allocate LKM major numbers statically?   If
you do that, you can have the old standard static /dev and everything
works fine.   Is it really likely that there will be >2048 (or
whatever) LKMified device drivers?   Is it likely that there will be
>4096 drivers in all?

			       _MelloN_

(...waiting for the bricks to start flying...)