Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752615AbWAHQdZ (ORCPT ); Sun, 8 Jan 2006 11:33:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752619AbWAHQdZ (ORCPT ); Sun, 8 Jan 2006 11:33:25 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:57032 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S1752615AbWAHQdZ (ORCPT ); Sun, 8 Jan 2006 11:33:25 -0500 Subject: Re: [PATCH]: How to be a kernel driver maintainer From: Arjan van de Ven To: Ben Collins Cc: Linux Kernel Development , Linus Torvalds In-Reply-To: <1136736455.24378.3.camel@grayson> References: <1136736455.24378.3.camel@grayson> Content-Type: text/plain Date: Sun, 08 Jan 2006 17:33:17 +0100 Message-Id: <1136737997.2955.10.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Spam-Report: SpamAssassin version 3.0.4 on pentafluge.infradead.org summary: Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1948 Lines: 43 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/