Message ID | 20220623180528.3595304-1-bvanassche@acm.org (mailing list archive) |
---|---|
Headers | show |
Series | Improve static type checking for request flags | expand |
Hi Bart, I generally like this. Two thoughs: - I suspect most places that currently pass a enum req_op might really want a blk_opf_t for future extensibility, exceptions are very low-level helpers like req_op() and bio_op() where the enum is very nice to force switch statements to handle all ops or have a default statements - a lot of the flags printinting is a mess, and introduce the code smell of __force casts. It migh make sense to introduce a new %psomething format specifier first to print a blk_opf_t using printk/vsprintf/etc and switch everyone to that first instead of hand crafted printing.
On Fri, Jun 24, 2022 at 07:05:27AM +0200, Christoph Hellwig wrote: > Hi Bart, > > I generally like this. Two thoughs: > > - I suspect most places that currently pass a enum req_op might really > want a blk_opf_t for future extensibility, exceptions are very > low-level helpers like req_op() and bio_op() where the enum is > very nice to force switch statements to handle all ops or have > a default statements > - a lot of the flags printinting is a mess, and introduce the code > smell of __force casts. It migh make sense to introduce a new > %psomething format specifier first to print a blk_opf_t using > printk/vsprintf/etc and switch everyone to that first instead of > hand crafted printing. Oh, and a third: there is still various places passing the op separately from the flags and/or using bio_set_op_attrs. This would be a good time to clean the rest of those up (I already did a lot of that gradually).
On 6/23/22 22:05, Christoph Hellwig wrote: > I generally like this. Two thoughs: > > - I suspect most places that currently pass a enum req_op might really > want a blk_opf_t for future extensibility, exceptions are very > low-level helpers like req_op() and bio_op() where the enum is > very nice to force switch statements to handle all ops or have > a default statements Agreed. I will use blk_opf_t where enum req_op is passed today but where request flags might be passed in addition to the request type in the future. > - a lot of the flags printinting is a mess, and introduce the code > smell of __force casts. It migh make sense to introduce a new > %psomething format specifier first to print a blk_opf_t using > printk/vsprintf/etc and switch everyone to that first instead of > hand crafted printing. How about using blk_fill_rwbs() instead, a function that is already being used by the bcache tracing code? No matter how tracing the request operation type and flags is unified, I'd like to defer this unification to a future patch series since this patch series is already too big. Thanks, Bart.
On 6/23/22 22:07, Christoph Hellwig wrote: > Oh, and a third: there is still various places passing the op > separately from the flags and/or using bio_set_op_attrs. This > would be a good time to clean the rest of those up (I already did > a lot of that gradually). I will look into combining 'op' and 'op_flags' arguments but I would like to postpone removing bio_set_op_attrs() since this patch series is already too big. Thanks, Bart.