[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130124225845.GD2373@mtj.dyndns.org>
Date: Thu, 24 Jan 2013 14:58:45 -0800
From: Tejun Heo <tj@...nel.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, pmatouse@...hat.com,
"James E.J. Bottomley" <JBottomley@...allels.com>,
linux-scsi@...nel.org, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH 02/13] sg_io: reorganize list of allowed commands
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists