[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 ...
