Subject: Re: ovbcopy
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 07/08/2001 15:50:39
[ On Sunday, July 8, 2001 at 16:57:18 (+0900), email@example.com wrote: ]
> Subject: ovbcopy
> i don't understand. then why do we have bcopy() macro in sys/systm.h?
> what is wrong in having both ovbcopy() and bcopy()? 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)
Why will it add lots of diffs? If it does then I would humbly suggest
that you're going about the porting all wrong.
All you need to make NetBSD code portable to other kernels, and vice
versa, is one little macro in one little _private_ header file.
Where you have no influence over the third-party code it would seem
prudent to always create such a private header that can be used to
define the necessary NetBSD portability macros for all the third-party
source modules. The only diffs necessary should therefore be those
needed to include this one private header file! With a bit of careful
planning on the location of these diffs, eg. where existing blank lines
unlikely to be changed or removed by the "vendor" will protect them, CVS
should be able to automate the merging of this one change into every
third-party source file.
I would agree that at no time should any macros used for importing
third-party source code ever be a part of any "standard" NetBSD header
file as that will only encourage their use in NetBSD code.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>