Hi John,
John Plocher wrote: > [I'm not sure why this is an OGB-Discuss discussion and > not an ARC one...] >> Should be slam dunk to get the mfi putback. > > Without having seen any of the details of this project, there > are two architectural level issues that jump out at me. One > is that of an incompatible change, the other is knowing about > a future train wreck. > > Issue 1: > > On SX, we currently have a mix of open and closed source > components that includes a closed driver for this chipset. Actually, we do not already have a driver of any sort for this chip and card in Open or closed Solaris. David's mfi driver is for the LSI MegaRAID SAS product. The drivers which we already have in Solaris are - lsimega, for the U320 parallel scsi raid controller, and - mpt, for the U160/U320 parallel scsi onboard controller and for the LSI 1064/1068E SAS hbas. Both chip families that mpt controls can do raid. > This project seeks to replace that driver with a different one, > such that some new version of SX will behave differently. > The issue is "what are those differences?" If they are along > the lines of "something that works today will break tomorrow", > then from a systems engineering perspective, we have a problem, > and will need to take steps to address the disconnect. No. The issues start with Sun getting in the way of OpenSolaris having an open, BSD-licensed driver for hardware which is incredibly popular. This "getting in the way" appears to stem primarily from being told by LSI words to the effect of "We're really truly going to sign the appropriate legal agreements real soon now so you can have our megasas driver" ... Those "promises" have been in train for well over a year as far as I am aware. There is, understandably, a great deal of frustration on the part of David and several other involved parties. > Issue 2: > > We know that the current state of the networking stack is > not very friendly to driver changes (renames, multiple > drivers for a single device, ...) - to the point where it > is effectively impossible to mechanize/automate/releasenote > all the steps needed to successfully remove one driver and > replace it with a different one (yes, vanity names will > help lots in this area, but they are not there yet). > > If we have reason to believe that we will have multiple > drivers for the same network device, we know we will end up > with a problem when they both end up in the same system. > Because the system does not (yet) support this situation, > we need to take steps to avoid it. > > What exactly those steps might be is beyond the scope of > this email discussion and into the realm of ARC review. > We all understand the conflicting desires that are in play, > as well as the technical hurdles. Our job is to chart a > course thru them all that gets us to the destination with > the fewest casualties. This second issue is one that has always been on my mind and which I have given some thought to from time to time. I have not, as yet, been able to come up with a mostly foolproof way of working around it. Of course, not actually having LSI's driver has made it rather difficult to even test hypotheses. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
