Keith M Wesolowski wrote:
> On Tue, Dec 18, 2007 at 11:13:25PM -0500, Richard Lowe wrote:
>
>
>> I'm sure the point's being raised to you in private will be raised to
>> the ARC and the C-Team (out of the fear of precise duplication), and
>> be argued on their technical merit.
>>
>
> Duplication is certainly bad. I was thinking the team should really
> go engage with the other driver's Project Team first, but I couldn't
> find them in the project directory[0]. Did the Device Drivers Group
> create this Project and we just failed to set it up?
>
No. The problem is that the duplication exists between closed entities
and open entities. Unfortunately, I think it will be very difficult to
get David's work past C-Team. As long as C-Team holds the keys to the
vault, it will be hard for anyone to commit anything that someone
believes is contrary to Sun's business interests.
And in this particular case, the problem, as I understand it, that wants
to be avoided is creation of two separate drivers. LSI has an
mpt-workalike, and apparently this has caused Sun and LSI some support
headaches. The management that has to sign off on this particular deal
would probably be happy to accept David's driver, except that
a) fear of features in LSI-written driver missing from Davids causes
customers to choose the unbundled, and possibly alternately named,
driver instead. (Alternate naming in most things is usually a good
thing... but in device drivers it creates major headaches for customers
switching... /etc/path_to_inst and /etc/driver_aliases doesn't cope well
with this at all)
b) a believe (and a desire) that LSI will sustain the LSI provided
code without incurring any additional support burden.
So, Sun wants to leverage the 3rd party's support, and the best way to
do that is to get a blessed driver from them. The problem is that no
such blessed driver has been forthcoming. From what I understand, a
rash of departures in the legal teams at both Sun and LSI have made an
already arduous process even worse.
The sad fact here is, barring a timely resolution from LSI, there is no
*long term* right answer. Almost any approach we take is going to cause
headaches. (And if you thought ipge -> e1000g was bad.... renaming hba
drivers is potentially going to be far far worse, IMO. It's technically
possible to make an upgrade seamless/painless, but it requires a lot of
careful thought on the part of the involved engineers to make sure
/etc/path_to_inst for disks don't differ between the implementations.)
At this point, I actually think Sun should tell LSI to go to hell, the
ship has sailed, and just ship David's code. But that's a personal
opinion, and it should be noted that I probably won't have to support
customers who have to deal with fallout because LSI ships a "better"
(more featureful) driver.
-- Garrett
PS: LSI's inability to play ball with Open Source in general strongly
suggests that folks buying systems might want to think twice before
purchasing products with their chips on them, given any superior
choice. Unfortunately, some Sun systems ship with LSI parts, but at
least we have closed source drivers for those parts. Intel has some
alternatives coming out that are looking pretty good now...
