On Thu, 20 May 2004, Dmitri Denissov wrote:
DD>Currently netgraph code uses splnet/splx to protect timeout calls.
DD>This doesn't work with 5.2 SMP kernel. What is the proper method
DD>here for a custom netgraph node? Is the Giant lock only the way?
Have a lock at the ng_timeout/ng_untimeout fun
On Thu, 20 May 2004, Julian Elischer wrote:
> > This is kind of a bridge, connected to ng_ether interface nodes.
> > Sometimes it queues received packets and later /on a timer
> call or a call
> > from the user space/
> > it re-injects the packets using ng_send_data.
> >
>
> reinjects it to wh
On Thu, 20 May 2004, Dmitri Denissov wrote:
> This is kind of a bridge, connected to ng_ether interface nodes.
> Sometimes it queues received packets and later /on a timer call or a call
> from the user space/
> it re-injects the packets using ng_send_data.
>
reinjects it to where?
>
> > Fr
This is kind of a bridge, connected to ng_ether interface nodes.
Sometimes it queues received packets and later /on a timer call or a call
from the user space/
it re-injects the packets using ng_send_data.
> From: Julian Elischer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 20, 2004 5:34 PM
>
Hi,
Currently netgraph code uses splnet/splx to protect timeout calls.
This doesn't work with 5.2 SMP kernel. What is the proper method
here for a custom netgraph node? Is the Giant lock only the way?
Thanks
--
Dmitri
___
[EMAIL PROTECTED] mailing li
Ha! funny you should ask that exactly now..
I was just discussing this with Robert Watson..
The answer is "it depends on what you want to do".
What DO you want to do and what does your node do?
netgraph has internal locking in 5.x that you need to
interact with but it should be pretty transparr
