From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:46:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDD7106566B; Wed, 21 Dec 2011 21:46:38 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8908FC16; Wed, 21 Dec 2011 21:45:36 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 16C19359316; Wed, 21 Dec 2011 22:43:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id DA02628468; Wed, 21 Dec 2011 22:43:44 +0100 (CET) Date: Wed, 21 Dec 2011 22:43:44 +0100 From: Jilles Tjoelker To: Gleb Smirnoff Message-ID: <20111221214344.GA83502@stack.nl> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <20111220192354.GB70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111220192354.GB70684@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-current , Brooks Davis , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 21:46:38 -0000 On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: > Considering r228571: we need to specify vhid as additional address > attribute in atomic manner, via one ioctl(). Address can't be first > configured, and then made redundant, that would lead it to being > static for a short period, sending gratutious ARP announcement, etc. > An assumption that we are not allowed to change ABI for our own tools > strongly discourages bringing in new features :( Consider changing to a more flexible ABI that does not need to be broken for new features. Examples are nmount(2)'s name-value pairs and GEOM's XML topology descriptions. This is initially more work and has poorer performance, but it may well be worth it. Process information reserves space in structures for future extension; this is less flexible but performs better (which matters somewhat). Another consideration is compatibility for 32-bit applications on 64-bit kernels; a good ABI design will minimize the amount of code needed to support that. -- Jilles Tjoelker