Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Feb 2012 18:34:35 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Juli Mallett <jmallett@freebsd.org>
Cc:        net@freebsd.org, Brooks Davis <brooks@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it>, Marcel Moolenaar <marcel@xcllnt.net>
Subject:   Re: Abstracting struct ifnet
Message-ID:  <CAJ-Vmo=T28t0XBmzmkNjOEA6wJ-Ub3Bc9DiWu1upDpBt8bM=XA@mail.gmail.com>
In-Reply-To: <CACVs6=_kTVC7tnsPJqgRq3VtUaSefkunVU8JetTdsXjGCmUT7A@mail.gmail.com>
References:  <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <CAJ-Vmoni1DHpxet08=JWSDGLFBP7MHO4-WDBLwX9vGxibR=EDA@mail.gmail.com> <CACVs6=_kTVC7tnsPJqgRq3VtUaSefkunVU8JetTdsXjGCmUT7A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 20 February 2012 18:21, Juli Mallett <jmallett@freebsd.org> wrote:
>
> It's not just about Juniper, though, it's about us, and how much this
> buys us. =A0Using 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. =A0We can't
> make ifnet opaque with inlines. =A0Adding 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=T28t0XBmzmkNjOEA6wJ-Ub3Bc9DiWu1upDpBt8bM=XA>