On 9/4/08, Jarod Wilson <jarod@...> wrote:
> On Thu, 2008-09-04 at 20:06 -0400, Jon Smirl wrote:
> > On 9/4/08, Jarod Wilson <jarod@...> wrote:
> > > Meant to include Janne on the cc list, please keep him in the loop.
> nb: Janne's actually on the list now.
> > > On Thu, 2008-09-04 at 16:21 -0400, Jarod Wilson wrote:
> > > > So a good while back, I talked about submitting all the lirc drivers
> > > > upstream for inclusion in Linus' kernel... Well, I've been a bit busier
> > > > than expected all summer long, and only in this past week have really
> > > > gotten back on the ball. Myself and Janne Grunau have been going back
> > > > over the latest checkpatch output, and as of this afternoon, have it
> > > > spitting out no errors and only four warnings (about use of cvs keyword
> > > > markers, which we can't drop yet). My intention is to submit a patch
> > > > series to lkml no later than this weekend, after smoke-testing a number
> > > > of drivers one last time. The current git tree can be found here:
> > Has LIRC been modified to work with evdev?
> Not that I'm aware of. First up, evdev needs to actually be completely
> usable -- Fedora 9 was initially planning to ship w/it on by default,
> but it caused too many problems, we're trying again with Fedora 10
> (aided by the fact we've hired Peter Hutterer).
> > Is there still a need for the lirc device?
Long run lirc should shift to evdev. There's no reason for it to have
it's own private interface.
> Yes, definitely still a need right now. Some of the usb-based devices
> should ultimately be converted to userspace drivers, but someone needs
> to actually do that. In the mean time, we've got functional kernel-space
> > If sticking with CVS, make sure there aren't any CVS keywords in the
> > files submitted to kernel git. They cause pointless noise in the git
> > kernel history.
> Yep, long-term, that's part of the plan. My current tree has only 4
> left. Wanted to figure out what we're doing w/maintenance first.
> > If sticking with CVS, how are you going to handle CVS having support
> > for multiple kernel versions, and the git version only supporting a
> > single version? This is a pain in DRM drivers and it has to be
> > stripped out every time code is submitted upstream. Very few kernel
> > drivers are maintained outside of the main kernel trees.
> This part is sort of up to Christoph. My personal preference would be to
> only maintain them in git, but that shuts out people who insist on
> running ancient kernels. :)
That is not entirely true, it only shuts out people running ancient
kernels from getting brand new drivers. People running ancient kernels
still have their ancient drivers. Most of the hardware in the kernel
is supported this way.
DRM is one exception, but that is driven more by the fact that is used
in BSD instead of the need to support ancient kernels with new
drivers. Are there others? dvb?
Broad use of git is really reducing the justifications for supporting
ancient kernels. It is very easy now for LIRC to have it's own git
tree. Building a new kernel only takes a few minutes. If you're smart
enough to want to update the version of your LIRC driver you should be
smart enough to update your kernel too.
Another reason for leaving things in CVS is when some of the
developers won't use git. I don't know if that's a problem on LIRC.
> Based on some discussion with a v4l/dvb person or two, I hacked together
> a script that takes the cvs bits and exports them into a git tree, part
> of which is some fugly passes over the code with unifdef to yank the
> compat stuff. It more or less works, so long as the compat stuff is
> properly #ifdef'd.