Peter Memishian wrote:
> > > 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.
>
> That's not true -- both because the performance of gigabit will become
> less important and easier to satisfy, and because conversion will become
> feasible once APIs are published.
>
I'm sorry, but you must have your head in the ground.
A published API is *not* what is keeping from Cassini from porting to
GLDv3. Until performance of Cassini on current hardware ceases to be a
concern of interest, we will be stuck. Its likely therefore that this
hack will have to live for at least a decade -- until we are able to
EOSL Cassini. (And yes, I know that this is true! I offered to supply
a GLDv3 version of ce to the current management of ce, with a promise of
no perf. regressions or at least negligible perf. regressions, plus
numerous added benefits, for integration into Nevada, and NSN flatly
turned me down. The political cost of a GLDv3 cassini driver is for
reasons not understood to me, far far higher than the actual technical
cost of producing one.)
Get management to buy into a Cassini GLDv3 port, and the other parties
will follow suit. SysKonnect, and Fujitsu could easily get contracts,
or get into uts/closed, if that were important to them, so they could
become part of ON (and thus not need a contract).
I don't think we really care about dropping perf. on those products
anyway, once we have a GLDv3 published.
All that said, the fast path described here *may* be required for S10.
I'm not sure. But I more or less resent the idea of such hackery in Nevada.
-- Garrett
