linux-kernel - Re: [PATCH] Promise 'stex' driver

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>] [day] [month] [year] [list]

Date:	Tue, 25 Jul 2006 13:30:32 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Ed Lin <ed.lin@...mise.com>
CC:	linux-scsi <linux-scsi@...r.kernel.org>,
	"James.Bottomley" <James.Bottomley@...elEye.com>,
	hch <hch@...radead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm <akpm@...l.org>, promise_linux <promise_linux@...mise.com>
Subject: Re: [PATCH] Promise 'stex' driver

Ed Lin wrote:
> So it seems there are several possibilities here(regarding no.1 comment):
> 1.The bridge code is kept unchanged. And, as this is a violation to
> Linux tradition and requirement, it could not be admitted upstream.
> 2.The code could be modified to be conforming to Linux standard. But,
> we are new to Linux. Maybe we need some specific instructions to know
> how to do it. Sorry if this request becomes annoying.
> 3.Remove the code.
> 
> We are wondering what should we do next. We are seeking the community's 
> help, and advice, something we definitely need.

The normal process for submitting changes to the Linux kernel is by
submitting a series of patches, each containing a single logical set of
changes.  For example:

[PATCH 1/4] stex: white space/ minor fix(INQUIRY, max_channel)
[PATCH 2/4] stex: add new device ids
[PATCH 3/4] stex: update internal copy code path
[PATCH 4/4] stex: add hard reset function

Each patch may be dependent on prior patches.  Each patch should produce
a usable driver, e.g.

patch #1 must produce a usable driver.
patch #1 + #2 must produce a usable driver.
patch #1 + #2 + #3 must produce a usable driver.
patch #2 + #3 (missing patch #1) need not produce a usable driver.

This is analogous to a mathematical proof:  each step in the proof
describes a complete equation.

Therefore, to move forward, I would suggest that you break up your
submitted patch into multiple patches, ordered such that the PCI
bridge-related code is in the final patch.  This permits me to
immediately merge patches not related to PCI bridge stuff, while
simultaneously discussing the hard reset/bridge change.

Note that this is standard iterative development:

	1. 'stex' driver development, testing.
	2. Post a set of 'stex' patches.
	3. Community reviews patches.
	4. Upstream maintainer merges some or all of the patches.
	5. Go to step #1, perhaps to resend (changed or unchanged)
	   the patches that were not merged.

Regards,

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/