> >> This is dangerous for the OSM. When the i2o OSM shuts an IOP
> >> down, it is history. It will stop doing any work at all; network,
> >> disk, console, mouse, whatever. I reserve that for really, really
> >> shutdown/reset.
> >
> > I'm not sure I understand what you mean by "dangerous". When your
> > shutdown method is called, you're being told that you're about to stop
> > being able to control your hardware, either because your code is about to
> > be removed from the kernel (module unload) or because the system is being
> > shut down.
>
> (perhaps) Dangerous in the sense that the i2o OSM handles multiple
> diciplines. It is not a disk-only driver. It has a disk component
> but if I shut down the IOPs more than just disks stop.
> Thus I need to be sure the OSM is the very last to be called.
If you've constructed your bus architecture correctly (ie. the OSM is the
parent of all the discipline drivers) then the bus subsystem will take
care of all of this for you.
(It would be silly to do it any other way.)
> > I'm assuming that you depend on the platform firmware to bring it out of
> > any of the deep sleep modes, re-enumerate the PCI bus and restore all of
> > its volatile state?
>
> Nope. I maintain a state machine in the OSM that makes sure
> there is nothing pending on the IOP. Shutting down the IOP
> is a mess. Bringing it back up is even bigger mess. It is
> simpler the way I do it. Besides, different vendors implement
> i2o in different ways. Some do not even have a facility for
> sane shutdown.
Ugh. In other words, you don't support suspend/resume. 8)
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
