Jukka Ruohonen <jruohonen%iki.fi@localhost> writes: > On Wed, Jun 05, 2013 at 10:24:34AM -0400, Greg Troxel wrote: >> INET is really INET4. > > Sure; but see below. > >> > #ifdef INET >> > ... >> > #ifdef INET6 >> >> That's a bug; in theory one should be able to have INET6 without INET. >> I did try it once several years ago, and had some trouble that I didn't >> solve. > > Not a single instance. In any case, these again cast a shadow on the > usefulness or quality of some of the #ifdefs, which are perhaps not even > expected to work... or at least contribute to the bitrot that christos also > noted in the commit log. I'm not sure what you're trying to get it. It's clear that there are ifdef bugs, but there may very well not be that many. I suspect there is some code that is needed for INET or INET6 but is only compiled if INET is defined. As for bitrot, it wasn't clear that there actually was any, just a concern that it might be there. I have been compiling with IPSEC_NAT_T enabled on -5, -6 and -current or a long time, and my -current builds do not seem to break more than a few times a week ;-) But seriously, I have not found any build problems in the NAT_T code. The INET and INET6 conditionals do not contribute much to the code bitrot problem, unless there is code that is enabled when they aren't defined and that code has issues. I expect that it's fairly commnon to omit INET6, so we're really talking about !INET. The real decision is how many conditional options to have. The IPSEC_NAT_T code is small, and NAT is regrettably common, so that seems reasoable to fold into IPSEC. But I don't think we should decide to make INET mandatory. (Of course, I don't expect you or anyone else to fix these bugs unless you are in the mood.)
Attachment:
pgp6sXLk1VcNa.pgp
Description: PGP signature