Frank Hofmann writes: > On Fri, 21 Sep 2007, Joachim Worringen wrote: > > Frank Hofmann wrote: > >> Why do you need to know this in a driver, how should behaviour be > >> different ? > > > > I'm porting some modules from Linux that use "signal_pending(current)" > > in some places. > > > > I already managed at one place to recode so that I can omitt the > > signal_pending(); I hopefully can continue this path. Otherwise, the > > construct you proposed looks not all that hacky... > > Except it doesn't do, unfortunately. > Sorry for the noise. [...] > I wonder whether it'd make sense to ask for inclusion of such a polling > function into the DDI. After all, you already do have proc_signal() to > raise one from within a driver ...
At least to me, the request for such a function itself raises some doubts about the design of the driver. Could the original poster please go into more design-level detail about exactly _why_ polling for a signal would make sense? I understand that you're porting a Linux driver, and I understand that Linux has this (mis)feature in its kernel. Simply doing the same on Solaris seems like the path of least resistance, but I'm not sure it's right. At a slightly wild guess, it sounds like the driver is trying to work around some other defect, such as holding mutexes for a "long time" to synchronize threads, rather than using condition variables, or some other synchronization- related shortcoming. I'd prefer not to see a "poll for pending signal" DDI function until there's some clear explanation of how the current signal-taking functions are themselves insufficient. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
