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). -- John Baldwin _______________________________________________ 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"
