Re: IPFilter 4.1.34 with backward compatibility

[Darren Reed <darrenr%netbsd.org@localhost>]

Just to tie up this loose end, this work was completed.

At some point in the near future, I will update NetBSD's
in-tree source code for IPFilter.

http://coombs.anu.edu.au/~avalon/ip_fil4.1.34.tar.gz

Darren

matthew green wrote:
>    matthew green wrote:
>    > hi darren.
>    > 
>    > 
>    > thank you so much for working on this.  it's been 12 years or
>    > more coming (since i first asked anyway :-)
>    > 
>    > i patched my netbsd-current kernel with your changes.  it seems
>    > to mostly work.  i'm having trouble loading ipf rules on 32 bit
>    > platforms.
>    > 
>    > it seems to be 64-bit time-t related.  struct frentry has a
>    > struct timeval, which has changed (on 32 bit only...) struct
>    > frentry{} in 5.0 on i386 is 396 bytes, but 400 in -current.
>    > 
>    > 
>    > fixing this looks really ugly, i'm afraid to say...
>    
>    Hmmm, maybe the thing to do is to put that timeval (and any
>    others) in a union that's 12 bytes in size and bump the version
>    of ipfilter (that will happen anyway before these changes are
>    committed.)
> 
> that probably seems easiest.  i didn't see anything else that
> needs this help -- no other time_t, timeval or dev_t's.
> 
> let me know when you have another patch to try out. :-)  you
> can easily see it on any netbsd 5 userland netbsd-current kernel
> with a 32 bit system.
>    
>    Afterall, the goal isn't to remain backward compat with 5.99.X,
>    only actual releases, such as 5.0.
> 
> yes, that is our (netbsd) goal as well.  (we try to do it for
> -current versions, too, but there's much less care here.)
> 
> thanks.
> 
> 
> .mrg.
> 
> ps: if you're switching stuff around, it may be nice to make
> everything used fixed-size types to help 32bit compat.  we've
> tended to put things into 64 bit items including for pointers.
> i think this one is a harder problem, we should solve after
> the basics work, but if you're already changing something it
> is a good time to make this sort of change as well.  we can
> handle dealing with 32 bit pointers and 32 bit data items
> being converted in netbsd32, but there are nicer ways to avoid
> it...