On Wed, 2020-07-22 at 12:11 +0300, Maxim Levitsky wrote: > On Tue, 2020-07-21 at 22:55 -0400, Martin K. Petersen wrote: > > Christoph, > > > > > Hmm, I wonder if we should simply add the check and warning to > > > blk_queue_logical_block_size and add an error in that case. Then > > > drivers only have to check the error return, which might add a lot > > > less boiler plate code. > > > > Yep, I agree. > > > > I also agree that this would be cleaner (I actually tried to implement > this the way you suggest), but let me explain my reasoning for doing > it > this way. > > The problem is that most current users of blk_queue_logical_block_size > (43 uses in the tree, out of which only 9 use constant block size) > check > for the block size relatively early, often store it in some internal > struct etc, prior to calling blk_queue_logical_block_size thus making > them only to rely on blk_queue_logical_block_size as the check for > block size validity will need non-trivial changes in their code. > > 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. > > Also note that I did add WARN_ON to blk_queue_logical_block_size. Any update on this? Best regards, Maxim Levitsky > > Best regards, > Maxim Levitsky
