PSARC/2008/146 sgen(7D) Multiple Opens

[Garrett D'Amore]

Right.  I'm sorry, I should have remembered that I was the one that 
initiated this conversation at today's meeting.

Anyway, other members, I believe that we have converged on this case.

I do believe that at some point, the PM team needs to take a hard look 
at the case of "device drivers in userland" and figure out a more 
general way to allow userland components to participate in S/R 
notification, etc.  Once upon a time, I believe that used to be RCM 
hooks for this -- but I'm not certain that those hooks are called in the 
x86 S/R code.  But this issue can be handled outside of the context of 
this case.

    -- Garrett

Eric Schrock wrote:
> For the record, we discussed this issue offline and determined that the
> current behavior, while leaving something to be desired, is valid given
> the use of the driver (userland pass-through).  Any changes to this
> behavior are beyond the scope of this particular case.
>
> - Eric
>
> On Mon, Feb 25, 2008 at 02:26:44PM -0800, Garrett D'Amore wrote:
>   
>> As far as Suspend/Resume goes, the "correct" behavior, IMO, is that 
>> open() "blocks" if it is called while the device is suspended, at least 
>> if it needs to access the device.  (If open() doesn't need to touch the 
>> hardware, but only updates soft state, then there is no reason to 
>> prohibit it from running normally even if the device is technically 
>> suspended.)
>>
>> Put another way, apart from observations involving the time it takes to 
>> run, I do not believe that there should be any noticeably different 
>> behavior to consumers of a device that supports suspend/resume.
>>
>> A separate EIO return value seems like a poor choice to me.
>>
>> Please feel free to contact me offline if you desire further feedback or 
>> discussion pertaining to S/R of devices.
>>     
>
> --
> Eric Schrock, Fishworks                        http://blogs.sun.com/eschrock
>