On Thu, Jan 24, 2013 at 02:49:21PM -0800, Tejun Heo wrote:
> On Thu, Jan 24, 2013 at 02:42:03PM -0800, Tejun Heo wrote:
> > One other thing is I would much prefer if the table was made static
> > const first. As we only allow compile-time defined tables, there's no
> > point in dynamically initializing these and the above can be static
> > initializers.
>
> On the similar line of thoughts, wouldn't it be better to have the
> table organized by the device type first? It would be much easier to
> comprehend which commands are allowed for each device type that way
> and FWIW it would be more cacheline friendly. e.g. something like,
>
> #define M(opcode) (1 << opcode)
>
> #define COMMON \
> M(READ_6) | M(WRITE_6) | ....
>
> static const whatever_type blk_cmd_filter_disk = {
> COMMON |
> M(CMD_SPECIFIC_TO_THIS_TYPE0) |
> M(CMD_SPECIFIC_TO_THIS_TYPE2) |
> ...
> };
Oops, there are way more bits than in the longest integer, so you
can't statically initialize them in pretty way (maybe it's possible
but I can't think of anything pretty). We can still initialize the
table once during boot and throw away the init code, I guess. Also, I
still think device -> command organization would be better than
commmand -> device.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
