[PATCH 0/5]

[PATCH 0/5]

[Luiz Fernando N. Capitulino]

 Hi,

 Some random things I've fixed while reading the code, they're
unrelated changes, but I think it's better to send in one shot.

Diff stat:

 Documentation/core-tutorial.txt |    9 ++++-----
 builtin-commit-tree.c           |    3 +--
 cache.h                         |    2 +-
 entry.c                         |   14 +++++++-------
 read-cache.c                    |   16 ++++++++--------
 5 files changed, 21 insertions(+), 23 deletions(-)

Re: [PATCH 0/5]

[Luiz Fernando N. Capitulino]

Em Tue, 24 Apr 2007 15:01:10 -0300
"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> escreveu:

|  Hi,
| 
|  Some random things I've fixed while reading the code, they're
| unrelated changes, but I think it's better to send in one shot.

 Sorry for that, looks like git-send-email doesn't want to work
for me.

 Will send again shortly.

-- 
Luiz Fernando N. Capitulino

Re: [PATCH 0/5]

[Junio C Hamano]

I suspect that you need to quote your human readable name, as it
has a full-stop in it ("N.").  Maybe git-send-email should be
taught about it.

Re: [PATCH 0/5]

[Luiz Fernando N. Capitulino]

Em Tue, 24 Apr 2007 13:56:11 -0700
Junio C Hamano <junkio@cox.net> escreveu:

| I suspect that you need to quote your human readable name, as it
| has a full-stop in it ("N.").  Maybe git-send-email should be
| taught about it.

 It worked when I tested it sending the series to me and CC'ing
my gmail address.

 Will send this series by hand and figure out a better way to
do this...

-- 
Luiz Fernando N. Capitulino

Re: [PATCH 0/5]

[Hermes Trismegisto]

"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>
writes:

> Em Tue, 24 Apr 2007 13:56:11 -0700
> Junio C Hamano <junkio@cox.net> escreveu:
>
> | I suspect that you need to quote your human readable name, as it
> | has a full-stop in it ("N.").  Maybe git-send-email should be
> | taught about it.
>
>  It worked when I tested it sending the series to me and CC'ing
> my gmail address.

Hmmm.  Maybe vger and my ISP have stricter filter based on set
of addresses that appear on To/Cc lines than the way you receive
mails?

In git-send-email, I notice that $author_name address on From:
line is quoted in dq pairs (in sub send_message) but none of the
addresses in @cc taken from the Signed-off-by lines are not
inspected nor quoted.  I do not know what is being done to To:
recipients offhand and I am too lazy to check.

>  Will send this series by hand and figure out a better way to
> do this...

Thanks.  They look reasonable, at least from my cursory look.

Re: [PATCH 0/5]

[Luiz Fernando N. Capitulino]

Em Wed, 25 Apr 2007 12:04:32 -0700
Hermes Trismegisto <junkio@cox.net> escreveu:

| "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>
| writes:
| 
| > Em Tue, 24 Apr 2007 13:56:11 -0700
| > Junio C Hamano <junkio@cox.net> escreveu:
| >
| > | I suspect that you need to quote your human readable name, as it
| > | has a full-stop in it ("N.").  Maybe git-send-email should be
| > | taught about it.
| >
| >  It worked when I tested it sending the series to me and CC'ing
| > my gmail address.
| 
| Hmmm.  Maybe vger and my ISP have stricter filter based on set
| of addresses that appear on To/Cc lines than the way you receive
| mails?

 Maybe, but I've alreays used quilt send to submit patches and it
works quite well (not sure whether I've submitted more than five
patches to LKML though).

| In git-send-email, I notice that $author_name address on From:
| line is quoted in dq pairs (in sub send_message) but none of the
| addresses in @cc taken from the Signed-off-by lines are not
| inspected nor quoted.  I do not know what is being done to To:
| recipients offhand and I am too lazy to check.

 Heh, I can't check either.

| >  Will send this series by hand and figure out a better way to
| > do this...
| 
| Thanks.  They look reasonable, at least from my cursory look.

 You're welcome.

-- 
Luiz Fernando N. Capitulino

[PATCH 0/5]

[Liu Yu]

The whole patchset includes:
patch 1: fix kvmppc build error
patch 2: fix kvmppc init error
patch 3~5: add kvmppc guest debug support

