public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: "Mukker, Atul" <Atul.Mukker@lsi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Austria, Winston" <Winston.Austria@lsi.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [RFQ] New driver architecture questions
Date: Wed, 13 May 2009 22:44:31 -0400	[thread overview]
Message-ID: <4A0B858F.3080405@garzik.org> (raw)
In-Reply-To: <6C678488C5CEE74F813A4D1948FD2DC7A95E6D37@cosmail02.lsi.com>

Mukker, Atul wrote:
> Hello Kernel experts out there!
> 
>  
> 
> We (a division of LSI Corp.) are planning to initiate a new driver design for future generation of LSI RAID controllers. The new class of RAID controllers would be supported under various operating systems in addition to Linux.
> 
> As part of the revamping exercise, we would like to design the driver in such a fashion that much of the driver source code can be made common across drivers offered for various operating systems.
> 
> The obvious benefits being:
> 
> 1.                   Reduction of feature disparity across various operating systems.
> 
> 2.                   Increased customer satisfaction in terms of support consistency across all available operating systems.
> 
> 3.                   More synergy between the driver team members and increased collaboration.
> 
> 4.                   Decreased overheads in terms of maintenance, fixing issues across the board, defect and change requests tracking etc.
> 
> 5.                   More channelized test engineering.

If the design is done right, everybody wins, absolutely.  Intel has done 
this in the past by making their hw-specific modules generic enough to 
be used across multiple operating systems, while not compromising the 
Linux API guarantees.  See drivers/net/e1000e etc.

We hope, though, that design mistakes from the past can be avoided.  In 
the past, when hardware vendors have created a cross-OS _layer_ for 
their drivers, that layer wound up decreasing performance, increasing 
code size, introducing bugs, and decreasing overall portability.

In the past, cross OS driver layers, developed by hardware vendors for 
specific drivers, have

1. Increased feature disparity between Linux drivers for hardware w/ 
similar capabilities.

2. Decreased customer satisfaction in terms of support consistency 
across all Linux drivers.

3. Decreased synergy and collaboration across Linux drivers and Linux 
engineers, due to increased driver differences.

4. Increased overhead in terms of maintenance, support, and fixing 
issues across multiple Linux drivers, due to wider gulf between Linux 
drivers.

5. Decrease total amount of testing and testing breadth, because less 
shared code means more code to test, and less focused testing.


So it is clear from past experience that the /wrong/ design can hurt 
Linux customers, and it is also clear that the /right/ design, e.g. like 
Intel's network drivers, can be made cross-OS without impacting 
performance, portability or bug hunting.

	Jeff




  reply	other threads:[~2009-05-14  2:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14  1:57 [RFQ] New driver architecture questions Mukker, Atul
2009-05-14  2:44 ` Jeff Garzik [this message]
2009-05-14  3:07   ` Mukker, Atul
2009-05-14  4:16     ` Jeff Garzik
2009-05-14  8:51       ` Boaz Harrosh
2009-05-15  0:58       ` adam radford
2009-05-15  1:01         ` Julian Calaby
2009-05-15  3:01           ` Jeff Garzik
2009-05-15 14:56             ` Mukker, Atul
2009-05-15 16:04               ` James Bottomley
2009-05-15 16:36               ` Matthew Wilcox
2009-05-15 18:03                 ` Mukker, Atul
2009-05-15 18:16                   ` Matthew Wilcox
2009-05-15 18:38                     ` Mukker, Atul

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=4A0B858F.3080405@garzik.org \
    --to=jeff@garzik.org \
    --cc=Atul.Mukker@lsi.com \
    --cc=Winston.Austria@lsi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox