On Thu, 21 May 2009, M. Warner Losh wrote:
: devctl_notify() probably needs to grow a sleepable flag, or perhaps we need
: two variations, one that can sleep.
devctl_notify() has expanded well beyond its original needs. Having an
extra case for sleeping is the wrong way to solve this problem. Really.
We're adding hacks on hacks on hacks here and we need to step back and
think.
I specifically didn't put in CDEV notifications into devd when I originally
did it because one can get the same notification via kevents on /dev.
Maybe the right answer is to remove this stuff entirely and update devd to
do that instead? It isn't a lot of code, and should provide equivalent
functionality without needing to change the rules of the game when it comes
to destroy_dev(). Especially this close to the code slush...
Well, the "can it sleep" question is fundamentally about whether it's a
reliable protocol or not in the presence of low kernel memory -- experience in
the network stack says you give code the option of failing if sleeping
indefinitely if it knows it's running in a safe context, and otherwise you
allow it to fail. Calls like if_detach(), destroy_dev(), etc, all assume
unbounded sleeping is OK, so should use M_WAITOK for generating messages to
devctl (although there is a question about over-filling buffers, etc -- should
they block if things get backed up, and if so can that deadlock?). If there
are cases where unsleepable locks must be held over notification, or it must
run in a non-sleepable context such as an ithread, having a non-sleepable
version (and hence one that can fail) is required.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
