Hi Maxim, > Instead of this adding blk_is_valid_logical_block_size allowed me to > trivially convert most of the uses. > > For RFC I converted only some drivers that I am more familiar with > and/or can test but I can remove the driver's own checks in most other > drivers with low chance of introducing a bug, even if I can't test the > driver. > > What do you think? > > I can also both make blk_queue_logical_block_size return an error > value, and have blk_is_valid_logical_block_size and use either of > these checks, depending on the driver with eventual goal of > un-exporting blk_is_valid_logical_block_size. My concern is that blk_is_valid_logical_block_size() deviates from the regular block layer convention where the function to set a given queue limit will either adjust the passed value or print a warning. I guess I won't entirely object to having the actual check in a helper function that drivers with a peculiar initialization pattern can use. And then make blk_queue_logical_block_size() call that helper as well to validate the lbs. But I do think that blk_queue_logical_block_size() should be the preferred interface and that, where possible, drivers should be updated to check the return value of that. -- Martin K. Petersen Oracle Linux Engineering
