Oliver Yang wrote:
Garrett D'Amore wrote:
Peter Memishian wrote:
> I'd like to have folks review the work at >
http://cr.grommit.com/~gdamore/dmfe_gldv3/webrev
> > * This will make dmfe a DLPI style 1 provider as well. (A
good > thing, IMO, DLPI style 2 is a "bug".)
Yes. FWIW, all the Clearview /dev/net nodes are DLPI style-1 *only*.
Since those will be what applications interact with in the future,
we're on our way to getting rid of "style-2 disease".
> * I'd love to replace the dmfe-custom loopback ioctls with
standards > sys/netlb.h ioctls. However, I'm not sure if any
consumers are going to > be impacted.
IIRC, switching to sys/netlb.h would allow SunVTS coverage.
Yes, I believe that is true. What I'm not sure of, is whether there
is a custom SunVTS module in place for dmfe. (It wouldn't surprise
to learn that there is.) Is SunVTS open sourced? :-)
The lookback test of Sun VTS is quite special. It seems it requires
code changes in Sun VTS for new driver supporting. I'm not sure why?
Does anybody know about it?
The last time I looked, it had a fixed list of drivers, along with some
ioctls. There is supposed to be a "common" ioctl (which is really
derived from the original GEM ioctls) for it, but I still think SunVTS
isn't smart enough to realize whether a driver supports the loopback
ioctls or not.
Another wrinkle is that of course only a few drivers support the netlb.h
ioctls, since they were never formally published anywhere. This is
another tunable that I'd like brussels to just take care of.
Making drivers handle ioctls for every kind of tunable is really, really
ugly. :-)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
