Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Sad. As a user, it's unbelievable to me that these guys have so much time on their hand for childish flamewars.
The sad story of the em28xx driver
Posted Nov 12, 2008 0:45 UTC (Wed) by JoeF (subscriber, #4486)
Posted Nov 12, 2008 13:07 UTC (Wed) by mrec (guest, #41847)
First of all let's start at the beginning and not in the middle of everything.
I agree with Jonathan that many things finally went that way BUT there's some kind of reason for it.
First of all some clarification:
The ownership of the em28xx driver, I have a couple of devices here and I know what's required to get those things work, there are also some requirements about backward compatibility. I don't want to own the em28xx driver, I would like to maintain it since I did that for 3 years already, accepting useful patches giving reviews etc. It could easily be that this was mistaken though.
The userspace driver attempt .. there we go it start's right in the middle of the whole story not taking into account what happened before.
So let's start and add it here:
The whole driver started at the end of 2005, I started to reverse engineer the protocol and worked on it with Luca Risolia(hope I got the name right). We got video, tuning and audio work. At that time nothing was a problem because there were only analog devices available.
At the beginning of 2006 hybrid devices came up and I continued to work on the driver. At this time I faced the problem that the analog and digital TV framework was separated, and there was certainly also some flamewar going on between v4l and the dvb people.
There have been a couple of approaches to solve the technical problem to share 1 component between analog and digital TV (the tuner) back then. My first approach was limited to a specific parameter setting which only allowed to receive some TV channels, I realized that and started over again digging further into the V4L and DVB framework.
I came up with the idea to refactor the tuner stuff in order to be able to use the same tuner code between both v4l and dvb, to make the story short this was declined. During the time while working on it the driver already started supported more and more devices, and that small gap at the beginning became as a base for the entire code, everytime I tried to rework some bits in it it broke alot devices.
So at that point there was already a large codebase depending on it, and a merge request has been sent.
(note this has nothing to do with userspace drivers).
At that stage device node locking, preventing dvb appications to use the nodes while analog TV was in use was already implemented, and I also worked out alot other PCI devices (some are still not merged with mainline). Also quite a few bugs have been fixed in the kernelframework (eg tuner-core) it cost alot time all together and the work didn't get valued at all. So at the end the code basically just got left behind and also during the development noone of those people who were against it was interested to join the core development - I asked several time on IRC, the ML posts didn't get further anyway either.
Just one, I have to write that Michael Krufky was also involved into why it turned bad. When I once asked him about joining that stuff he just told me well but you have it already done.. I wanted to do it.
The whole issues at that time gave him the opportunity to work on his own stuff even more to let the existing em28xx code left behind.
Finally his stuff got merged, bringing my code totally out of sync, and patches which got into mainstream were mostly derived from my code too.
If someone looks at the audio driver, and the patches for the audio driver it's the code I've written, bugfixes to read() for the videoframes the same story but never taking into account all the devices which were supported by the em28xx driver which I worked on constantly.
So now the userspace stuff comes in thinking about how to open up that project again so that work can be used with the existing kernel.
I got around i2c-dev which allows the access of those shared components in userland, the only outstanding gap in order to remain compatible with existing tv apps was to add a small wrapper to resubmit the controls to userspace (sick isn't it?) well partly there are projects out there for BSD which do tuning in userspace. Another point here could be what is a kernelspace driver worth which requires firmware and doesn't come with firmware. At that time there was no single binary driver available from my side anyway, everything has always been opensource (this also has to be considered).
Now continue reading with the article ontop of it.
Posted Nov 12, 2008 22:30 UTC (Wed) by liljencrantz (subscriber, #28458)
Posted Nov 12, 2008 23:57 UTC (Wed) by mrec (guest, #41847)
Someone could dig into the whole topic at least for a week (fulltime).
Jonathan's article is overall ok, but it starts right after the bad things happened when the mood of everyone was already below something good.
Posted Nov 13, 2008 1:35 UTC (Thu) by JoeF (subscriber, #4486)
Let's just agree that you guys disagreed, and move forward.
Posted Nov 14, 2008 23:30 UTC (Fri) by giraffedata (subscriber, #1954)
... it's unbelievable to me that these guys have so much time on their hand for childish flamewars.
It takes very little time to conduct a childish flamewar. In the referenced posting, you suggest that time could be used better to fix bugs. I'll bet they couldn't fix 5% of a device driver bug in the time it takes to write a series of childish flames.
So I think your real objection isn't to the developers' allocation of their time, but to the way they choose to conduct their lives.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds