Tracking FreeBSD-CURRENT

Dmitry Salychev dsl at mcusim.org
Thu Sep 3 13:34:37 UTC 2020


Hi Stefan,

> Any new code must be committed to -CURRENT first, before it may be
> merged into the stable branches (and then will make it into a release).

Is this approach the same for code which is intended for ARM? For
example, if there is a driver for an ethernet transceiver connected to
BeagleBone Black. I should track -CURRENT on my laptop, add, build and
test my driver on BBB, merge the latest changes from -CURRENT and send a
patch. Am I correct?

> Since -CURRENT makes no guarantees with regard to kernel interfaces
> and data structures, there is a small risk, that you'll have to adopt
> to changes between when you "froze" your -CURRENT source tree and the
> tree at the time of commit.
>
> Staying current is not much of a problem, though. On my system, the
> "svn up" of the -CURRENT source tree generally finishes in less than
> 10 seconds and "make buildworld" takes only a few minutes, if you
> enable META_MODE - and if there are any collisions you'll notice
> them just when the conflicting changes are fresh and it is easy to
> assess what needs to be done to adapt your code.

It looks like I'd better to have a spare disk for my experiments to
track -CURRENT.

> Definitely not, and I know that some developers fork -CURRENT at
> some suitable point and merge from the official repository only every
> few weeks.
>
> This will obviously not be a good approach, if you are working with
> data structures that are in the process of being significantly modified,
> e.g. to improve the scale-ability of the filesystem or network code.

It shouldn't be a problem because I'd like to program a driver for
Microchip's KSZ9563R (eth switch) which I might only be interested in
:)

Thanks for your help!

Regards,
Dmitry


More information about the freebsd-hackers mailing list