The guest debug still have some problems I haven't solved.

1. gdb 'next' command uses software breakpoint
software breakpoint is implemented via modify guest's code.
In most case it works well,
but when used by 'next' it's easy to make trouble on powerpc booke.

For example booke has a code template for
jumping to and returning from interrupt handlers:

	bl transfer
	.long handler_addr
	.long ret_addr

when call transfer, it never return but
in transfer assembly code it will read the handler_addr
and ultimately call the handler.
Gdb doesn't know that and treat it as a normal function call.
so gdb put a software breakpoint instruction at handler_addr,
in order to get trap there when return from transfer.

Then guest will read software breakpoint as handler_addr and jump to there..

I'm not sure if x86 suffer this kind of issue.
Is there any way to avoid this?


2. gdb 'watch' command
Jan told me gdb>6.8 can issue hardware watchpoint request via command 'watch',
my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch
However when I use 'watch', I can only see single step from gdbstub side.
Did I miss anything?

Re: [PATCH 0/5]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

Liu Yu wrote:
> The whole patchset includes:
> patch 1: fix kvmppc build error
> patch 2: fix kvmppc init error
> patch 3~5: add kvmppc guest debug support
> 
> The guest debug still have some problems I haven't solved.
> 
> 1. gdb 'next' command uses software breakpoint
> software breakpoint is implemented via modify guest's code.
> In most case it works well,
> but when used by 'next' it's easy to make trouble on powerpc booke.
> 
> For example booke has a code template for
> jumping to and returning from interrupt handlers:
> 
> 	bl transfer
> 	.long handler_addr
> 	.long ret_addr
> 
> when call transfer, it never return but
> in transfer assembly code it will read the handler_addr
> and ultimately call the handler.
> Gdb doesn't know that and treat it as a normal function call.
> so gdb put a software breakpoint instruction at handler_addr,
> in order to get trap there when return from transfer.
> 
> Then guest will read software breakpoint as handler_addr and jump to there..
> 
> I'm not sure if x86 suffer this kind of issue.

It would if it had such a pattern.

> Is there any way to avoid this?

Unless there is a mechanism via the debug infos of a binary to tell gdb
about this, I think one can only avoid it by not using next here.

> 
> 
> 2. gdb 'watch' command
> Jan told me gdb>6.8 can issue hardware watchpoint request via command 'watch',
> my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch
> However when I use 'watch', I can only see single step from gdbstub side.
> Did I miss anything?

Did you install a watchpoint on a symbol? If yes, try if placing one on
an absolute address changes the picture.

Frankly, I didn't understand gdb's logic for selecting soft or hard
watchpoints so far. Soft watchpoints are those you saw: single step to
the program, checking after each step if the watched variable has
changed. In theory it should be clear when to use which. But practice
appears to be non-deterministic, at least with the versions we recently
tried on x86.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

RE: [PATCH 0/5]

[Liu Yu-B13201]

 

> -----Original Message-----
> From: jan.kiszka@web.de [mailto:jan.kiszka@web.de] 
> Sent: Saturday, July 25, 2009 6:44 PM
> To: Liu Yu-B13201
> Cc: qemu-devel; Hollis Blanchard; kvm-ppc; Nathan Froyd
> Subject: Re: [PATCH 0/5]
> 
> Liu Yu wrote:
> > 2. gdb 'watch' command
> > Jan told me gdb>6.8 can issue hardware watchpoint request 
> via command 'watch',
> > my gdb is 6.8.50.20080821-cvs and our toolchain provider 
> confirm that it supports hardware watch
> > However when I use 'watch', I can only see single step from 
> gdbstub side.
> > Did I miss anything?
> 
> Did you install a watchpoint on a symbol? If yes, try if 
> placing one on
> an absolute address changes the picture.

Cool, it did use hardware watch when I used absolute address.
Seems I need to test more. :)

Re: [PATCH 0/5]

[Nathan Froyd]

On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
> For example booke has a code template for
> jumping to and returning from interrupt handlers:
>
> 	bl transfer
> 	.long handler_addr
> 	.long ret_addr
>
> when call transfer, it never return but
> in transfer assembly code it will read the handler_addr
> and ultimately call the handler.
> Gdb doesn't know that and treat it as a normal function call.
> so gdb put a software breakpoint instruction at handler_addr,
> in order to get trap there when return from transfer.
>
> Then guest will read software breakpoint as handler_addr and jump to there..
>
> I'm not sure if x86 suffer this kind of issue.
> Is there any way to avoid this?

You would need to modify GDB to recognize this sort of case with the
skip_trampoline_code gdbarch method.

-Nathan

RE: [PATCH 0/5]

[Liu Yu-B13201]

 

> -----Original Message-----
> From: Nathan Froyd [mailto:froydnj@codesourcery.com] 
> Sent: Monday, July 27, 2009 9:14 PM
> To: Liu Yu-B13201
> Cc: qemu-devel@nongnu.org; hollisb@us.ibm.com; 
> kvm-ppc@vger.kernel.org; jan.kiszka@siemens.com
> Subject: Re: [PATCH 0/5]
> 
> On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
> > For example booke has a code template for
> > jumping to and returning from interrupt handlers:
> >
> > 	bl transfer
> > 	.long handler_addr
> > 	.long ret_addr
> >
> > when call transfer, it never return but
> > in transfer assembly code it will read the handler_addr
> > and ultimately call the handler.
> > Gdb doesn't know that and treat it as a normal function call.
> > so gdb put a software breakpoint instruction at handler_addr,
> > in order to get trap there when return from transfer.
> >
> > Then guest will read software breakpoint as handler_addr 
> and jump to there..
> >
> > I'm not sure if x86 suffer this kind of issue.
> > Is there any way to avoid this?
> 
> You would need to modify GDB to recognize this sort of case with the
> skip_trampoline_code gdbarch method.
> 

Hmm.. I am not a gdb expert.
But even gdb can recognize this pattern, is it safe to skip it?

Re: [PATCH 0/5]

[Nathan Froyd]

On Tue, Jul 28, 2009 at 04:11:57PM +0800, Liu Yu-B13201 wrote:
> > On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote:
> > > For example booke has a code template for
> > > jumping to and returning from interrupt handlers:
> > >
> > > 	bl transfer
> > > 	.long handler_addr
> > > 	.long ret_addr
> > >
> > > when call transfer, it never return but
> > > in transfer assembly code it will read the handler_addr
> > > and ultimately call the handler.
> > > Gdb doesn't know that and treat it as a normal function call.
> > > so gdb put a software breakpoint instruction at handler_addr,
> > > in order to get trap there when return from transfer.
> > >
> > > Then guest will read software breakpoint as handler_addr 
> > and jump to there..
> > >
> > > I'm not sure if x86 suffer this kind of issue.
> > > Is there any way to avoid this?
> > 
> > You would need to modify GDB to recognize this sort of case with the
> > skip_trampoline_code gdbarch method.
> 
> Hmm.. I am not a gdb expert.
> But even gdb can recognize this pattern, is it safe to skip it?

The code doesn't get skipped.  skip_trampoline_code is a hook for
telling GDB "this function doesn't return in the normal way: here's
where execution will resume once this function finishes."  That way GDB
can place the software breakpoint in the correct location: in this case,
at the address handler_addr.

-Nathan

[PATCH 0/5]

[Joshua Clayton]

The main goal of this series is to get rid of a needless and ugly typedef
in the rtl8712 wlan driver.

In the course of fixing that, I found a bug thati will can might (at least in theory)
lead to a overrun during a memcpy, as well as a duplicate struct.
Finally after cleaning up the typedef, I could not bring myself to leave
a variable called SupportedRates in the kernel with my name on it.

I have tested this on amd64. cwthe module loads and doesn't explode



Joshua Clayton (5):
  staging: rtl8712: fix buggy size calculation
  staging: rtl8712: simplify size calculation
  staging: rtl8712: remove duplicate struct
  staging: rtl8712: remove typedefs
  staging: rtl8712: style fix:

 drivers/staging/rtl8712/ieee80211.c           | 22 ++++++-------
 drivers/staging/rtl8712/rtl871x_cmd.c         | 28 +++++-----------
 drivers/staging/rtl8712/rtl871x_cmd.h         |  4 +--
 drivers/staging/rtl8712/rtl871x_event.h       |  2 +-
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 33 +++++++++----------
 drivers/staging/rtl8712/rtl871x_mlme.c        | 47 ++++++++++-----------------
 drivers/staging/rtl8712/rtl871x_mlme.h        |  2 +-
 drivers/staging/rtl8712/rtl871x_mp_ioctl.c    |  6 ++--
 drivers/staging/rtl8712/wlan_bssdef.h         | 32 +++---------------
 9 files changed, 63 insertions(+), 113 deletions(-)

