Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Castor Fu <castor@egocast.org>
Cc: fio@vger.kernel.org
Subject: Re: numerical option parsing broken in engine options
Date: Tue, 25 Feb 2014 11:37:02 -0800	[thread overview]
Message-ID: <530CF0DE.2090807@kernel.dk> (raw)
In-Reply-To: <530CEC6C.2020501@kernel.dk>

On 2014-02-25 11:18, Jens Axboe wrote:
> On 2014-02-25 10:52, Jens Axboe wrote:
>> On 2014-02-25 09:34, Castor Fu wrote:
>>> Indirectly.  If the external engine has an option which is a
>>> FIO_OPT_INT, and I give it a value like  '4k', then we'll eventually
>>> call fio_get_kb_base while pointing to the engine options area instead
>>> of the options / thread_data area.
>>
>> Ah I see now, yes that is definitely an issue... Let me think about this
>> a bit. td->eo as data only works for the engine itself, it's not pretty
>> that the parser ends up thinking it's td.
>
> So the issue is really that a non static function makes assumptions
> about what 'data' is at this point. That's just not going to work.
> Internal use cases are fine, since they know what *data is, but it wont
> work for fio_get_kb_base().
>
> So we definitely need some way of knowing if 'data' is our regular
> options or not...

This is the best short term fix I could come up with...

http://git.kernel.dk/?p=fio.git;a=commit;h=cb1402d674fb7694d1b09d7ef4aeb3d4506f23f0

It'd be nice if kb_base always worked as expected, however. So I'll keep 
mulling over this and see if we can't come up with something better. We 
might just have to have two sets of private, or a private container so 
we can always pass in the right thing.

-- 
Jens Axboe



      reply	other threads:[~2014-02-25 19:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25  1:51 numerical option parsing broken in engine options Castor Fu
2014-02-25 17:07 ` Jens Axboe
2014-02-25 17:34   ` Castor Fu
2014-02-25 18:52     ` Jens Axboe
2014-02-25 19:18       ` Jens Axboe
2014-02-25 19:37         ` Jens Axboe [this message]

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=530CF0DE.2090807@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=castor@egocast.org \
    --cc=fio@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox