Subject: Re: 32 bit dev_t, Revision 2
To: None <email@example.com>
From: Ted Lemon <firstname.lastname@example.org>
Date: 01/11/1998 14:10:55
> 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?
(...waiting for the bricks to start flying...)