-- 
2.4.6

[PATCH 0/5]

[minyard]

This is a small set of patches for the i801 I2C driver that are
mostly cleanups and consolidation.  No real behaviour change, except
not enabling PEC when it's not needed.

I have tested these pretty extensively on qemu with various configurations
and errors (I've hacked up qemu a bit to do this) and it seems to be ok.

Not sure if you are interested, but thought I would offer.

-corey

[PATCH 0/5]

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

These are another cleanup patches to make it less OS dependent
(less Linux dependent).

Tomohiro Kusumi (5):
  Move {is,load}_blktrace() to a new header blktrace.h
  Drop struct thread_data dependency from os headers
  Drop circular dependency in log.c and lib/output_buffer.c
  Move Linux/ppc64 specific cpu_online() to os/os-linux.h
  Include sg headers in os/os-linux.h

 blktrace.c          |  1 +
 blktrace.h          | 23 +++++++++++++++++++++++
 fio.h               |  8 --------
 init.c              | 10 +++++++---
 iolog.c             |  1 +
 lib/output_buffer.c |  8 +-------
 lib/output_buffer.h |  2 +-
 log.c               |  6 ++++++
 os/os-linux.h       | 10 ++++++++++
 os/os-windows.h     |  4 +---
 os/os.h             | 34 +---------------------------------
 stat.c              |  6 ++++--
 12 files changed, 56 insertions(+), 57 deletions(-)
 create mode 100644 blktrace.h

-- 
2.9.4

[PATCH 1/5] Move {is,load}_blktrace() to a new header blktrace.h

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

This commit does exactly the same as what cgroup.h does for cgroup
support.

Since blktrace is Linux specific feature and api compiled only on
Linux and Android, these two could be defined in blktrace.h rather
than in os/os.h which is basically intended to be something generic
whose implementation vary depending on supported platforms.

The reason for adding a new header blktrace.h instead of using
blktrace_api.h is because blktrace_api.h seems to have been added
for blktrace.c to include which gets compiled only on Linux where
blktrace apis are basically guaranteed to exist (unless really old
kernels), whereas these prototypes or inline functions are needed
by all platforms.

Signed-off-by: Tomohiro Kusumi <tkusumi@tuxera.com>
---
 blktrace.c |  1 +
 blktrace.h | 23 +++++++++++++++++++++++
 fio.h      |  8 --------
 iolog.c    |  1 +
 os/os.h    | 13 -------------
 5 files changed, 25 insertions(+), 21 deletions(-)
 create mode 100644 blktrace.h

diff --git a/blktrace.c b/blktrace.c
index a3474cb..65b600f 100644
--- a/blktrace.c
+++ b/blktrace.c
@@ -10,6 +10,7 @@
 
 #include "flist.h"
 #include "fio.h"
+#include "blktrace.h"
 #include "blktrace_api.h"
 #include "oslib/linux-dev-lookup.h"
 
diff --git a/blktrace.h b/blktrace.h
new file mode 100644
index 0000000..8656a95
--- /dev/null
+++ b/blktrace.h
@@ -0,0 +1,23 @@
+#ifndef FIO_BLKTRACE_H
+#define FIO_BLKTRACE_H
+
+#ifdef FIO_HAVE_BLKTRACE
+
+int is_blktrace(const char *, int *);
+int load_blktrace(struct thread_data *, const char *, int);
+
+#else
+
+static inline int is_blktrace(const char *fname, int *need_swap)
+{
+	return 0;
+}
+
+static inline int load_blktrace(struct thread_data *td, const char *fname,
+				int need_swap)
+{
+	return 1;
+}
+
+#endif
+#endif
diff --git a/fio.h b/fio.h
index ed631bc..963cf03 100644
--- a/fio.h
+++ b/fio.h
@@ -640,14 +640,6 @@ extern void free_threads_shm(void);
  */
 extern void reset_all_stats(struct thread_data *);
 
-/*
- * blktrace support
- */
-#ifdef FIO_HAVE_BLKTRACE
-extern int is_blktrace(const char *, int *);
-extern int load_blktrace(struct thread_data *, const char *, int);
-#endif
-
 extern int io_queue_event(struct thread_data *td, struct io_u *io_u, int *ret,
 		   enum fio_ddir ddir, uint64_t *bytes_issued, int from_verify,
 		   struct timeval *comp_time);
diff --git a/iolog.c b/iolog.c
index 31d674c..01b82e8 100644
--- a/iolog.c
+++ b/iolog.c
@@ -19,6 +19,7 @@
 #include "trim.h"
 #include "filelock.h"
 #include "smalloc.h"
+#include "blktrace.h"
 
 static int iolog_flush(struct io_log *log);
 
diff --git a/os/os.h b/os/os.h
index 5e3c813..c25cc36 100644
--- a/os/os.h
+++ b/os/os.h
@@ -253,19 +253,6 @@ static inline uint64_t fio_swap64(uint64_t val)
 	__cpu_to_le64(val);			\
 })
 
