Re: [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends.
FUJITA Tomonori <[email protected]>
| Newsgroups | org.kernel.vger.stgt |
|---|---|
| Message-ID | <20131108.065149.1568838937885782612.fujita.tomonori@lab.ntt.co.jp> |
On Thu, 07 Nov 2013 13:46:36 -0800 Dan Mick <[email protected]> wrote: > >>>> I see, thanks. Using the bitmaps is simpler than the array of char if >>>> you calculate delta and such? >>> >>> I think using the array with opcode names is simpler for a human to >>> comparing when reading the sourcecode. >>> >>> >>> I had a bitmap of 32 bytes, one bit for each opcode, and I also >>> tried using an array of 256 bytes, one byte 0/1 for each opcode >>> but it was horrible to read from a human standpoint. >>> >>> When reading the code and the bitmap/array it was very difficult to >>> see which opcodes were supported and which were not >>> by just looking at the bits. >>> It was also errorprone and I did several mistakes when building the >>> bitmap manually. >> >> Why you built it manually? You can do something like >> >> set_bit(WRITE_6, bitmap_addr); >> >> ? >> >> As usual, you can steal bitmap functions from Linux kernel. > > Is it worth it to mess around with bits when chars are easily > manipulated? Sure, it's 8x the data, but it's much easier to dump, > examine in debuggers, etc., and it's 256 bytes; hardly worthy of > notice. > Bitmaps are a pain in general. Most of us (kernel people) are familar with bitmap ops rather than functions that we would invent. That's my point.