Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Daniel Gollub <d.gollub@telekom.de>, fio@vger.kernel.org
Subject: Re: fio headers as build dependency for external-ioengines
Date: Wed, 30 Apr 2014 08:29:15 -0600	[thread overview]
Message-ID: <536108BB.7030502@kernel.dk> (raw)
In-Reply-To: <1398849904-6013-1-git-send-email-d.gollub@telekom.de>

On 04/30/2014 03:25 AM, Daniel Gollub wrote:
> Hi,
> 
> I am working right now in preparing for the Ceph project an external
> fio ioengine, which depends on Ceph-internal libraries. So I thought
> about building this ioengine as an external ioengine. (Thats why I
> send couple of weeks/month ago this C++-compiler-issues-fixes for
> fio.h)
> 
> Since fio is not (yet) distributed with a -dev/-devel package in
> linux distribution and was very likely not yet consider doing so
> I wanted to start the discussion here if this in interested of the
> project "exporting"/"installing" the required fio headers to build
> external ioengines. So fio can be later a "packaged" build-dependency.
> 
> For time-being I thought about solving this like this:
> 
> One can introduce in the external project's build-env a parameter
> like: --with-fio=~/projects/fio/ and the resulting build-env will
> pass this path as include directory as compiler flags for the
> external ioengine build.
> 
> Unfortunately there are some issues with double-declaration and
> one ambiguous header file name (e.g. time.h - see provided patch)
> 
> Double-declaration issues of defines/macros/... I hit while building
> the Ceph filestore external ioengine:
> 
>  * ARRAY_SIZE
>  * CONFIG_CPU_COUNT
>  * le16_to_cpu
>  * le32_to_cpu
>  * le64_to_cpu
> 
> 
> If you want to reproduce the described issue with ceph,
> checkout following revision:
> https://github.com/gollub/ceph/commit/079c08c67f811c0173e70201dc91168b60d2e86b
> ( Working branch: https://github.com/gollub/ceph/tree/fio_filestore_v2 )
> 
> And run:
> ./configure --with-fio-dir=/path/to/fio/
> cd src
> make libfio_ceph_filestore.la
> 
> 
> This could be solved/workaround on the external ioengine side, as well
> as in the fio header. One possibility on the fio side could be to relax
> fio.h header a bit, so only mandatory declarations and further
> includes are part of it to successfully build an external-ioengine.
> I am happy to help on this if fio decides to go this route.
> 
> Thoughts?

It'd be a useful thing to be able to do. I applied your time patch,
looks fine to me. Are you going to be able to work through the other
issues? I think we just need to privatize some of the names a bit more.

-- 
Jens Axboe



      parent reply	other threads:[~2014-04-30 14:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-30  9:25 fio headers as build dependency for external-ioengines Daniel Gollub
2014-04-30  9:25 ` [PATCH] Rename time.h for third-party include of fio.h Daniel Gollub
2014-04-30 14:29 ` 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=536108BB.7030502@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=d.gollub@telekom.de \
    --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