On Tue, 23 Feb 2010, Jens Axboe wrote: > > > And that's back to the question of whether or not that is a nice thing to > > > do. It seems a bit dirty, but otoh where else to do it. Perhaps just > > > using the kblockd to postpone the del_gendisk() to out-of-resume context > > > would be the best approach. > > > > That would involve a layering violation, wouldn't it? Either the > > driver would have to interface with kblockd directly, or else > > del_gendisk() would need to know whether the writeback task was frozen. > > > > On the whole, I think it's best for the block layer to retain full > > control over its own tasks and requirements. > > You would export such functionality - del_gendisk_deferred(), or > something like that. The kblockd suggestion was implementation detail, > not something the driver would concern itself with. It's not exactly > picture perfect, but it could be used from eg resume context where the > device isn't fully live yet. Hmm. There's still no way for the driver to know whether or not the writeback task is frozen when it wants to call del_gendisk(). It would have to defer _all_ such calls. And all hot-pluggable block drivers would have to do this -- would that be acceptable? How about plugging the request queue instead of freezing the writeback task? Would that work? It should be easy enough for a driver to unplug the queue before unregistering its device from within a resume method. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
