All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Mick <dan.mick@inktank.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	ronniesahlberg@gmail.com
Cc: stgt@vger.kernel.org
Subject: Re: [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends.
Date: Thu, 07 Nov 2013 13:46:36 -0800	[thread overview]
Message-ID: <527C0A3C.9080904@inktank.com> (raw)
In-Reply-To: <20131108061347I.fujita.tomonori@lab.ntt.co.jp>


>>> 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.

  reply	other threads:[~2013-11-07 21:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1381588740-25968-1-git-send-email-ronniesahlberg@gmail.com>
     [not found] ` <1381588740-25968-2-git-send-email-ronniesahlberg@gmail.com>
2013-10-16 16:05   ` [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends ronnie sahlberg
2013-10-17 13:47   ` Hitoshi Mitake
2013-10-20 13:38   ` ronnie sahlberg
2013-10-21  1:34   ` FUJITA Tomonori
2013-10-31  1:44     ` ronnie sahlberg
2013-11-05 14:39       ` ronnie sahlberg
2013-11-07  7:07       ` FUJITA Tomonori
2013-11-07 16:42         ` ronnie sahlberg
2013-11-07 21:39           ` FUJITA Tomonori
2013-11-07 21:46             ` Dan Mick [this message]
2013-11-07 21:51               ` FUJITA Tomonori
2013-11-07 22:15                 ` Dan Mick
2013-11-17  1:18 [PATCH] Add an array that describes which opcodes are supported by backends Ronnie Sahlberg
2013-11-17  1:18 ` [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends Ronnie Sahlberg
2013-11-17 13:23   ` FUJITA Tomonori
2013-11-24 16:39     ` ronnie sahlberg
2013-11-24 21:06       ` FUJITA Tomonori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527C0A3C.9080904@inktank.com \
    --to=dan.mick@inktank.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=ronniesahlberg@gmail.com \
    --cc=stgt@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.