On Tue, 13 Jun 2000, Simon Burge wrote:

> Matt Thomas wrote:
> 
> > At 01:19 PM 6/13/2000 +1000, Simon Burge wrote:
> > >Locally, I've changed the members of 'struct msgbuf' from "long" to
> > >"int64_t" to make 'struct msgbuf' compat32 friendly.  I've not had any
> > >problems on either alpha or i386 other than the old msgbuf looking a bit
> > >funny on i386 - I suspect it would fail the magic test on sparc due to
> > >endianness.
> > 
> > That's wrong, IMO.  If anything change them to int32_t.
> 
> I just tried int32_t and it works fine ok.  A 32 bit limit on the size
> of msgbuf obviously shouldn't worry anyone...
> 
> > The overhead of
> > int64 is unacceptable on many of the older platforms.
> 
> Do you have any figures for how a vax or m68k deals with say adding two
> 64bit numbers?

Switching to `int' or `int32_t' is better IMHO.  I wanted to do that back
in 1.4 but got pushback from the alpha port.  Don't know why anyone would
want more than 4GB of message buffer anyway.

> > If you are going to
> > make things compat32 friendly, that's fine.  but don't make things worse
> > for platforms that will never use compat32.
> > 
> > Personally, I think if you are going to run 32bit programs on a 64bit
> > platform, you should expect a little performance hit.
> 
> It's not performance (either way) that I'm worrying about - it's getting
> the data back in a known format regardless of any differences between
> the userland and kernel size.  I'm open to better/easier/quicker-natively
> ways of doing this.

32-bit works fine for that.  In fact it will recycle the *same* message
buffer so you can get messages from both a 32-bit kernel and a 64-bit
kernel in the same msgbuf.

Eduardo Horvath