> 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
compiler).

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
break.  8-)

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
different.)

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
unreasonable.  8-)



chris