Bringing the OpenCBM driver into the staging tree

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Frédéric Brière
Date: Saturday, April 17, 2010 - 10:35 am

[I originally sent this message via Gmane, but I think it got gobbled up
somewhere.]


Hi everybody,

I have offered the OpenCBM team a hand in helping them bring their
driver into the (staging, at first) kernel tree.  I have a couple of
technical questions about the whole process, so I sure wouldn't mind
hearing your comments on this.

(The OpenCBM driver allows for communicating with old Commodore
peripherals, via the parallel port and a custom cable.  See
<http://sourceforge.net/projects/opencbm/> for more details.)


Our main concern is that this driver would be rejected by the kernel
maintainers, due to the fact that it busy-waits with interrupts
disabled, for up to 32ms (in the very worst and unlikely case).
Although I have found similar instances in the kernel tree, none of them
disabled interrupts for as long as this.  (The longest was 5ms, by
rs_put_char() in drivers/serial/68328serial.c.)  Unfortunately, this is
the only way to achieve the precise timing required.


If this is deemed acceptable, and the driver can be included, would you
recommend sending a patch ASAP, or doing as much clean-up as possible
beforehand?

Upstream will want to keep maintaining their own copy of the driver for
a while (to support older kernels), which will obviously differ from the
kernel tree version (if only for the gazillion ifdefs).  My concern is
that right after the driver is introduced, somebody will run
checkpatch.pl on it or re-indent it or what-have-you, thus making it
even harder to backport changes from one version to the other.  (OTOH,
I'm aware that waiting for the patch to be perfect before sending it
usually means it will never get sent in the near future.)

Are there any tricks that make it easier to maintain such a pair of
in-tree and out-of-tree drivers?


In a similar vein, as OpenCBM features both Linux and Windows drivers,
the upstream developers were thinking of trying to merge both of them,
to avoid code duplication.  Obviously, this would be incompatible with
introducing a pure Linux driver into the kernel tree.  Again, do you
know of any techniques that would help to keep both in sync?  (I'm
assuming there must be a few Linux drivers out there with a Windows or
FreeBSD sibling.  How do their maintainers cope with this?)


Thanks, and sorry for rambling.  :)


-- 
Actually, typing random strings in the Finder does the equivalent of
filename completion.
		-- Discussion on file completion vs. the Mac Finder
_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Bringing the OpenCBM driver into the staging tree, Frédéric Brière, (Sat Apr 17, 10:35 am)
Re: Bringing the OpenCBM driver into the staging tree, Gary Jennejohn, (Sun Apr 18, 2:40 am)
Re: Bringing the OpenCBM driver into the staging tree, Frédéric Brière, (Sun Apr 18, 5:52 am)
Re: Bringing the OpenCBM driver into the staging tree, Gary Jennejohn, (Sun Apr 18, 9:23 am)
Re: Bringing the OpenCBM driver into the staging tree, Gary Jennejohn, (Sun Apr 18, 9:37 am)
Re: Bringing the OpenCBM driver into the staging tree, Matt Mackall, (Sun Apr 18, 10:22 am)
Re: Bringing the OpenCBM driver into the staging tree, Frédéric Brière, (Sun Apr 18, 10:22 am)
Re: Bringing the OpenCBM driver into the staging tree, Frédéric Brière, (Sun Apr 18, 10:46 am)
Re: Bringing the OpenCBM driver into the staging tree, Matt Mackall, (Mon Apr 19, 3:53 pm)
Re: Bringing the OpenCBM driver into the staging tree, Frédéric Brière, (Thu Apr 22, 2:38 pm)