From owner-freebsd-net@FreeBSD.ORG  Wed Aug 18 18:40:56 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 244FB16A4CE; Wed, 18 Aug 2004 18:40:56 +0000 (GMT)
Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net
	[207.115.63.102])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 975F043D62; Wed, 18 Aug 2004 18:40:55 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from elischer.org (adsl-68-124-233-133.dsl.snfc21.pacbell.net
	[68.124.233.133])i7IIep3d155456;	Wed, 18 Aug 2004 14:40:53 -0400
Message-ID: <4123A2B2.2040209@elischer.org>
Date: Wed, 18 Aug 2004 11:40:50 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524
X-Accept-Language: en, hu
MIME-Version: 1.0
To: John Polstra <jdp@polstra.com>
References: <XFMail.20040818112451.jdp@polstra.com>
In-Reply-To: <XFMail.20040818112451.jdp@polstra.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: freebsd-net@freebsd.org
cc: re@freebsd.org
Subject: Re: netgraph only on i386/ia64 - why ?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 18:40:56 -0000

John Polstra wrote:
> On 18-Aug-2004 Julian Elischer wrote:
> 
>>John Polstra wrote:
>>
>>>There is one problem with netgraph on 64-bit platforms.  The ng_msghdr
>>>struct is 52 bytes / 4-byte aligned (see ng_message.h).  That means
>>>the message payload is not well-aligned for 64-bit platforms.  It
>>>would be nice to fix that (and bump NG_VERSION, of course).  Nobody
>>>ever guaranteed that the message payload would be aligned, but it
>>>makes things a lot more convenient.
>>
>>if we do this we should do it now so that we have a consistent ABI from 5.3 on..
>>
>>scott (et al), should we pad an extra 4 bytes in this now?
>>it's low/no risk, but better now than after 5.3 has been released..
> 
> 
> I'd really like to see this change happen.  Julian, would it require
> bumping just NG_VERSION, or should NG_ABI_VERSION change too?
> 
> John

you'd have to change both.. but we alredy have an NG_ABI version change for 5.3
we COULD even hack ng_socket to convert new and old version messages if we 
thought we had people that needed it..

the current structure is:

/* A netgraph message */
struct ng_mesg {
         struct  ng_msghdr {
                 u_char          version;                /*  == NGM_VERSION */
                 u_char          spare;                  /* pad to 2 bytes */
                 u_int16_t       arglen;                 /* length of data */
                 u_int32_t       flags;                  /* message status */
                 u_int32_t       token;                  /* match with reply */
                 u_int32_t       typecookie;             /* node's type cookie */
                 u_int32_t       cmd;                    /* command identifier */
                 u_char          cmdstr[NG_CMDSTRSIZ];   /* cmd string + \0 */
         } header;
         char    data[];                 /* placeholder for actual data */
};

let me see..
1+1+2+4+4+4+4+32.. hmmmm..
yeah ok,,
we could change it to:

/* A netgraph message */
struct ng_mesg {
         struct  ng_msghdr {
                 u_char          version;                /*  == NGM_VERSION */
                 u_char          spare;                  /* pad to 2 bytes */
                 u_int16_t       arglen;                 /* length of data */
                 u_int32_t       flags;                  /* message status */
  ----------->   u_int32_t	spare2;			/* pad to 8 bytes */
                 u_int32_t       token;                  /* match with reply */
                 u_int32_t       typecookie;             /* node's type cookie */
                 u_int32_t       cmd;                    /* command identifier */

                 u_char          cmdstr[NG_CMDSTRSIZ];   /* cmd string + \0 */
         } header;
         char    data[];                 /* placeholder for actual data */
};


I'd put it there in case the flags ever need to expand..

actually maybe bringing 'token' ot 'typecookie' forward so that the flags
would be 64 bit aligned too might be worth it...