Garrett D'Amore wrote:
> Yes, you could. Properties (as opposed to dev ops flags) are a PITA. A flag is fine. Same idea. I'm not really hung up on expanding dev_ops vs adding a new detach command with a flag/property. I was just pointing out that if the project team doesn't want to expand dev_ops, there is a decent alternative available. >> This needs a bit of work, IMO. > > This sound less architectural, and more wordsmithing. I won't disagree > that the docs can be cleaned up, made clearer.... No, this is the specification of the interface. It isn't wordsmithing. The specification of the interface is what's important here and it must be crystal clear and not subject to different interpretations. > Ah, but what I'm saying is that the kernel should have disabled all > interrupts from occurring at the point that quiesce is called. So those > events, which may occur in hardware, won't trigger an ISR execution. No > locking is required. It must be specified that way. Not the single threaded part, but the guarantee that timers, callbacks, interrupt service routines and all other async callbacks and other driver entry points will not be called or active when the driver is in quiesce(9e). If that's the interface, then it must be specified that way as part of the case materials. PSARC is reviewing the interface specification. The interface specification is not sufficient, so it needs work before it can be approved so all these things that have been mentioned in the replies are addressed and made part of the interface specification. Thanks, David
