On Sat, Apr 17, 2010 at 01:35:50PM -0400, Fr?d?ric Bri?re wrote:
quoted text
> [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.

I'll take anything in staging as long as:
  - the license is acceptable
  - the code builds
  - someone is going to "own" it to help get it merged to the main
    kernel tree eventually.

quoted text
> (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).

Why does it do this?

quoted text
> 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.

Are you sure?

quoted text
> 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?

It's up to you.

quoted text
> 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.)

Again, it's up to you, but I would not recommend maintaining 2 versions
after the code is in the main kernel tree, as it will quickly get quite
hard to do so, as you have pointed out.

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

Don't do it :)

quoted text
> 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?)

They backport the changes that go upstream in Linux to their other
trees.  But it can take a lot of work to do so at times.

thanks,

greg k-h
_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors