On 3/19/15 3:28 AM, Adrian Chadd wrote:
On 18 March 2015 at 08:23, John Baldwin <j...@freebsd.org> wrote:
On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote:
On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin <j...@freebsd.org> wrote:
I do think the normal zone callbacks passed to uma_zcreate() are too public
to change. Or at least, you would need to do some crazy ABI shim where you
have a uma_zcreate_new() that you map to uma_zcreate() via a #define for
the API, but include a legacy uma_zcreate() symbol that older modules can
call (and then somehow tag the old function pointers via an internal flag
in the zone and patch UMA to cast to the old function signatures for zones
with that flag).
I really wasn't clear here. I definitely don't think that changing the
ctor, etc to accept a size_t is MFC'able, and I don't think that the
problem (which is really only theoretical at this point) warrants an MFC to
-stable. I was talking about potentially doing it in a separate commit to
head, but that does leave -stable and head with a different API. This can
be painful for downstream consumers to deal with, which is why I wanted
comments.
I actually think the API change to fix the zone callbacks is fine to change
in HEAD. I don't think that is too disruptive for folks who might be
sharing code across branches (they can use a local typedef to work around
it or some such).
+1. This isn't exposed to userland, right? So I wouldn't worry about.
Kernel progress can't be held back because we're afraid of kernel ABI
changes that fix actual bugs.
I don't think we've ever aid we'd maintain kernel internal ABI across
different code lines.
We have said we'd try keep changes to some things
"easy to fix" (e.g. network driver API) but a recompile is pretty much
always needed.
-adrian
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
