On Fri, Nov 05, 2004 at 11:05:04PM +0100, Lars Marowsky-Bree wrote: > - Allow user-space to send us a "switch_pg" message, specifying the > number of the PG to switch to instead. > - Report the number of the active PG in the status report. > - To keep the mapping itself stable, allow user-space to specify the no > of the PG which should be active initially at table load time. > - The kernel keeps track of the "current_pg" already and never > gratuitiously changes PGs. Only in response to errors (all paths > failed), or when the error handler tells us to SWITCH_PG do we switch, > and then we switch to the first other PG with healthy paths. It's worth trying something along those lines to see if it shifts the complexity to a better place. [BTW The bypass lots at once issue is trivially solved by accepting a list of PGs.] So it removes enable/disable PG messages, and replaces them with a single message to switch PG to a specific PG immediately. PGs become 'sticky' - the current_pg will no longer change automatically if a path in a higher-priority PG becomes available. But what happens if the error handler requests a PG switch? Does that mean that PG cannot be used again without userspace intervention (in which case it might as well fail all its paths)? For otherwise, how is that state held (and reported/modified by userspace) without something similar to the bypass logic? Alasdair -- agk@xxxxxxxxxx