-#ifndef FIO_HAVE_BLKTRACE
-static inline int is_blktrace(const char *fname, int *need_swap)
-{
-	return 0;
-}
-struct thread_data;
-static inline int load_blktrace(struct thread_data *td, const char *fname,
-				int need_swap)
-{
-	return 1;
-}
-#endif
-
 #define FIO_DEF_CL_SIZE		128
 
 static inline int os_cache_line_size(void)
-- 
2.9.4

[PATCH 2/5] Drop struct thread_data dependency from os headers

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

Since os/os.h is included by fio.h before other functions/structures
are even defined, it's better for os/os*.h not to have dependency on
those (in this case it's struct thread_data and duplicated td_fill_
rand_seeds() prototypes) unless really needed. os/os*.h are basically
collections of small wrappers over syscalls/etc whose idea is similar
but with difference interface among supported platforms, thus they
normally don't need to have dependency on fio functions/structures,
and in fact they're normally designed that way.

This commit gets rid of struct thread_data argument from an inlined
function init_random_state(), which was needed only to call another
function td_fill_rand_seeds(td). This can simply be called from
setup_random_seeds() after init_random_state() without making any
functional difference. Also rename init_random_state() to
init_random_seeds() as it only initializes random seeds now.

With this commit, struct thread_data is completely gone from os/.
struct fio_file is still there, but this is needed by Windows where
the idea of fd differs from unix like in general.

Signed-off-by: Tomohiro Kusumi <tkusumi@tuxera.com>
---
 init.c          | 10 +++++++---
 os/os-windows.h |  4 +---
 os/os.h         |  8 +-------
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/init.c b/init.c
index 52a5f03..d224bd6 100644
--- a/init.c
+++ b/init.c
@@ -1080,8 +1080,12 @@ static int setup_random_seeds(struct thread_data *td)
 	unsigned long seed;
 	unsigned int i;
 
-	if (!td->o.rand_repeatable && !fio_option_is_set(&td->o, rand_seed))
-		return init_random_state(td, td->rand_seeds, sizeof(td->rand_seeds));
+	if (!td->o.rand_repeatable && !fio_option_is_set(&td->o, rand_seed)) {
+		int ret = init_random_seeds(td->rand_seeds, sizeof(td->rand_seeds));
+		if (!ret)
+			td_fill_rand_seeds(td);
+		return ret;
+	}
 
 	seed = td->o.rand_seed;
 	for (i = 0; i < 4; i++)
