i have some (probably stupid) questions about Netgraph, 
device drivers and mutexes. i'm using -current as of this

i have written draft version of the driver for 3com/HP 
Bluetooth Card (PC-Card). the driver is a pure Netgraph
node, i.e. no device nor network interface registered at
all. the only interface is Netgraph.

the dirver is very simple - it detects and attaches the 
card, allocates resources, registers interrupt service 
routine (for now at NET level, but it probably shouldn't)
and creates Negraph node. it sort of works, but i'm trying
to figure out what kind of locking i need (if i need any).

the same locking questions goes for the other Netgraph
nodes that connected to the driver node. i want very 
simple locks to do the following:

1) handle timeouts with timeout(9)/untimeout(9) -
   my _biggest_ concern. all i could find in -current is
   everyone use splXXX/splx :( is it broken on SMP?

2) modify node's internal data structure in a safe way.
   i'm talking about things like linked lists, queues

since splXXX(9) functions are no longer relevant in
-current (please correct me if i wrong), i was looking
at mutex(9). i have noticed several device drivers that
also use Netgraph (if_ar, if_sr, if_lmc and udbp), and 
they use MTX_DEF mutexes and splXXX(9) functions. is that
OK with Netgraph? the man page says that MTX_DEF mutexes
_will_ context switch when they are already held. 

can/should i use MTX_SPIN mutexes? i have tried to use
them, but WITNESS code gets very upset (panic) unless i 
modify "order_lists" in kern/subr_wintess.c. i would 
rather not do it, since i'm not fully aware of what's 
going on.

any other ways to handle that? i had crazy idea to write
a Netgraph "timeout" node, that does nothing but accepts
requests to set/remove timeout and send message back when
timeout has expired. it won't solve timeout problem, but 
put it into one place.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to