This is useful for applications even if they elect not to use the SPDK
event framework.
This doesn't shift everything in one go - just the subsystem
initialization logic. Configuration file loading also needs to move
in a separate patch later.
Change-Id: Id419df1045442d416650ed90e5ee78adfdd623d7
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6641
Community-CI: Broadcom CI
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Paul Luse <paul.e.luse@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
All of our Makefiles duplicate huge lists of libraries
in SPDK_LIB_LIST. We have a very precise and accurate
accounting of the library dependencies in
mk/spdk.lib_deps.mk which can be used to generate
the full list if the app specifies the modules and
subsystem libraries it wishes to link.
I did a first pass through all of the existing
Makefiles to take advantage of this new functionality.
There may be more optimizations we can make later but
don't want to hold up this patch for all of them.
Signed-off-by: Jim Harris <james.r.harris@intel.com>
Change-Id: Icdaf6f749a6908df2c2ce2db22631a4af4ff3a9e
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/5553
Community-CI: Broadcom CI
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
spdk_dd is a tool for coping data to/from files
and SPDK bdevs efficiently.
This is initial patch preparing files, application
help output and arguments parser.
Signed-off-by: Maciej Szwed <maciej.szwed@intel.com>
Change-Id: Iee31df6f9f4ac1f64d96a30bb4c16fdf285df22e
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/2925
Community-CI: Broadcom CI
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
