Subject: Re: 32 bit dev_t, Revision 2
To: None <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 01/11/1998 16:57:49
> As CGD has explained, we've had severe problems on things like the ARM
> port with this sort of thing, caused by structure alignments being
> different from non-structure alignments.
To be a bit more correct:
We've had significant problems like this on the Alpha (c.f. stat).
We've avoided significant problems like this on the ARM, by using a
gross and disgusting (some would say 'broken') compiler change.
In both cases, this _particular_ example wouldn't normally cause
problems on either the Alpha or the ARM (even with a non-hacked
However, knowing a bit about the wonderful proliferation of wacky CPU
architectures, I've no doubt that there's a system somewhere that it'd
There's no reason to do it in 'committed' code, so why do it?
> You really want to be very
> careful about it. I suggest that this might be reasonable as a device
> for FINDING all the problems during your initial conversion of the
> kernel, but that the committed code should use a uint32.
Actually, the committed code should really use a type which says
"32-bit integer or larger," rather than mandating 32 bits. However,
that's a different issue.
> > 3. Our new dev_t will be split 12 bits major, 20 bits minor. If the top 12
> > bits are zeroes, the dev_t is an "old" device when considering conversion in
> > the kernel.
> Sounds reasonable, though where did you pick 12 and 20 from?
I suggested it, at least. (I don't recall what he was intending to
use before i suggested 12/20. may have been the same, maybe
I like it because it's what a lot of systems I use use, and because I
can think of a use for 20 minor bits which doesn't seem too