Erik Nordmark wrote:
> Darren Reed wrote:
>
>> I'm submitting this case for myself as a fast track.
>>
>
> Darren,
>
> I'm trying to figure out what assumptions are being made about the
> order that hook users and hook providers appear in the system.
>
> Looking at sample.c I see:
>
> static void
> sample_init(void)
> {
> ipv4 = net_protocol_lookup(GLOBAL_NETID, NHF_INET);
>
>
> Suppose the ISVs sample module somehow is loaded and initialized
> before /kernel/drv/ip. Then the above call would fail, because IP
> hasn't registered in with the netinfo framework.
>
> Since firewall like functionality (a potential user of the netinfo)
> wants to be in place before any IP packets can be sent and received,
> isn't it likely that the 3rd party sample module provider wants their
> module to load before IP? If they do, how does the module get notified
> when IP registers with the netinfo framework?
You've picked up on something I left out, which means I'll need to
update the spec
and resend.
What I left out was providing the means to listen on and receive updates to:
- protocols being added/removed
- events being added/removed
- hooks fpr events being added/removed
> I also have some issues with the description of things which I think
> affect the field names in the data structures as it relates to
> "family". As far as I understand family is the thing that can be
> either "inet" or "inet6". But the material has this text which is
> utterly confusing:
>
>> hook_pkt_event_t
>> ~~~~~~~~~~~~~~~~
>> An extra field has been added to the hook_pkt_event_t structure.
>> The field, hpe_family, is provided to allow the function being called to
>> use this (a net_data_t) value to discover the instance (and thereby
>> zone)
>> to which the event belongs.
>>
>> hook_nic_event_t
>> ~~~~~~~~~~~~~~~~
>> As with hook_pkt_event_t, an extra field, hne_family, has been added to
>> provide more context to the receiver of the event.
>
>
> I don't see how a string like "inet" can be used to tell the
> difference between different IP instances.
>
> In fact the implementation due to hpe_family and hne_family being more
> than just a family - it is a net_data_t. Thus I think the above two
> fields should be renamed to something other than "family", and the
> description clarified. (I think the net_data_t is an opaque handle
> thus it might make sense to have "handle" in the name.)
I called it "family" because it relates to how the implementation fits
together.
If I sit back and look at, like you do, it does seem a rather bizarre
choice of name
given where it appears and how it is used.
A better combination might be to use "net_handle_t" with "hne_protocol" and
"hpe_protocol".
> Finally an important terminology nit. We don't have anything called
> "stack instance" in Solaris. We have IP Instances used by exclusive-IP
> zones. Sticking to that terminology (which is more succinct than
> talking about "stacks") means that all occurances of "stack" in the
> document should be removed or replaced by "instance". (I can edit the
> document for this if you'd like.)
Yup, I understand that - the inclusion of the term "stack instance" was
a mistake.
I should have made a sweep over for that specifically.
Darren
