Subject: Re: struct msgbuf contents.
To: Simon Burge <firstname.lastname@example.org>
From: Eduardo Horvath <email@example.com>
Date: 06/13/2000 07:57:21
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.