public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	James Bottomley <JBottomley@parallels.com>,
	Christoph Hellwig <hch@lst.de>, Jeff Garzik <jeff@garzik.org>,
	Dave Jiang <dave.jiang@intel.com>,
	Jeff Skirvin <jeffrey.d.skirvin@intel.com>,
	Ed Nadolski <edmund.nadolski@intel.com>,
	Jacek Danecki <jacek.danecki@intel.com>,
	sfr@canb.auug.org.au, David Milburn <dmilburn@redhat.com>,
	hare@suse.de
Subject: Re: [GIT] isci: towards the v3.0 merge candidate
Date: Tue, 7 Jun 2011 10:53:15 +0200	[thread overview]
Message-ID: <20110607085315.GA3794@lst.de> (raw)
In-Reply-To: <1307408765.11482.40.camel@dwillia2-linux>

On Mon, Jun 06, 2011 at 06:06:05PM -0700, Dan Williams wrote:
> The libsas-pending, x86-pending, and subsequently upstream-pending
> branches are now closed with the inclusion of v3.0-rc2 into 'master'.

Can you generate a tree without the merge commits?

> Conspicuously missing is significant progress toward the request to
> merge the isci_ and scic_sds_ level of data structures.  This is mainly
> due to taking a break on the cleanups to knock down bugs and missing
> features, but it also comes back to biting the bullet on more rename
> thrash.  Patches like "isci: remove 'min memory' infrastructure" give me
> pause because they indicate we still have work to do on clarifying the
> data structures and shrinking the number of members (the meat / hard
> work of the cleanup).  A rename is icing (still necessary) at this
> point, but working on closing out bugs before going down that road.
> 
> Questions / suggestions on how to proceed on the cleanup versus bug
> fixing for the 3.0 merge are welcome.

I think we really need to get the main data structures and the naming sorted
out.  Also the development process really would benefit from more frequent
posting of updates.

> Adam Gruchala (1):
>       isci: Added support for C0 to SCU Driver

Please make the silicon revision per-pdev.  Even if you only happen to
one in any given system now this is plain ugly.

> 
> Dan Williams (3):
>       Revert "isci: Add missing PCI IDs"
>       isci: remove 'min memory' infrastructure
>       isci: use pci_map_biosrom
> 
> Dave Jiang (3):
>       isci: removing the kmalloc in smp request construct
>       isci: Retrieve the EFI variable for OEM parameter
>       isci: Removing unused variables compiler warnings
> 
> Edmund Nadolski (10):
>       isci: replace isci_timer list with proper embedded timers

Please don't add those sci_timer wrappers.  del_timer already makes
sure it is cancelled, it just doesn't wait for the execution of
previous timers, so your additional cancel flag doesn't buy anything.


Btw, what bugfixes have you been looking into?  There's basically none
in this update, and given the time it took to get this one out there's
not a whole lot of things in it at all.

>     Revert "isci: Add missing PCI IDs"
>     
>     This reverts commit c2af8ba9.  These ids are reserved for 3rd party
>     vendors to deploy their own drivers.

This sounds wrong.  It's probably the same crap we had with all kinds of
Intel and other vendor cards where some OEM adds value by providing fake
raid and a driver of it's own.  Care to explain how not supporting them
benefits the user?


  parent reply	other threads:[~2011-06-07  8:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07  1:06 [GIT] isci: towards the v3.0 merge candidate Dan Williams
2011-06-07  5:20 ` Stephen Rothwell
2011-06-07  8:53 ` Christoph Hellwig [this message]
2011-06-07 16:54   ` Dan Williams

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=20110607085315.GA3794@lst.de \
    --to=hch@lst.de \
    --cc=JBottomley@parallels.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmilburn@redhat.com \
    --cc=edmund.nadolski@intel.com \
    --cc=hare@suse.de \
    --cc=jacek.danecki@intel.com \
    --cc=jeff@garzik.org \
    --cc=jeffrey.d.skirvin@intel.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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