4.x mbuf binary compatibility; can it be broken?

[Mike Silbersack]

In the process of hunting down reported panics in xl_newbuf, I've come to
the conclusion that the panics are a result of mbuf cluster refcounts
overflowing.  This is not too surprising, as we use an array of chars to
store the refcounts.  (-current uses ints, and doesn't have this problem.)

It's easy enough to switch from a char to an int array in 4.x to fix the
problem there, but there is a problem:  Our friendly mbuf macros (MCLALLOC
and MCLFREE) manipulate the refcount.  This means that 3rd party modules
which use the macros will no longer work properly.

Hence, the question posed on the subject line.  Aside from putting hacks
in many of the mbuf functions so that they avoid reference counts growing
into the danger zone, there's no solution to the problem that I can see.

So, what's our policy on ABI breakage for modules?  It'd be nice to ignore
this problem, but the xl-related PRs filed which seem to describe this
exact problem are too numerous to ignore.  (No, this isn't if_xl's fault;
it's simply a victim because it properly uses its descriptor lists,
thereby using mbuf cluster refcounts rather than packet copies as many
cheaper NICs are required to do.)

Thanks,

Mike "Silby" Silbersack