Abstracting struct ifnet

[Adrian Chadd]

On 20 February 2012 18:21, Juli Mallett <jmallett at freebsd.org> wrote:
>
> It's not just about Juniper, though, it's about us, and how much this
> buys us.  Using inlines buys us some source compatibility and the
> ability to add some invariants, but is no different to macros in terms
> of KBI within a version of FreeBSD, or between versions.  We can't
> make ifnet opaque with inlines.  Adding a member to ifnet which is
> opaque[*] and which has the fields most likely to change in size,
> order, existence, etc., and leaving a few that are needed in the fast
> path and will be used by macros/inlines is probably where we should
> end up.
>
> *: Obviously ifnet should be a value member of the opaque type, and
> the ifnet should include a pointer to the opaque type, or something
> like that, since you can't make an opaque struct a value member, which
> is probably obvious, but I wanted to be clearish.

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.

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.



Adrian