Mike Christie wrote:
Joe Thornber wrote:
On Tue, Jan 20, 2004 at 08:32:44PM +0100, Christophe Saout wrote:
To use blk_queue_stack_limits dm would have to associate a request queue
with a table and swap it around too. I don't know if this is possible.
dm doesn't use most of the fields in the request_queue struct.
This would be the wrong thing.
Right having the queue in the table would not work.
In the constructor the target calls dm_get_device on it's devices and
combines the io restrictions for them. Then dm_table_add_target calls
combine_restrictions_low to combine the newly added targets restrictions.
So, it looked like instead of combining the restrictions when you build
the table you could defer it until you bind. dm_table_set_restrictions
could just loop through its list of devices combining all the
restrictions then.
I meant, it looked like it would work becuase the targets seem to use
their io restrictions for just combining restrictions, but at bind time
the table has all the devices. What is the reason to perculate them up
through the dm_dev, target and table during the building.
dm_table_set_restrictions could just do:
loop table->devices
blk_queue_stack_limits(q, current device's queue);
Is there a target that uses the the limit variable for something else? I
just did a grep through the source so I do not know for sure. Or will
this be a problem with how the v1-ioctl binds and sets up tables - I am
not too familir with it?
Mike
