Evan writes:
> Gary Winiger wrote:
> >> IPv6 NAT for IP Filter
> >>
> >> Overview
> >> ========
> >> This change request aims to provide IPv6 NAT capabilities for IP Filter.
> >> The requested release binding is micro/patch.
> >>     
> >
> >   
> >> Customer impact
> >> ===============
> >> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT 
> >> sessions in kernel needs to rebuild their program due to the changes of
> >> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h.
> >>     
> >
> >     What is the taxonomy of these ioctls.  If it is above Volatile,
> >     how is the incompatible change mitagated for the requested
> >     release binding?
> >
> >   
> 
> It's "External Stable". Does it mean for functionality extension we need to
> provide new ioctl? Are the header files changable? Or we need to provide new
> header files? Can we add new structures into the old header files as long as
> we guarantee that no recompiling action is required for original customers?

        I'm not sure what "External Stable" is, so I'll take it as the
        former Stable which is the current Committed.  And I'll ask again:
        "How is the incompatible change mitagated for the requested Patch
        release binding?"

Darren write:
> There are a few things going on here...
> 1) management isn't interested in investing in a non-ioctl API
>    unless there is significant interest outside of engineering
>    (there is some interest), meaning that internal changes that
>    get reflected in changes to the ioctls either cost engineers
>    a whole bunch of extra work or cause customers a bunch of
>    pain/work;
> 
> 2) the changes to support ipv6 NAT, in the external code base
>    are being made as part of the next major release (4.x -> 5.x)
>    but we're not doing that here...
> 
> Feel free to accost said mangler when he returns O:-)

        I'm not sure what the reasons are, or if they really matter
        unless the architecture is wrong and then I'd leave that up
        to the Case Owner and the Case Submitter to work out before
        submitting the Fast Track.

        I'm asking the naive question presuming the Case Owner has approved
        of the general architecture and that's less up for discussion.
        If ioctls are the wrong architecture, the Case Owner should just
        derail or withdraw the case.

Gary..

Reply via email to