Re: some pmf improvements

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

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?

}         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.

} 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?

}-- End of excerpt from David Young