Re: [PATCH] call drv->shutdown at rmmod

[ebiederm@xmission.com (Eric W. Biederman)]

Russell King <rmk@arm.linux.org.uk> writes:

> On Thu, Aug 14, 2003 at 08:54:43AM +0100, Christoph Hellwig wrote:
> > Sounds really confusing.  And having shutdown maybe called before remove
> > but not always sounds like a design mistake.

My patch always called shutdown before remove, but only if the methods
are implemented.  Mandating that shutdown and remove are implemented 
is not something I am changing with this patch.

> > Why do we have shutdown at all?  Can't we just call ->remove on shutdown
> > so the device always get's into proper unitialized state on shutdown, too?
> 
> That's likely to remove the keyboard driver, and some people like
> to configure their box so that ctrl-alt-del halts the system, and
> a further ctrl-alt-del reboots the system once halted.

Hmm.  That is a very weird case.  Semantically the keyboard driver
and everything else should be removed in any case.

After device_shutdown is called it is improper for any driver
to be handling interrupts because the are supposed to be in a quiescent
state.  And if they are not it is likely to break a soft reboot.

> There are also some bus drivers which want to know the difference
> between "device (driver) was removed" and "device was shutdown",
> eg, for setting bus-specific stuff back into a state where the
> machine can be soft-rebooted.
> 
> With the shutdown callback, drivers get the option whether to
> handle this event or not.  Combining it with remove gives them no
> option what so ever, and bus drivers loose this knowledge.

Reasonable.  And they still get that knowledge with the way I implemented
my patch.  They just get to shutdown first.

Russell do you have any objects to always calling shutdown before
remove?   I don't think this looses knowledge and in most cases it should
work, but if there are bus devices were we need to do things significantly
differently I am open to other solutions.

All I really care about is that we get something that is simple enough
that device driver authors can get it right.  And according to my limited
testing we don't have that right now.

Eric