Date: Wed, 21 Dec 2011 22:43:44 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Doug Barton <dougb@FreeBSD.org>, freebsd-current <freebsd-current@FreeBSD.org>, Brooks Davis <brooks@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: r228700 can't dhclient em0 Message-ID: <20111221214344.GA83502@stack.nl> In-Reply-To: <20111220192354.GB70684@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111221214344.GA83502>