Chris G. Demetriou wrote:

> simonb@netbsd.org (Simon Burge) writes:
> > So, is there (still?) anyone against using 32 bit ints inside struct
> > msgbuf on all ports?
> 
> Well, it's pretty much always bogus to used fixed-size types except in
> well-defined cases, of which 'kernel structures' is not one ... but
> what you're proposing is to turn msgbuf into a structure used by a
> protocol.  I'm not particularly keen on it, but it seems like you've
> little choice at this point.

Ok, what about another option:

My plan was to add a sysctl that returns 'struct msgbuf' plus the buffer
after that.  Since we already have a sysctl to return the message buffer
length, what about a separate sysctl that returns just the contents of
the buffer, rearranged if the buffer currently wraps.  This way userland
doesn't need to know about 'strcut msgbuf' at all.

Does this sound like a more reasonable solution?

As for re-use of the buffer with different kernel sizes, we could
introduce a #define in <machine/types.h> for the type of the msgbuf
components.  That way most architectures stay as "long", but
sparc/sparc64 (and perhaps mips) can use "int64_t" or whatever they
fancy.

> > Looking the other way, almost all info that gets written to the message
> > buffer is also dumped on the console (right?), so even on the slowest
> > machines incrementing a 64 bit int should be orders of magnitudes faster
> > than writing a byte to the console.  So this could be one application
> > with the speed isn't (so) important...
> 
> uh, a console may just be a single address in memory, or a ring
> buffer...  The guts of printf() can be much more expensive.  8-)

Yeah, I've already had it pointed out to me.  Not all the world is a
dumb serial console...

Simon.