Subject: Re: ifconfig error handling
To: None <>
From: Daniel Carosone <>
List: tech-net
Date: 08/31/2006 10:45:49
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 30, 2006 at 06:32:57PM -0500, David Young wrote:
> > WAG: so that it will continue processing multiple configuration
> > settings on the one command line, even when an earlier one fails?
> I consider that a bug, also! :-)

Sure, I was guessing only about the original intent. Whether it is
consistent or desirable is a separate question, and it wouldn't
surprise me if it was neither. :-)

In terms of changing it and making it more transactional, the blue-sky
approach would go something like this:

 - ifconfig gets the current interface propdict from the kernel
 - ifconfig parses the command line and fiddles the props to match,
   applying whatever user-level syntax and sanity checking it knows
 - ifconfig passes the modified props back, which the kernel either
   rejects or accepts.  If its rejected, the original props should be
   restored (internally by the kernel) or still current.

In that world, if we decide to accept a transactional nature for the
new interface contract, we should then KASSERT that the props pre- and
post- are the same.

Until then, attempts to make ifconfig command lines atomic based on
sequences of ioctl()s are pretty futile; we can concentrate on
deciding whether ifconfig should try each 'subcommand' independently
or in-order and abort on first failure.  Or at least document and make
more consistent a description of which properties are errors and which
are warnings if they can't be set, perhaps some really aren't vital
even if the current implementation is confused?


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.5 (NetBSD)