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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.