[stgt] [PATCH 07/15] tgt: os.h: sync_file_range is OS dependent
FUJITA Tomonori
fujita.tomonori at lab.ntt.co.jp
Mon Mar 2 12:45:39 CET 2009
On Mon, 02 Mar 2009 13:24:31 +0200
Or Gerlitz <ogerlitz at voltaire.com> wrote:
> Boaz Harrosh wrote:
> > Introduce a new header that includes definitions of all OS specific services. stgt code will use abstract API from os.h. (start with os_xxx). Then a linux/os.c and bsd/os.c implement these services for the needed platform.
> >
> > First such service is sync_file_range which needs to be emulated in bsd.
> > usr/linux/os.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> >
> Hi Boaz,
>
> I think best if we can avoid having a --linux-- os.c file. If not, at
> least avoid adding one-hop for fast-path calls such as sync_file_range
> (e.g in this case under linux let it be inline as it used to be).
If we want to avoid linux/os.c, we need to use ifdef or __weak attribute.
With the former, we can use inline but it doesn't look pretty (so we
use linux/os.c). With the latter, it's pretty but we can't use inline
and some buggy gcc versions can't handle __weak properly.
So we have to choose inline or linux/os.c.
I don't think any functions in linux/os.c is a fast-path call. I
really don't think that making sync_file_range inline affects the
performance.
> Also,
> I wasn't sure where the patch to bs_aio.c from the previous post (11/14)
> landed in this sequence.
I think:
Subject: [PATCH 15/15] tgt: usr/Makefile BSD build Support
-TGTD_OBJS += bs_rdwr.o bs_aio.o
+TGTD_OBJS += bs_rdwr.o
+ifneq (FreeBSD,$(UNAME))
+TGTD_OBJS += bs_aio.o
+endif
As I suggested, we compile bs_aio.o only with Linux. It makes sense
because bs_aio is Linux specific AIO code.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt
mailing list