@@ -1376,7 +1380,7 @@ static int add_job(struct thread_data *td, const char *jobname, int job_add_num,
 	prev_group_jobs++;
 
 	if (setup_random_seeds(td)) {
-		td_verror(td, errno, "init_random_state");
+		td_verror(td, errno, "setup_random_seeds");
 		goto err;
 	}
 
diff --git a/os/os-windows.h b/os/os-windows.h
index 0c8c42d..36b421e 100644
--- a/os/os-windows.h
+++ b/os/os-windows.h
@@ -116,7 +116,6 @@ int nanosleep(const struct timespec *rqtp, struct timespec *rmtp);
 ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
 ssize_t pwrite(int fildes, const void *buf, size_t nbyte,
 		off_t offset);
-extern void td_fill_rand_seeds(struct thread_data *);
 
 static inline int blockdev_size(struct fio_file *f, unsigned long long *bytes)
 {
@@ -239,7 +238,7 @@ static inline int fio_cpuset_exit(os_cpu_mask_t *mask)
 	return 0;
 }
 
-static inline int init_random_state(struct thread_data *td, unsigned long *rand_seeds, int size)
+static inline int init_random_seeds(unsigned long *rand_seeds, int size)
 {
 	HCRYPTPROV hCryptProv;
 
@@ -258,7 +257,6 @@ static inline int init_random_state(struct thread_data *td, unsigned long *rand_
 	}
 
 	CryptReleaseContext(hCryptProv, 0);
-	td_fill_rand_seeds(td);
 	return 0;
 }
 
diff --git a/os/os.h b/os/os.h
index c25cc36..21b7a9d 100644
--- a/os/os.h
+++ b/os/os.h
@@ -303,12 +303,7 @@ static inline long os_random_long(os_random_state_t *rs)
 #endif
 
 #ifdef FIO_USE_GENERIC_INIT_RANDOM_STATE
-extern void td_fill_rand_seeds(struct thread_data *td);
-/*
- * Initialize the various random states we need (random io, block size ranges,
- * read/write mix, etc).
- */
-static inline int init_random_state(struct thread_data *td, unsigned long *rand_seeds, int size)
+static inline int init_random_seeds(unsigned long *rand_seeds, int size)
 {
 	int fd;
 
@@ -323,7 +318,6 @@ static inline int init_random_state(struct thread_data *td, unsigned long *rand_
 	}
 
 	close(fd);
-	td_fill_rand_seeds(td);
 	return 0;
 }
 #endif
-- 
2.9.4

[PATCH 3/5] Drop circular dependency in log.c and lib/output_buffer.c

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

Two files log.c and lib/output_buffer.c have dependency on each other,
i.e. log.c is using buf_output_add() in lib/output_buffer.c, while
lib/output_buffer.c is using log_info_buf() in log.c.

This commit removes this dependency from lib/output_buffer.c by
dropping log_info_buf() call from a library function buf_output_flush(),
and then as a result rename buf_output_flush() to buf_output_clear()
since it's no longer flusing anything. log_info_buf() is now called
independently by __show_run_stats() which was the only caller of
buf_output_flush().

log_info_buf() returning 0 on !len is necessary to keep this commit
without making functional difference. dprint()/log_info() basically
never pass NULL or "" to log_info_buf(), but __show_run_stats() would
pass NULL with length 0 for unused output modes which then needs to
be avoided as a special case.

Signed-off-by: Tomohiro Kusumi <tkusumi@tuxera.com>
---
 lib/output_buffer.c | 8 +-------
 lib/output_buffer.h | 2 +-
 log.c               | 6 ++++++
 stat.c              | 6 ++++--
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/lib/output_buffer.c b/lib/output_buffer.c
index c1fdfc9..313536d 100644
--- a/lib/output_buffer.c
+++ b/lib/output_buffer.c
@@ -3,7 +3,6 @@
 #include <stdlib.h>
 
 #include "output_buffer.h"
-#include "../log.h"
 #include "../minmax.h"
 
 #define BUF_INC	1024
@@ -41,15 +40,10 @@ size_t buf_output_add(struct buf_output *out, const char *buf, size_t len)
 	return len;
 }
 
-size_t buf_output_flush(struct buf_output *out)
+void buf_output_clear(struct buf_output *out)
 {
-	size_t ret = 0;
-
 	if (out->buflen) {
-		ret = log_info_buf(out->buf, out->buflen);
 		memset(out->buf, 0, out->max_buflen);
 		out->buflen = 0;
 	}
-
-	return ret;
 }
