David Kahn wrote:
>
>
> 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.
I agree they should be part of the interface specification. But anyway,
it sounds like the current implementation (for better or worse -- I
think worse) isn't implemented this way.
I'd frankly rather have this kind of wording, and implementation to
match, to keep life simple for everyone.
-- Garrett
>
> Thanks,
> David
>
>
