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
next prev parent 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