Date: Sun, 03 Mar 2002 10:49:05 -0800 From: Maksim Yevmenkin <e.max@verizon.net> To: freebsd-current@freebsd.org Subject: Netgraph, device drivers and mutexes Message-ID: <3C827021.A7FA73A4@verizon.net>
next in thread | raw e-mail | index | archive | help
Hackers, i have some (probably stupid) questions about Netgraph, device drivers and mutexes. i'm using -current as of this weekend. 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 etc. 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. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C827021.A7FA73A4>