Which is why, IMHO (am I repeating myself ? :) that command has to
be sent down the queue by the _lowest_ level device driver, that
is ide-cd, ide-disk, etc...
This is the way our new device model is designed, at least from
my understanding of our numerous discussions with Patrick. The
actual device beeing suspended is the ide-disk (/cd/tape/...),
it is the target of the suspend request, it gets it from it's
parent in the bus binding (PCI mostly, non-PCI controllers will
have to provide something here), and it's the only place of code
that _knows_ what have to be done.
"knowing" that an ATA disk wants a SYNC. CACHE and/or STANDBY
command while an ATAPI CD wants a packet command (with eventually
a door unlock, and a check unit attention on resume) is not
the responsibility of the block layer nor even the ATA layer,
that would be a layering violation. It's the driver for the
actual device which is the one to know what to do with it's
device and when to do it (when = bus binding).
Pavel propose to stop processes & threads to make things easier
regarding VM, I now tend to think it will indeed make things
less intricated at first and agree we should keep it for now
especially with suspend-to-disk, but it's not the responsibility
of any generic, subsystem or whatever code to actually go suspend
the IO queues down to the drivers (it may be to stop feeding them,
which is the point of stopping processes).
I have the feeling that Alan is trying to avoid any kind of
responsibility upon drivers ;) Well, unfortunately, I think
we have no choice here, and that mean yes, we will have
eventually a few broken drivers that won't play nice with
suspend-to-disk/ram at first, and yes, users will notice,
post bug reports, and hopefully this will be fixed over
time...
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/