[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 2425) Re: Concerns and questions on the advanced API draft
From:       Matt Thomas <matt () lkg ! dec ! com>
Date:       1996-10-30 20:27:53
[Download RAW message or body]



> Here I am assuming that one might want to add padding at the end
> of the option, if the option data is not 4/8 byte muliple. So that next
> cmsg_hdr can be 4 or 8 byte aligned. So this means that cmsg_len
> includes the length of the padding too.

The option processing in the kernel will do that automagically since it
can determine the alignment of the option from its length.

> I concede that if such an option is not designed then this won't be a 
> problem. But I don't think this is guaranteed.

All options must be defined such that the "stuff" inside must
be order from those the most strict alignment requirements to 
those with the least.

>  > size_t on most 64LP implementations is a long and since the cmsghdr field
>  > cmsg_len is of type size_t, this will force the cmsghdr structure to be
>  > aligned on an alignment that will satisfy size_t.
> 
> Yes, but unfortunately NetBSD/alpha  uses u_int instead of size_t for
> cmsg_len.

Digital UNIX currently has the problem however I felt that the right
thing to do is use the POSIX definitions.  At least until NetBSD fixes
the definition, you have the option of recompiling the kernel with the
right definition.

>  > 
>  > >    Instead we can define that all options be passed in the cmsghdr
>  > >    structure as the current suggestion, but leave the next 4 byte as
>  > >    pad, then put an option which is 8 byte aligned as a full tlv 
>  > >    option.
>  > 
>  > I don't see a need for this given what I said above.
>  > 
>  > >    Or a better thing might be to define a function to add header
>  > >    options in a cmsghdr area, which can be implementation dependent.
>  > 
>  > That's an option but I don't think it's needed.
> 
> I think this option will allow implementations to comply with the
> new draft with minimal changes, i.e. they won't have to change the 
> cmsghdr structure etc., as in my case.

While I "feel your pain", I don't think it is the right solution.  It
adds a level of complexity which is not needed if the O/S is POSIX compliant
(and most are heading that way if not already there).
 
>  > I don't think the scope of the advanced API should cover the needs of
>  > IPv6 stack developers to test their implementation.  
> 
> 	Well I did not mean this. But think if an implementation needs
> more control of the source address, and doesn't want kernel to 
> select one for it. Then it will have to call bind everytime. Also
> you will have to make extra calls to setsockopt in case you want
> to set hop limit etc. 

It does not have to bind, it should use IPV6_TXINFO option which will
allow it to control the source address and/or interface.  Also, now that
the application is "unaware" of the IPv6 header format, adding/changing
it is possible without causing everyone to compile or change their source.

-- 
Matt Thomas                          Internet:   matt@lkg.dec.com
IPv6 Kernel Grunt                    WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          	      http://playground.sun.com/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]