Dave Miner writes: > I don't see how it's necessary, for this project's purposes, to > slavishly represent the internals to that degree. There's nothing I saw > in the review that gave any evidence that consumers of this interface > would care about the physical/logical distinction, as all the useful > info is tied to logical interfaces, so why make it harder for the > consumers of the API? Even ifconfig only rarely cares, and you're not > proposing to re-implement ifconfig on this interface, anyway.
I don't think that's one of the possible options. Unfortunately, Solaris makes some odd distinctions in naming addresses as though they were interfaces, and though those distinctions just don't exist on other operating systems and obviously do make the programming interface more complex, they're a crucial part of both the overall programming model and the administrative we have today. So, unless this project is going to rewhack IP so that it represents the interface/address distinction in a different way, I think it needs to remain true to the underlying internals. This was one of the issues I had during ARC review. If not, then you can run into serious problems. For example, unlike any other operating system I know of, a Solaris administrator may refer to a particular address by the name of an IP interface -- e.g., "ce0:5". If you abstract away that distinction for the programming interface, then there's no reasonable way that an application using that interface could deal with such an administrator request. We'd be creating a rift between ipfilter and ifconfig. Maybe that rift is a good thing, but I don't think we ought to stumble into it. We need to have a plan to ditch the current model before we start hobbling it. In other words, as long as we're talking about fundamental APIs, we need to represent the system faithfully, and that means either ripping out the offending abstraction system-wide or leaving it in place. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
