* [EMAIL PROTECTED] [20051028T095615]: > >* In various places the document refers to "local zones", though I > > understood we were to avoid using that term, preferring "non-global > > zones". Personally I don't care, though consistency is good. > > Thanks, I didn't know this.
It's worth checking with a Zones guru (which I'm not). > >* The version management of DL_IOC_IPNETINFO seems odd. If an > > application exists that can understand both versions 1 and 2 of the > > ancillary data, how does the application indicate this to the > > observability device? > > > > If ancillary data were always present the kernel could pass upward > > data in the "current" version. If the application doesn't > > understand this, it should fail. This approach would mean that a > > single application might function over several versions of the > > ancillary data. > > In the version scheme version 2 would be an extension of 1 so you > wouldn't need to ask for 1 and 2. I kind-of hate this. It means that the kernel has to be able to generate the ancillary data in multiple formats depending on what the consumer asks for. By the time we get to version 5 this will be a real pain, and quite possibly a performance issue. Having user-level applications that understand multiple versions seems much easier and more flexible than forcing that responsibility onto the kernel. User-level applications are also easier to update and transport between OS versions (e.g. I build my own version of ethereal with version 1-5 support and can then use it on s10uX, s10uY, s11, s12, s13, ...). dme. -- David Edmondson, Solaris Engineering, Sun Microsystems. _______________________________________________ networking-discuss mailing list [email protected]
