> > My personal taste on things like this is that if you had something like > > a variable with a result code, then use a separate enum for the possible > > options. However, in this case, you have a multi-mask item and the > > defines are the three masks and their shifts. I'm OK with that being > > mixed in or being separate, but if it's separate, I would want it > > immediately before the struct with a comment specifying that this is the > > format of the status byte in the struct. What I wouldn't want is the > > #defines moved far away from the struct with a bunch of other defines > > where the context of the struct is lost. > > It looks like you are neutral on the topic, and I'm against mixing these > specific defines with structures. Every change in such define changes > struct as well which can be easily missed out. > Leon, I don't think that is reasonable. I can accept that refactoring all of our code so that defines end up outside the structures would make it easier for you personally to review, but I don't agree there is any general improved readability. Quite the opposite. The whole purpose of storing the defines adjacent to their fields is so you can easily associate them together. The reason that this style is used by so many people is *for* improved debuggability and readability. This style is prevalent throughout the kernel. Even if you think net is a bad example (while I think it is an excellent example), you can find examples in every corner of the kernel so this is not "a net thing". Here are just a few examples outside of net (there are thousands): fs/cachefiles/internal.h line 86 block/partitions/acorn.c line 69 crypto/jitterentropy.c line line 78 kernel/sched/sched.h lines 594 and 1250 drivers/block/drbd/drbd_int.h line 996 drivers/gpu/drm/gma500/psb_intel_drv.h line 128 As Doug is comfortable with this style, we are going to leave it as is. Try thinking of our entrance to linux-rdma as an opportunity to cross- pollinate and bring over some new techniques and new people into the subsystem. Thanks, Ariel -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