diff --git a/lib/output_buffer.h b/lib/output_buffer.h
index 396002f..15ee005 100644
--- a/lib/output_buffer.h
+++ b/lib/output_buffer.h
@@ -12,6 +12,6 @@ struct buf_output {
 void buf_output_init(struct buf_output *out);
 void buf_output_free(struct buf_output *out);
 size_t buf_output_add(struct buf_output *out, const char *buf, size_t len);
-size_t buf_output_flush(struct buf_output *out);
+void buf_output_clear(struct buf_output *out);
 
 #endif
diff --git a/log.c b/log.c
index 4eb4af5..172f153 100644
--- a/log.c
+++ b/log.c
@@ -8,6 +8,12 @@
 
 size_t log_info_buf(const char *buf, size_t len)
 {
+	/*
+	 * buf could be NULL (not just "").
+	 */
+	if (!buf)
+		return 0;
+
 	if (is_backend) {
 		size_t ret = fio_server_text_output(FIO_LOG_INFO, buf, len);
 		if (ret != -1)
diff --git a/stat.c b/stat.c
index 5b48413..1f124a8 100644
--- a/stat.c
+++ b/stat.c
@@ -1825,8 +1825,10 @@ void __show_run_stats(void)
 	}
 
 	for (i = 0; i < FIO_OUTPUT_NR; i++) {
-		buf_output_flush(&output[i]);
-		buf_output_free(&output[i]);
+		struct buf_output *out = &output[i];
+		log_info_buf(out->buf, out->buflen);
+		buf_output_clear(out);
+		buf_output_free(out);
 	}
 
 	log_info_flush();
-- 
2.9.4

[PATCH 4/5] Include sg headers in os/os-linux.h

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

Since sg is Linux kernel's SCSI subsystem specific interface, it's
better to include required headers in os/os-linux.h which also defines
FIO_HAVE_SGIO, rather than conditionally including them in os/os.h.
Android has FIO_HAVE_SGIO disabled, so no need to do this for Android.

Even if another platform implements sg (compatible) ioctls within
their SCSI driver, there is no guarantee the required kernel header
will be "linux/fs.h", which then fails to compile.

Signed-off-by: Tomohiro Kusumi <tkusumi@tuxera.com>
---
 os/os-linux.h | 2 ++
 os/os.h       | 5 -----
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/os/os-linux.h b/os/os-linux.h
index ba53590..0e6246e 100644
--- a/os/os-linux.h
+++ b/os/os-linux.h
@@ -16,6 +16,8 @@
 #include <linux/unistd.h>
 #include <linux/raw.h>
 #include <linux/major.h>
+#include <linux/fs.h>
+#include <scsi/sg.h>
 
 #include "./os-linux-syscall.h"
 #include "binject.h"
diff --git a/os/os.h b/os/os.h
index 21b7a9d..3c96b4d 100644
--- a/os/os.h
+++ b/os/os.h
@@ -60,11 +60,6 @@ typedef struct aiocb os_aiocb_t;
 #endif
 #endif
 
-#ifdef FIO_HAVE_SGIO
-#include <linux/fs.h>
-#include <scsi/sg.h>
-#endif
-
 #ifndef CONFIG_STRSEP
 #include "../oslib/strsep.h"
 #endif
-- 
2.9.4

[PATCH 5/5] Move Linux/ppc64 specific cpu_online() to os/os-linux.h

[kusumi.tomohiro]

From: Tomohiro Kusumi <tkusumi@tuxera.com>

cpu_online() implementation for ppc64 added to os/os.h by c5dd5d97
(powerpc: fix cpus_online() to get correct max CPU number for powerpc64)
seems Linux specific, thus it should be moved to os/os-linux.h.

For example, non standard sysconf values _SC_NPROCESSORS_ONLN and
_SC_NPROCESSORS_CONF do the same thing with libc in FreeBSD, whereas
they aren't always the same with glibc. This implies c5dd5d97 is about
Linux, and wouldn't be a general solution that needs to be in os/os.h.

sysconf(3) in FreeBSD
https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/sysconf.c#L588

Another possibility is AIX in addition to Linux, but below website
has an example of both _SC_NPROCESSORS_ONLN and _SC_NPROCESSORS_CONF
having the same value under SMT.

Topic: prtconf and sysconf produce different numbers of processors
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014250083
Signed-off-by: Tomohiro Kusumi <tkusumi@tuxera.com>
---
 os/os-linux.h | 8 ++++++++
 os/os.h       | 8 --------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/os/os-linux.h b/os/os-linux.h
index 0e6246e..008ce2d 100644
--- a/os/os-linux.h
+++ b/os/os-linux.h
@@ -260,6 +260,14 @@ static inline int arch_cache_line_size(void)
 		return atoi(size);
 }
 
+#ifdef __powerpc64__
+#define FIO_HAVE_CPU_ONLINE_SYSCONF
+static inline unsigned int cpus_online(void)
+{
+        return sysconf(_SC_NPROCESSORS_CONF);
+}
+#endif
+
 static inline unsigned long long get_fs_free_size(const char *path)
 {
 	unsigned long long ret;
diff --git a/os/os.h b/os/os.h
index 3c96b4d..1d400c8 100644
--- a/os/os.h
+++ b/os/os.h
@@ -324,14 +324,6 @@ static inline unsigned long long get_fs_free_size(const char *path)
 }
 #endif
 
-#ifdef __powerpc64__
-#define FIO_HAVE_CPU_ONLINE_SYSCONF
-static inline unsigned int cpus_online(void)
-{
-        return sysconf(_SC_NPROCESSORS_CONF);
-}
-#endif
-
 #ifndef FIO_HAVE_CPU_ONLINE_SYSCONF
 static inline unsigned int cpus_online(void)
 {
-- 
2.9.4

Re: [PATCH 0/5]

[Jens Axboe]

On Tue, May 23 2017, kusumi.tomohiro@gmail.com wrote:
> From: Tomohiro Kusumi <tkusumi@tuxera.com>
> 
> These are another cleanup patches to make it less OS dependent
> (less Linux dependent).
> 
> Tomohiro Kusumi (5):
>   Move {is,load}_blktrace() to a new header blktrace.h
>   Drop struct thread_data dependency from os headers
>   Drop circular dependency in log.c and lib/output_buffer.c
>   Move Linux/ppc64 specific cpu_online() to os/os-linux.h
>   Include sg headers in os/os-linux.h

Looks good, applied, thanks.

-- 
Jens Axboe

[PATCH 0/5]

[Jason Wang]

Hi all:

This series tries to support batched IOTLB updating vhost-vdpa.

Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it
can only forward one mapping to IOMMU or device through IOMMU API or
dma_map(). Though set_map() is designed to have the capability to pass
an rbtree based mapping to vDPA device, it's still be called at least
once for each VHOST_IOTLB_UPDATE or VHOST_IOTLB_INVALIDATE. This is
because vhost-vdpa doesn't know the userspace start or stop then
updating.

So this patch introduces two flags as hints for vhost-vdpa to call
set_map() only when userspace finish a batch of IOTLB updating.

So instead of:

1) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)
2) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)
...
n) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s)

With the help of hints, we do:

0) VHOST_IOTLB_BATCH_START

1) VHOST_IOTLB_UPDATE/INVALIDATE
...
n) VHOST_IOTLB_UPDATE/INVALIDATE

n+1) VHOST_IOTLB_BATCH_END -> set_map()

One one call of set_map() to vDPA device for a batch of IOTLB
mappings. So for the device that has its own DMA translation logic, it
can efficiently structure the memory mapping to get best performance.

Note, this only impacts the devices that want its own DMA
translation (less times of set_map() call). For other type of devices,
there's no changes in the behaviour.

Changes from RFCV1:

- tweak the comments per Michael's request

Jason Wang (5):
  vhost-vdpa: refine ioctl pre-processing
  vhost: generialize backend features setting/getting
  vhost-vdpa: support get/set backend features
  vhost-vdpa: support IOTLB batching hints
  vdpasim: support batch updating

 drivers/vdpa/vdpa_sim/vdpa_sim.c | 40 +++++++++++++++++++++--
 drivers/vhost/net.c              | 18 ++---------
 drivers/vhost/vdpa.c             | 55 ++++++++++++++++++++++++++------
 drivers/vhost/vhost.c            | 15 +++++++++
 drivers/vhost/vhost.h            |  2 ++
 include/uapi/linux/vhost.h       |  2 ++
 include/uapi/linux/vhost_types.h | 11 +++++++
 7 files changed, 114 insertions(+), 29 deletions(-)

-- 
2.20.1