tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: some pmf improvements



On Mon, Feb 11, 2008 at 02:37:07PM -0800, John Nemeth wrote:
> On Jul 3, 11:12am, David Young wrote:
> } On Sun, Feb 10, 2008 at 07:44:18AM -0800, John Nemeth wrote:
> } > On Jul 2, 10:08am, David Young wrote:
> } > } 
> } > } Also, I put a process to sleep if it calls pmf_device_resume(, 
> PMF_F_SELF)
> } > } on a device that was suspended by the system/operator.  In this way,
> } > } I stop programs such as wpa_supplicant(8) from interfering with device
> } > } suspension by modifying IFF_UP.
> } > 
> } >      Why not just return an error instead of putting the process to
> } > sleep?
> } 
> } Because that raises more questions than it answers? :-)
> } 
> }         1) Shall we actually set IFF_UP, or cancel the operation?
> 
>      Cancel the operation.  It shouldn't be throwing an error while
> performing the operation anyways?
> 
> }         2) Which error code?  ENXIO?  EINPROGRESS?
> 
>      EX_UNAVAILABLE?  EX_TEMPFAIL?  EX_NOPERM?
> 
> }         3) How will applications handle the error code?  Spin?  Quit?
> 
>      Quit?

I don't think you understand.  I am trying to avoid killing off
applications.  If one closes the lid to a laptop, and re-opens the lid, it
defies expectations for suspend/resume for a lot of processes to die off.

> }         4) Will we audit and modify 3rd-party apps in base to handle the
> }            error code?  What about pkgsrc apps?
> 
>      In base, yes.  Pkgsrc, maybe.  This is a very good question though.

If you say so, but this is a tremendous amount of work.  I am striving
to avoid that work myself, and to avoid creating work for others.

> } I don't think that most applications are prepared for an ioctl that
> } ordinarily powers-up a device to do any different, and we may as well
> } put those applications to sleep.
> 
>      Wouldn't this create an unkillable process?

Not necessarily.  I have used an uninterruptible sleep to test the idea,
but I don't see any reason that it should remain so.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24


Home | Main Index | Thread Index | Old Index