# Cherry G. Mathew 2006-07-28:
> On 7/28/06, Allen Briggs <briggs@netbsd.org> wrote:
> >On Thu, Jul 27, 2006 at 08:11:40AM -0700, Matt Thomas wrote:
> >> shutdownhooks should go away.  instead we should have a two stage
> >> process and, for devices, this should be using ca_activate in
> >> struct cfattach.  For filesystems, we should add a vfs_activate
> >> to struct vfsops.
> >>
> >>     (*wdc_ca.ca_activate)(wdc_cd.cd_devs[0], DVACT_DEACTIVATE_PREPARE);
> >>
> >> Ask the device to prepare to quiesce, it returns 0 if it is ready or
> >> an errno if it's not possible.  If it returns EAGAIN, call with PREPARE
> >> again after deactivating next device.  If at the end of the device list
> >> and there are devices returning EAGAIN, either panic or fail the
> >> PREPARE.
> >>
> >> Now depending on results of the PREPARE, either call the ca_activate with
> >> DVACT_DEACTIVATE_COMMIT (now really quiesce) or DVACT_DEACTIVATE_CANCEL
> >> (resume normal operation).  COMMIT and CANCEL not allowed to fail.
> >
> >I like this proposal in principle, but it needs a some more fleshing
> >out.  Are either of you able and/or willing to flesh out the proposal
> >and/or do the work to make it happen?
> 
> Why is this necessarily better than the current hooks based mechanism?

Well, we have some API duplication in controlling device's operational
state (deactivate, shutdown hooks, power hooks). It would be good to
replace all those more-or-less ad hoc hooks with a clear API and state
change protocols.

> Isn't what Matt proposes doable with minor modifications to the
> current mechanism?

I don't think it would be "minor" -- a lot of device drivers will need
to be modified. That said, I like the general direction of Matt's idea.

> I suspect wider scope ( powerhooks and general driver infrastructure
> reworking ), which is why I'm asking in the first place.

I suspect I'm working on (part of) this wider scope :-) (device_iterator
API being the foundation thereof). I'll post more on this when I'm done
with some proof-of-concept experiments.

	-- Jachym