From: Ben Collins <ben.collins@ubuntu.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH]: How to be a kernel driver maintainer
Date: Sun, 08 Jan 2006 13:27:50 -0500 [thread overview]
Message-ID: <1136744870.1043.4.camel@grayson> (raw)
In-Reply-To: <1136737997.2955.10.camel@laptopd505.fenrus.org>
On Sun, 2006-01-08 at 17:33 +0100, Arjan van de Ven wrote:
> On Sun, 2006-01-08 at 11:07 -0500, Ben Collins wrote:
> >
> > +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 primary code (e.g. if you have a CVS repo for maintaining your
> > code).
> > +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.
>
> I don't quite agree with this part. This encourages cvs use, and "cvs
> mentality". I *much* rather have something written as "the primary
> location of your driver becomes the kernel.org git tree. This may feel
> like you're giving away control, but it's not really. If you maintain
> your driver there, people will still send patches via you for
> approval/review. Of course you can keep a master copy in your own
> version control repository, however be aware that most users will see
> the kernel.org tree one as THE drivers. In addition, merging changes and
> keeping uptodate is a lot harder that way. And worse, keeping the "main"
> version outside the kernel.org tree tends to cause huge deviations and
> backlogs between your main tree and the "real" kernel.org tree, with the
> result that it becomes impossible to find regressions when you DO merge
> the changes over.
But this isn't at al true. Almost all subsystems maintain the primary
tree outside of the kernel, with the kernel being the primary _stable_
tree. USB, Netdev, Alsa, etc. All changes go someplace else before being
pushed to the primary kernel tree. 99% of the time, patches are going
somewhere else before going into the main kernel. So the above
paragraphs is really misleading.
--
Ben Collins <ben.collins@ubuntu.com>
Developer
Ubuntu Linux
next prev parent reply other threads:[~2006-01-08 18:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-08 16:07 [PATCH]: How to be a kernel driver maintainer Ben Collins
2006-01-08 16:33 ` Arjan van de Ven
2006-01-08 18:27 ` Ben Collins [this message]
2006-01-08 18:43 ` Arjan van de Ven
2006-01-08 18:57 ` Arjan van de Ven
2006-01-09 9:51 ` Joel Becker
2006-01-08 21:45 ` [PATCH updated]: " Ben Collins
2006-01-09 7:46 ` Arjan van de Ven
2006-01-09 13:34 ` Ben Collins
2006-01-09 14:02 ` Grant Coady
2006-01-09 21:28 ` Arjan van de Ven
2006-01-10 0:09 ` Linus Torvalds
2006-01-10 0:58 ` Ben Collins
2006-03-08 18:03 ` [Updated]: How to become " Ben Collins
2006-03-08 19:05 ` Jesper Juhl
2006-03-08 19:10 ` Arjan van de Ven
2006-03-08 19:27 ` Jesper Juhl
2006-06-02 21:38 ` [Updated v3]: " Ben Collins
2006-06-02 22:16 ` Randy.Dunlap
2006-06-03 0:03 ` Greg KH
2006-06-05 10:27 ` Jan Engelhardt
2006-03-09 4:32 ` [Updated]: " Randy.Dunlap
2006-01-08 21:47 ` [PATCH]: How to be " Ben Collins
2006-01-09 19:26 ` Pavel Machek
2006-01-10 15:10 ` Ben Collins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1136744870.1043.4.camel@grayson \
--to=ben.collins@ubuntu.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox