Subject: Re: ovbcopy
To: None <email@example.com>
From: Perry E. Metzger <firstname.lastname@example.org>
Date: 07/08/2001 09:57:52
> >That will make it easier to deal with when they move to using mem*, as
> >they probably will eventually.
> >I would rather we not do a global ovbcopy macro.
> i don't understand. then why do we have bcopy() macro in sys/systm.h?
To deal with code that has not yet been converted over. The goal is to
convert the rest of the code.
> what is wrong in having both ovbcopy() and bcopy()?
At the time that the macros were inserted, ovbcopy had been purged
completely from the kernel so it was no longer needed. I'm reluctant
to re-add it because that might encourage having new instances
appear. We've already seen new instances of code with bcopy/bzero/bcmp
added by NetBSD hackers unaware that the interface was deprecated.
> if you remove
> bcopy macro right now, i can understand your tactics - but i would
> object to that as it will add lots of diffs in thirdparty kernel code.
> (the key to reduce thirdparty codebase synchronization labor is to
> try to reduce any diffs with the origin)
One of the reasons we never touched the net*/ code when doing the b*
purge was that we were anticipating the KAME integration.
However, KAME has its own include file which is a fine place to put
macros like the ovbcopy->memmove macro. That way, we don't encourage
its use in the wider kernel.
In the medium term, I want to try to assure that FreeBSD and OpenBSD
both have mem*() implemented in their kernels (even if they keep b*())
so as to permit portable code to be written between all three.