Cleaning up the CDDL import mess

John Baldwin jhb at freebsd.org
Wed Jul 7 21:42:53 UTC 2010


On Wednesday, July 07, 2010 11:20:38 am Rui Paulo wrote:
> On 7 Jul 2010, at 15:12, John Baldwin wrote:
> 
> > I think it should be fine to remove vendor-cddl.  It would be useful to 
get
> > the ZFS bits the correspond to our current ZFS bits committed into the
> > vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the 
merge
> > info.
> > 
> > However, one caveat with the ZFS bits is that we may want to keep ZFS and
> > DTrace independent in that you don't want to have to force an upgrade of 
ZFS 
> > just to get newer DTrace bits and vice versa.  In that sense, it may make 
> > sense to store the vendor DTrace and ZFS bits in separate trees.  I'm not 
sure 
> > how practical that is (e.g. if they share common code).
> 
> ZFS doesn't use any code in the vendor area. It's all imported "by hand" in 
Perforce and then merged to HEAD, "by hand" too. So, unless the ZFS team wants 
to start using real vendor imports instead of what they have been doing, 
there's no such problem as "common code".
> 
> If you are advocating that we should do a vendor import of ZFS, I agree. If 
you're just saying that you want to fix the mergeinfo in ZFS, that is not 
going to be enough because most of the ZFS code is in HEAD, not in the vendor 
branch.

Yes, we would have to do a vendor import of ZFS and then bootstrap the 
mergeinfo.  I am just worried that if both ZFS and DTrace live under 
vendor/opensolaris there may be weird issues with upgrading one part of the 
vendor tree and not the other, but perhaps it will work ok.

> Regarding DTrace, a lot of it has been copied to HEAD without a proper 
vendor import, but some of bits were vendor imported, as you may know.
> 
> What I really wanted to see for DTrace was a real vendor import of all the 
necessary DTrace code, merged all to cddl/contrib and then we would edit 
cddl/contrib to port DTrace to FreeBSD (since DTrace is already ported, we 
would just copy the stuff outside cddl/contrib to cddl/contrib).
> As an example, consider the DTrace module. We have sys/cddl/contrib with 
several headers and whatnot, but the real code lives in sys/cddl/dev/dtrace. 
This is not how we have been doing vendor branches with other external 
contributions. 

Yes, I have noticed this as well.  It should be fixed as you say that we copy 
the FreeBSD changes in head to the original path in the vendor source so we 
can do meaningful merges in the future and generate useful diffs relative to 
the vendor sources.  I think it should be fine to fix this by simply copying 
our version of the file over and committing it as a change in head.

-- 
John Baldwin


More information about the freebsd-arch mailing list