Abstracting struct ifnet

[Juli Mallett]

On Mon, Feb 20, 2012 at 18:34, Adrian Chadd <adrian at freebsd.org> wrote:
> Is the target though _binary_ compatibility? Just having a blessed
> method of doing accessor method things will buy more source
> flexibility. The KBI can stay the same in the default case and IMHO
> this kind of thing gives developers more power to do smart invariant
> and debugging things.

KBI compatibility requires very little discipline and makes loadable
modules for network drivers much less hellish.  Inlines, macros and
full visibility of ifnet in -current may be useful, but unless there's
a performance reason for doing so, retaining KBI compatibility *and*
the ability to merge ifnet changes to -stable sounds pretty nice to
me.

> Being able to say "inform me every time an interface flag changes"
> would actually be kind of nice when debugging some of the issues i've
> been facing with ath. I've been half tempted to do this -inside- the
> ath driver, partially to restore the OS portability it once tried to
> achieve.

I think that it is rare that this is useful in debugging, and
something of a red herring.  Even invariants are almost a red herring:
really, we shouldn't be using these individual methods to tweak
structure fields, either, we should have a way of describing a network
driver more semantically, such that the invariants are richer and also
not as complicated, and also more comprehensive.

Source compatibility is the biggest win, but a little self-discipline
to win what measure of binary compatibility we can seems perfectly
sensible.

(And at some point, we could even replace ifnet with something that's
less of a strange grab bag assortment that's awkward to explain to new
driver writers, and keep both source and binary compatibility for a
reasonable period in doing so.  Unlikely to happen in the near term,
but wouldn't it be nice?