svn commit: r222465 - in head/usr.sbin: jail jls

Bjoern A. Zeeb bz at FreeBSD.org
Mon May 30 07:52:29 UTC 2011


On May 30, 2011, at 7:20 AM, Pawel Jakub Dawidek wrote:

> On Sun, May 29, 2011 at 09:03:40PM +0000, Bjoern A. Zeeb wrote:
>> Author: bz
>> Date: Sun May 29 21:03:40 2011
>> New Revision: 222465
>> URL: http://svn.freebsd.org/changeset/base/222465
>> 
>> Log:
>>  Check for IPv4 or IPv6 to be available by the kernel to not
>>  provoke errors trying to query options not available.
>>  Make it possible to compile out INET or INET6 only parts.
> 
> That's interesting. When adding IPv6 support to HAST I was thinking
> about making IPv4/IPv6 support compile options. But after discussing
> this with various folks I decided to always compile IPv4 and IPv6
> support in for userland tools and detect what is supported by the kernel
> at runtime. This way it is easy to just recompile the kernel to
> add/remove IPv4/IPv6 support and userland tools may stay unmodified.
> 
> Do we have some general recommendation within FreeBSD how to handle this
> in userland? (ie. at compile-time or at run-time)

The code by default still compiles for dual-stack usage and dynamically
detects available address families now avoiding errors.

The problem before was that on an IPv6-only kernel you get an error, which
prevents the classic jls command from working:
# jls 
jls: unknown parameter: ip4.addr

Now that works, skipping the unavailable option without erroring.  The problem
here is historical as jails in the early days had the single one mandatory IPv4
address, which now no longer is mandatory or might not even be possible to use. 

In addition to dynamic detection it allows people to reduce the size of the
binary using src.conf like we have supported for compiling out INET6 for ages
for various user space binaries, just that we can compile out one or the other
now.  While possibly less interesting for jail/jls there are still people building
images for very tiny RAM and disk - say very cheap IPv6 only sensor networks
with tens of thousands of nodes and for them every byte might still matter,
Compiling out will also force an address family even on a dual stack kernel.

So having a mix of src.conf options and feature_present(3) gives the full
flexibility for everyone.

Bjoern

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.



More information about the svn-src-all mailing list