Abstracting struct ifnet
Konstantin Belousov
kostikbel at gmail.com
Tue Feb 21 13:14:28 UTC 2012
On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote:
> 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?
You could take a look how mutexes or vm_page_locks are handled,
giving inlines for kernel proper and stable KBI for modules.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20120221/c7d88eec/attachment.pgp
More information about the freebsd-net
mailing list