On Wed, 11 Apr 2018, Joe Perches wrote:
> (Adding Julia Lawall) > > On Wed, 2018-04-11 at 09:29 -0700, Andrew Morton wrote: > > We already have some 500 bools-in-structs > > I got at least triple that only in include/ > so I expect there are at probably an order > of magnitude more than 500 in the kernel. > > I suppose some cocci script could count the > actual number of instances. A regex can not. I got 12667. I'm not sure to understand the issue. Will using a bitfield help if there are no other bitfields in the structure? julia > > > and the owners of that code will > > be wondering whether they should change them, and whether they should > > apply those remove-bool-in-struct patches which someone sent them. > > Which is why the warning is --strict only > > > So... can we please get some clarity here? > > > > ... > > > > (ooh, https://lkml.org/lkml/2017/11/21/384 is working this morning) > > > > hm, Linus suggests that instead of using > > > > bool mybool; > > > > we should use > > > > unsigned mybool:1; > > > > However that introduces the risk that alterations of mybool will use > > nonatomic rmw operations. > > > > unsigned myboolA:1; > > unsigned myboolB:1; > > > > so > > > > foo->myboolA = 1; > > > > could scribble on concurrent alterations of foo->myboolB. I think. > > Without barriers, that could happen anyway. > > To me, the biggest problem with conversions > from bool to bitfield is logical. ie: > > unsigned int.singlebitfield = 4; > > is not the same result as > > bool = 4; > > because of implicit truncation vs boolean conversion > so a direct change of bool use in structs to unsigned > would also require logic analysis. > >
