Em Tue, 27 Jun 2017 07:38:50 +0200 Ralph Metzler <rjkm@xxxxxxxxxxxxxx> escreveu: > Daniel Scheller writes: > > Am Mon, 26 Jun 2017 11:59:20 +0200 > > schrieb Ralph Metzler <rjkm@xxxxxxxxxxxxxx>: > > > > > Mauro Carvalho Chehab writes: > > > > > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > > > to > > > [...] > > > > change the makefile to: > > > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > > > > > The only detail is that "ddbridge.c" should be renamed to > > > > ddbridge-core.c (or something similar) and some *.h files will > > > > be needed. > > > > > > Hmm, ddbridge -> ddbridge-main would be fine. > > > > Funny, that's exactly the naming I had in mind when thinking about this > > in the past :) > > > > So, I'll propose a rough todo (commit list) for me (I will do and > > care about this) then: > > > > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved > > reordering the functions in the code, this will be repeated with the > > current mainline driver (helps keeping the diff with the actual code > > bump cleaner) > > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do > > it by having multiple objects in the makefile, adding header files > > with prototypes where required > > - 3/4: Bump the driver code with what is already there (means, the > > pre-cleaned variant w/o modulator and netstream/octonet stuff) > > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by > > default Kconf opt, marked EXPERIMENTAL" thing I did to work around > > the still problematic MSI IRQ stuff to let users have a better > > experience) > > > > When done, I'll post the patches for early review, but they'll have a > > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel > > like ripping this out since we want that support anyway). > > > > Additionally,I can do this for dddvb and submit it to the DigitalDevices dddvb > > repository (GitHub Pull Request) so we're at least in-sync wrt > > building the driver. > > > > Ralph, Mauro, are you ok with this? > > I cannot promise which changes I will accept and when. Some will likely break > other things like building the OctopusNet image. > > The public DigitalDevices repository also is not the one I am using for development. > So, changes will first go into our private repository and will only go upstream > for releases. Are there any way where we can help to make easier to synchronize upstream with your internal tree? As Daniel mentioned that he used some scripts, perhaps he can send them for you to run on your tree. Another alternative would be if you could release a "fork" of your development tree before a release, as sort of "release candidate" or something similar, at least while we're taking some efforts to synchronize it with upstream. Thanks, Mauro
