On Fri, Jun 02, 2006 at 05:38:36PM -0400, Ben Collins wrote:
> The real work of maintainership begins after your code is in the tree.
> This is where some maintainers fail, and is the reason the kernel
> developers are so reluctant to allow new drivers into the main tree.
I don't think this is true. On-going maintenance of a driver is quite
minor over time, unless you are adding new support, or if there are bugs
in your driver. We will gladly accept any driver, as long as it follows
the proper coding style rules and plays nice with the rest of the
kernel.
> The other side of the coin is keeping changes in the kernel synced to your
> code. Often times, it is necessary to change a kernel API (driver model,
> USB stack changes, networking subsystem change, etc). These sorts of
> changes usually affect a large number of drivers. It is not feasible for
> these changes to be individually submitted to the driver maintainers. So
> instead, the changes are made together in the kernel tree. If your driver
> is affected, you are expected to pick up these changes and merge them with
> your temporary development copy. Usually this job is made easier if you
> use the same source control system that the kernel maintainers use
> (currently, git), but this is not required. Using git, however, allows you
> to merge more easily.
Almost always, the person doing the API change fixes all in-kernel
versions of the api change. So the driver author/maintainer does not
have to fix up anything.
>
> There are times where changes to your driver may happen that are not the
> API type of changes described above. A user of your driver may submit a
> patch directly to Linus to fix an obvious bug in the code. Sometimes these
> trivial and obvious patches will be accepted without feedback from the
> driver maintainer. Don't take this personally. We're all in this together.
> Just pick up the change and keep in sync with it. If you think the change
> was incorrect, try to find the mailing list thread or log comments
> regarding the change to see what was going on. Then email the patch author
> about the change to start discussion.
>
>
> How should I maintain my code after it's in the kernel tree?
> ------------------------------------------------------------
>
> The suggested, and certainly the easiest method, is to start a git tree
> cloned from the primary kernel tree. In this way, you are able to
> automatically track the kernel changes by pulling from Linus' tree. You
> can read more about maintaining a kernel git tree at
> http://linux.yyz.us/git-howto.html.
I disagree, quilt is _much_ easier for maintaining patches against a
common tree. Combined with ketchup and it makes things dirt simple.
Everything else looks good, very nice job.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
