Hello networking experts,
I'm one of two engineers working on Solaris 10 Containers (S10Cs), a
project aimed at producing a zone brand that will emulate Solaris 10
user environments in OpenSolaris. (See
http://opensolaris.org/os/project/s10brand for more information.) I'm
going to start evaluating networking within S10Cs in order to discover
which S10 networking behaviors will break in S10Cs.
I suspect that the sweeping changes made to networking in Nevada will be
incredibly difficult to detect and remedy in S10Cs, especially within
exclusive-stack S10Cs. I'm familiar with neither the internals of
Solaris networking nor the networking APIs presented to userland nor the
changes that have caused S10 and Nevada networking to diverge. I
figured that it would be better to consult you first regarding potential
breaks before blindly plunging into a massive evaluation of networking APIs.
The following questions concern me most:
1. Which applications, networking device interfaces, and system calls
are or will most likely be broken in S10Cs?
2. Given the answer to (1), what are the best means of fixing the breakage?
3. Which networking test suites can be run within zones and which will
most likely expose breakage in networking APIs within S10Cs?
We (the engineers working on S10Cs) have a few ways of
solving/circumventing breakages in S10Cs:
1. If a break occurs in a system call (i.e., a fix was integrated into
Neavada (but not S10) that introduced a flag day), then we can [usually]
emulate the old S10 system call by interposing on it within S10Cs.
2. If a break occurs in a device's ioctl interface (ioctl parameters
changed between S10 and Nevada, behaviors changed, etc.), then we have a
few options:
A. Create and push a new streams module on top of the problematic
device from within S10Cs that emulates S10 behaviors.
B. Modify the Nevada version of the device to be more
accommodating of legacy behavior.
C. Enhance emulation of the ioctl system call to detect ioctls
issued to the problematic device and emulate the device's legacy
behavior. (This is the least desirable solution of the three listed here.)
3. If a broken interface is Sun-private or not widely used, then we
might be able to replace binaries that consume the interface with native
Nevada binaries when the branded zone is booted.
4. If all else fails, we can backport the missing/problematic feature
to S10. (This is obviously the least desirable solution.)
Bear in mind that we have to produce S10 networking behaviors not only
for Sun applications but for ISV applications as well. If a broken
networking interface/API is used by ISVs as well as Sun, then simply
replacing Sun S10 binaries with native equivalents will not be satisfactory.
Any feedback you can provide would be greatly appreciated. Any help you
can provide in evaluating networking within S10Cs would also be greatly
appreciated.
Thanks for your time.
Regards,
Jordan
_______________________________________________
networking-discuss mailing list
[email protected]
