Darren Reed writes:
> - does it give you the access to packets that you need?
>
> - is the ordering mechanism for hooks useful/useless?
>
> - is enough basic infrastructure supplied for you to
> work with and process packets?
>
> - what do you want to do that this won't let you do?
There seem to be some missing parts in the man pages. In particular,
I wasn't able to find definitions of these things, though they're
referred to in the other man pages:
net_protocol_register(9f)
net_protocol_unregister(9f)
net_event_register(9f)
net_event_unregister(9f)
net_ifgetnext(9f)
net_getforwarding(9f)
net_setforwarding(9f)
And some other things seem to be both undefined and not referenced as
man pages:
phy_if_t
net_data_t
net_if_t
My guess is that these are intended to be opaque structures and that
access to the members is provided by certain accessor functions, but I
think it'd help to have a summary somewhere of what those accessors
(and related functions) are. I'd suggest having phy_if(9s),
net_data(9s), and net_if(9s) man pages that explain what the
structures are (without providing the member names) and what utility
functions exist. Otherwise, it's hard to make the connections.
How do zones figure in here? I see no features related to zones, and
I would have expected interfaces that allow one to determine whether a
given net_if_t is within a particular zone, and which zone is the
source or destination of a given packet.
How do net stacks (exclusive IP zones) work? Shouldn't the zone ID be
(in some way) an argument to net_protocol_lookup(9f) so that the right
instance of the network layer protocol is found? I see the
net_callback_t functionality and the netid_t handle, but I don't see
how it relates to either the zone identity or can be used to identify
the separate stack instances. It's not the same net_data_t for two
separate instances of IP, is it?
What about other non-Ethernet features? This doesn't seem to support
tunnels or point-to-point interfaces -- there's no net_getlifdstaddr
function, nor any tsrc/tdst access. Are there any features visible
through the SIOC* ioctls that would be useful here, but that are not
included? If so, what are those things?
Is it possible to invoke L2 (ARP/NDP) look-up? What about getting the
results of a forwarding table look-up? (Is that net_routeto ... ?)
> The create function in the set of callbacks is called after a new instance
> of IP has been created and before any traffic will appear for that instance.
> The only argument to the create function is an identifier that uniquely
> identifies this instance from all others. The return value from the create
> is passed back in as the 2nd argument to the destroy and shutdown functions.
I think you might be missing an iterator here. What happens if a hook
is loaded *after* zones are started? How does such a hook know what
zones are already running when it is installed?
(As far as naming goes, I'm not sure "callback" is a good name for
"stack instance.")
> The word "hint" is used here deliberately as two of the optional hints,
> first and last, may not be continually satisified beyond the initial
> registration of the hook - they only represent the ordering requirement
> at the time of insertion. Furthermore, the "before" and "after" hints
> do not gaurantee "immediately before/after".
Why not? What happens if the hint isn't honored? Is it possible that
correctness is sacrificed?
I think it may well be the case that certain types of hints --
particularly "first" and "last" -- cannot be absolutely guaranteed
without making two users incompatible with each other. But so what?
Is it a bad thing if two hook users can't (by design) be used
together?
For other hints, it's clear that you can always satisfy the condition,
such as a single "before" or "after" hint -- barring any "impossible"
requests. I think those should be defined in such a way that the
condition is guaranteed to hold at all times.
I like the idea that we don't have explicit administrative twiddling
here, and that this new mechanism provides relative control (rather
than relying on some kind of precedence registry), but I'm still a
little fuzzy on the implications of the hook ordering constraints.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 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]
