re: IPFilter 4.1.33 with backward compatibility

[matthew green <mrg%eterna.com.au@localhost>]

   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...