<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: hi!
   mchehab: hi syoung, sailus, pinchartl
   <br> anything for today?
   syoung: hi
   hverkuil: <u>mchehab</u>: there are some pending PRs, when do you plan to look at those?
   mchehab: <u>hverkuil</u>: didn't have time yet to look at the patchset you pointed me (that videodev2 sync thing).... has been too busy on my side
   hverkuil: My tentative plan is to go through my pending patches next week for new PRs, so expect more PRs coming next week.
   mchehab: good question. I'm working against the time to solve something internally... I'm hoping to address it until Fri. If so, I'll handle PRs either tomorrow or early next week
   hverkuil: OK. That gives me some idea of what to expect.
   <br> I have WAY too many pending patches :-(
   mchehab: heh :-(
   hverkuil: <u>pinchartl</u>: I'll probably ping you next week about that ti-vpe cal 107-part series :-)
   mchehab: If things get calm here, I'll try to help picking some pending stuff
   <br> <u>syoung</u>: there's a patch addressing config32 stuff for DVB
   <br> not sure if you know much about that...
   <br> basically, when a driver runs on 64 bits, while userspace is on 32 bits, the compat32 code makes the conversion
   <br> (as pointers change their size)
   <br> I didn't tried, but it sounds that the patch is supposed to fix some ioctls
   syoung: I was just going to mention that series
   <br> (looking for the link)
   mchehab: Unbreak 32-bit DVB applications on  64-bit kernels
   <br> (that's the name of the thread)
   syoung: Yes, this is not something I've looked at before.
   pinchartl: <u>hverkuil</u>: sure :-)
   <br> there will be a v2 of the series
   mchehab: with people start using 64 bits on ARM, the compat thing became more important
   <br> (on x86, I guess nobody actually uses the compat32 anymore, in practice, as distros are fasing out support for x86_32)
   hverkuil: <u>pinchartl</u>: do you want me to review v1? Or should I wait for v2? I got 442 patches in my TODO list, so if I can get rid of 107 for now, then that would be nice :-)
   mchehab: funny enough, the series is for Kernel 4.9...
   <br> not sure what's the upstream status with that regards
   syoung: I find it a bit annoying having to review something for ancient kernels, why are we encouraging people to run ancient kernels.
   mchehab: well, just check if upsream is OK, then ;-)
   pinchartl: <u>hverkuil</u>: up to you. it's a bunch of tiny patches, I don't expect any major change to be required
   <br> if you want to have a look at the big picture, you can review v1
   <br> if you want to review all details you can wait for v2, but that may not be the best use of your time
   mchehab: I bet that the port to 4.9 is due to some android or some other embedded hw that uses a platform DVB driver on arm64
   pinchartl: Tomi and Kieran are reviewing the details already
   mchehab: 4.9 is a LTS Kernel
   syoung: Sure 4.9 is an LTS kernel. Still, if you're suddenly interested in compat then you're doing something completely new like run a 64 bit kernel
   hverkuil: <u>pinchartl</u>: would it make sense to split this into two series: one cleanup/refactoring (001-083) and one for the actual MC conversion on top? The first part can probably be merged quite quickly. Up to you, though.
   mchehab: <u>syoung</u>: it is not that easy... right now, I'm stuggling with a 4.9-based kernel, with a driver that were not ported upstream
   <br> (there's an open source version, but on a downstream Kernel, based on Android)
   <br> it even depends on staging android crap
   pinchartl: <u>hverkuil</u>: I'm fine not merging everything in one go, but I'd rather not split the submission in two series
   hverkuil: OK.
   pinchartl: as for MC conversion, it's not a real conversion, it's addition of an optional API. the video node centric API still works as before
   <br> (or better, as there should be a few bug fixes in the series :)-)
   syoung: I realise reality is not that easy, because of all the non-upstream crap. Crap we shouldn't be caring about.
   mchehab: hverkuil, pinchartl: please refrain from sending a PR with too many paches... the mailbomb script has a threshold (something between 50-100 patches), as a protection measure about flooding ML with too many patches
   syoung: Anyway I don't mind reviewing the current state of 32 compat on dvb, and then doing a quick review on the 4.9 rubbish based on that.
   mchehab: well, if you send a PR, I'll just pull it by parts, but still it would be better to have smaller PRs
   <br> <u>syoung</u>: ok, thank you!
   hverkuil: <u>pinchartl</u>: do you expect changes in v2 for patches 001-083?
   syoung: <u>mchehab</u>: I'm pretty busy on all fronts so it'll be next week or late
   mchehab: ok
   hverkuil: ah, probably you will based on Tomi/Kieran review comments.
   mchehab: <u>syoung</u>: my main concern is if upstream is OK or not. depending on what's there, it is possible that the code is just a complete garbage
   pinchartl: <u>hverkuil</u>: yes, small changes and bugfixes
   mchehab: we had to do a large rework on compat32 a few years ago at V4L2 side. We didn't do the same on dvb
   hverkuil: it looks like a lot of the patches from Florian are cleanups/fixes, those can probably be reviewed quite easily.
   mchehab: yeah, it sounds that most of his patches aren't the actual compat32 fixes
   <br> as the DVB core doesn't change much, it may be possible that they would even apply almst cleanly against upstream
   <br> <u>hverkuil</u>: do you remember who wrote the initial compat32 code on that time?
   <br> If my memories are not tricking me...
   hverkuil: I think patch 19/21 is the only patch that does compat32 stuff.
   <br> compat32 code of what? dvb? v4l2?
   mchehab: someone sent a version against an older kernel, and you did the efforts of making it work upstream
   <br> v4l2
   hverkuil: That was not for compat32 support as such, that was to fix a security hole in the v4l2 compat32 code.
   <br> It was v4l2 specific, it didn't affect dvb.
   mchehab: yes, I remember it was due to set_fs() calls at v4l2 compat32 code
   hverkuil: right
   mchehab: dvb doesn't use this, as far as I remember
   <br> but I guess the original set was sent against some older Kernel version or had some other issue...
   <br> and you ended needing to do the work against upstream. right? (or my memories are tricking me?)
   hverkuil: Yes, that's correct. But it was badly done anyway so I believe I just rewrote most (all?) of it.
   mchehab: yes
   hverkuil: this dvb series looks much easier to port to mainline.
   mchehab: hmm.. all patches seem to be backports from upstream...
   <br> as they all seem to contain my SOB
   <br> but in thesis, it should call dtv_set_frontend() only once
   syoung: I'll go through them when I have some time