On Tue, Jun 19, 2007 at 11:47:35AM -0700, Brendan Gregg - Sun Microsystems 
wrote:
> G'Day Dan,

Hello!

<mucho snippage deleted!>

> > We use the concept of a diagnostic code in our PF_KEY enhancements to
> > disambiguate the UNIX EINVAL to great effect.  You could do what we do, and
> > map the diagnostic code to easily-translatable strings in a user-space
> > library!
> 
> Awsome - I can just DTrace ip_drop_packet(). Why didn't I see that before?
> Oh - there is only ONE call to ip_drop_packet() in the whole of ip.c!
> I see 267 freemsg()'s in there! Uhh - have I missed something?

Yes -- this RFE:

6321434 Created P3 kernel/tcp-ip Every dropped packet in IP should
        use ip_drop_packet()

> I'm very happy to use ip_drop_packet() (from what I've just seen it looks
> like the right way). Will the rest of ip.c start using it?

Quite frankly, I'm of the opinion that the above RFE fits in with your
Networking Provider work.  The interface itself (ip_drop_packet() and
friends) may need a bit of enhancement.  I'm more than happy to help with
such architectural changes.

I *do* understand, however, that there's a LOT of scutwork that needs to be
done to make the above RFE happen.  Also, if all of TCP/IP starts using
ip_drop_packet(), initialization, etc. will have to happen earlier in IP.
Right now, ip_drop_init() is done as part of ipsec_stack_init(), and if we
generalize it, we'll have to yank it up a level to IP itself.

Dan
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org

Reply via email to