Peter Memishian wrote:
> > > Far far better, IMO, is to "fix" the main driver this case is for
> > > (cassini), which architecturally could easily be converted to GLDv3 and
> > > bundled into Nevada, and then spend effort to wrap up GLDv3 enough to
> > > publish it for 3rd parties.
> >
> > Completely agree. Adding complexity to GLDv3 to work around a
> > performance issue that exists for one driver seems completely backwards.
>
> It's not just one driver -- until GLDv3 is published, other third-party
> drivers, such as the Fujitsu ones and the SysKonnect ones will need this
> fastpath to preserve performance.
>
> This code is seperable and we will be happy to remove it when it is no
> longer needed. However, until the GLDv3 API is public (which cannot
> happen at least until Crossbow integrates), we need this to preserve
> performance in Nevada.
>
Once it goes in, it will essentially *never* be removable. Because it
will cause regressions for *some* driver (most likely that NSN driver....)
The other vendors will probably be *happy* to convert to GLDv3, if we
just publish the damned API. And I think we're close to it.
Btw, maybe its time to either look at versioning the API, or at least
look at the impact that Crossbow will have on it. I'm not worried about
things that add features, but will Crossbow create incompatible changes
to the driver API (not just enhancements)?
Obviously, I'm not a member of NSN nor of networking (anymore), so my
vote counts for little. But I really think we need to be spending our
time trying to get everyone to use GLDv3. "Enabling" those legacy APIs
means that no one is incentivized to to update, and we'll be carrying
around the baggage until the next major release of Solaris. (SunOS 6.x)
-- Garrett
