netdev - Re: [GIT]: Networking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Aug 2008 19:33:20 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"John W. Linville" <linville@...driver.com>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT]: Networking

Hi Linus,

> > John was just pointing out (like myself before) that a lot of people are
> > under the impression that documentation updates and new drivers should
> > not be queued up and merged as soon as possible.
> 
> I think (and hey, I'm flexible, and we can discuss this) that the rules 
> should be:
> 
>  - by default, the answer should always be "don't push anything after the 
>    merge window unless it fixes a regression or a nasty bug".
> 
>    Here "nasty bug" is something that is a problem in practice, and not 
>    something theoretical that people haven't really reported.
> 
>  - but as a special case, we relax that for totally new drivers (and that 
>    includes things like just adding a new PCI or USB ID's to old drivers), 
>    because (a) it can't really regress and (b) support for a specific 
>    piece of hardware can often be critical.
> 
> With regard to that second case, I'd like to note that obviously even a 
> totally new driver _can_ regress, in the sense that it can cause build 
> errors, or problems that simply wouldn't have happened without that 
> driver. So the "cannot regress" obviously isn't strictly true, but I 
> think everybody understands what I really mean.
> 
> It should also be noted that the "new driver" exception should only be an 
> issue for things that _matter_.
> 
> For example, a machine without networking support (or without suppoort for 
> a some other really core driver that provides basic functionality) is 
> practically useless. But a machine without support for some particular 
> webcam or support for some special keys on a particular keyboard? That 
> really doesn't matter, and might as well wait for the next release.
> 
> So the "merge drivers early" is for drivers that reasonably _matter_ in 
> the sense that it allows people to test Linux AT ALL on the platform. It 
> shouldn't be "any possible random driver".
> 
> IOW, think about the drivers a bit like a distro would think about 
> backporting drivers to a stable kernel. Which ones are really needed? 
> 
> Also, note that "new driver" really should be that. If it's an older 
> driver, and you need to touch _any_ old code to add a new PCI ID or 
> something, the whole argument about it not breaking falls away. Don't do 
> it. I think, for example, that the SCSI people seem to be a bit too eager 
> sometimes to update their drivers for new revisions of cards, and they do 
> it to old drivers.
> 
> And finally - the rules should be guidelines. It really isn't always 
> black-and-white, but most of the time the simple question of "could this 
> _possibly_ be just queued for the next release without hurting anything" 
> should be the basic one. If the answer is "yes", then wait.

I am perfectly fine with these rules. You only had to spell them out :)

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html