Subject: Re: 32 bit dev_t, Revision 2
To: None <tech-kern@NetBSD.ORG>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 01/11/1998 19:02:21
> > In both cases, this _particular_ example wouldn't normally cause
> > problems on either the Alpha or the ARM (even with a non-hacked
> > compiler).
> good. that's what i thought.
> > 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-)
> i don't think cpu architectures that break C portability will make much of
> an impression in the marketplace in the next dozen years.
uh, requiring structures to be aligned in a certain way doesn't break
C portability. It might break "portability" of code which cannot be
implemented in portable C, but that's not _really_ portable code, is
> > There's no reason to do it in 'committed' code, so why do it?
> sure there is. opaqueness has lasting value -- i disagree that this is
> just a lint question. "struct in_addr" is still a struct and it keeps
> people from comparing addresses as if they were integers. that opacity
> has kept a huge amount of bad code from being written over the years.
If you truly believe that, then you must agree that the struct-ness of
dev_t should be exported to user-land as well. _that's_ my
disagreement with it being handles as described. It should be the
same in user-land as it is in the kernel, alwasy.
That would solve any kernel vs. user-land binary incompatibility
problems. However, I don't know if that's allowed by various