James Carlson wrote:
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.
I would agree, if this interface is really being presented as a general
API that will be useful for many consumers to discover the details of
the configuration. That certainly isn't how I read the presentation in
the design document.
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.
I think you're extrapolating my suggestion in the wrong direction. What
value does a consumer of this interface get in understanding the
physical interfaces, and the relationship to the logical? None that I
could come up with on my read through it.
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.
I of course would be happy to see the model change, since it's clumsy in
so many directions, but of course agree that's not this project.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
