Re: RFS: opencbm (2nd attempt)
2010/3/1 Frédéric Brière <fbriere@fbriere.net>:
> Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> Frédéric, why are these not upstream on the kernel, and if they are
>> sucky drivers, why not upstream on staging?
>
> My main concern is that because of the strict timing requirements of the
> IEC bus,
What is this IEC bus?
> the module may busy-wait for up to several ms at a time. I
> wonder if that would be deemed as acceptable behavior by the kernel
> maintainers. (Although, grepping through the source, I see there are
> already worse offenders in there.)
Indeed, staging is full of drivers which do quite a lot of terrible
things so you should be fine. The purpose of staging is to help expose
the drivers to a wider audience and get more contributions going.
Stuffing the driver into Debian only won't buy you much except limited
use.
> I agree it would be nice to have this included in the kernel tree, but
> I'd have to ask upstream how they feel about this, as this would require
> freezing the API.
So long as the driver compiles and doesn't require some kernel patches
to modify the kernel itself it should be fine to merge it.
Can you elaborate on the API exposed by this driver. What hooks does
it give userspace if any? Are there a complementary userspace set of
apps based on this driver?
Getting the driver into staging would mean at this point it would be
included part of the 2.6.34 release, so Debian would have to wait a
while until it would have to deal with equivalent distribution kernel
release/driver. The advantage of stuffing it to staging is not for
Debian though, its just what should be done.
> Also, the project provides both a Linux and Windows
> driver, so there may be advantages in keeping them in the same place.
> (I also doubt they would have much time to spare on this, but I'd be
> glad to lend a hand.)
Don't worry about resource considerations, that's what the Linux
driver project is for, it finds resources, volunteers, if it does not
move and get traction it can simply be removed in the long run.
> In any case, would this preclude packaging the module separately up
> until its (possible) inclusion in linux-staging?
I am only familiar with upstream and staging stuff, not with Debian
stuff, subscribed to debian-mentors to post regarding some other
kernel related subjects but figured I'd chime in on this one since it
involves a driver not yet in staging.
Luis
Reply to: