* Mainlining Lustre client
@ 2013-04-27 3:33 Peng, Tao
2013-04-27 13:21 ` Greg Kroah-Hartman
0 siblings, 1 reply; 12+ messages in thread
From: Peng, Tao @ 2013-04-27 3:33 UTC (permalink / raw)
To: Greg Kroah-Hartman, Al Viro
Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig, Andreas Dilger,
Matthew Wilcox, Andi Kleen, Theodore Ts'o, Myklebust, Trond,
faibish, sorin, Tang, Haiying
Hello Greg And Al,
In 2012's LSF-MM summit, we discussed briefly about mainlining Lustre[1] client. At that time, Lustre client code was mixing with many obsolete code to support old kernels and other platforms. Also it wasn't updated to latest upstream at that time. As a conclusion of the discussion, People suggested to put the code in staging tree and clean it up there. And I talked to Greg during collaboration summit and he also agreed on it. Thank you guys for your great support!
In the past year, we've done a bunch of cleanups against the code, including removing many unused code, dropping unnecessary checker macros, separating some client and server code routines, removing some cross-platform support code, as well as keeping the code updated against latest upstream. The biggest leftover part is that ideally we can remove the libcfs [4] layer entirely. It has be slow because each removal would touch too many files. We will continue working on it of course. To now, the code is still not clean but we think it has reached a point where we can put it in the staging tree and continue cleaning it up there.
Please note that the patches are huge [3, 5]. It consists of two huge patches for fs/lustre and net/lnet, and two smaller patches modifying Kconfig/Makefile and porting it to 3.9 kernel. Because the patches are too huge, I just gave a pointer to my development repo [4]. We are hoping that we can merge the huge patches and then do incremental cleanups.
Now, we would want to ask for your favor on how we can put the code in staging tree. What are the requirements for being merged in the staging tree? Shall we send the huge patches for review? Which merge window shall we target at? And any other issues you have in mind. Please share your thoughts. Thank you very much!
Best Regards,
Tao
[1] Lustre is the most common used distributed file system in High Performance Computing world. (http://www.lustre.org)
The Lustre community upstream git repository is maintained by Whamcloud (acquired by Intel last year) at http://git.whamcloud.com/?p=fs/lustre-release.git;a=summary
[2] libcfs is a common wrapper layer for kernel primitives so that Lustre can be built on different platforms including Linux, user space, MacOS and even Windows. Sadly it was never completed and only the Linux part is actively in use.
[3] git diff gave "433 files changed, 275260 insertions(+), 0 deletions(-)" for the Lustre client code merge.
[4] https://github.com/bergwolf/linux/tree/3.9-rc3-lustre-base
[5] detailed `git diff --stat v3.9-rc3`
fs/Kconfig | 2 +
fs/Makefile | 1 +
fs/lustre/Kconfig | 34 +
fs/lustre/Makefile | 3 +
fs/lustre/fid/Makefile | 7 +
fs/lustre/fid/fid_handler.c | 661 +++
fs/lustre/fid/fid_internal.h | 86 +
fs/lustre/fid/fid_lib.c | 97 +
fs/lustre/fid/fid_request.c | 522 +++
fs/lustre/fid/fid_store.c | 259 ++
fs/lustre/fid/lproc_fid.c | 360 ++
fs/lustre/fld/Makefile | 7 +
fs/lustre/fld/fld_cache.c | 567 +++
fs/lustre/fld/fld_handler.c | 455 +++
fs/lustre/fld/fld_index.c | 415 ++
fs/lustre/fld/fld_internal.h | 223 +
fs/lustre/fld/fld_request.c | 520 +++
fs/lustre/fld/lproc_fld.c | 365 ++
fs/lustre/include/cl_object.h | 3278 +++++++++++++++
fs/lustre/include/dt_object.h | 1477 +++++++
fs/lustre/include/interval_tree.h | 124 +
fs/lustre/include/ioctl.h | 106 +
fs/lustre/include/lclient.h | 437 ++
fs/lustre/include/linux/lprocfs_status.h | 58 +
fs/lustre/include/linux/lustre_acl.h | 66 +
fs/lustre/include/linux/lustre_common.h | 22 +
fs/lustre/include/linux/lustre_compat25.h | 346 ++
fs/lustre/include/linux/lustre_debug.h | 47 +
fs/lustre/include/linux/lustre_dlm.h | 46 +
fs/lustre/include/linux/lustre_fsfilt.h | 181 +
fs/lustre/include/linux/lustre_handles.h | 53 +
fs/lustre/include/linux/lustre_intent.h | 62 +
fs/lustre/include/linux/lustre_lib.h | 87 +
fs/lustre/include/linux/lustre_lite.h | 100 +
fs/lustre/include/linux/lustre_log.h | 57 +
fs/lustre/include/linux/lustre_net.h | 50 +
fs/lustre/include/linux/lustre_patchless_compat.h | 85 +
fs/lustre/include/linux/lustre_quota.h | 47 +
fs/lustre/include/linux/lustre_user.h | 67 +
fs/lustre/include/linux/lvfs.h | 134 +
fs/lustre/include/linux/lvfs_linux.h | 66 +
fs/lustre/include/linux/obd.h | 128 +
fs/lustre/include/linux/obd_class.h | 58 +
fs/lustre/include/linux/obd_support.h | 63 +
fs/lustre/include/lprocfs_status.h | 1115 +++++
fs/lustre/include/lu_object.h | 1367 +++++++
fs/lustre/include/lu_ref.h | 170 +
fs/lustre/include/lu_target.h | 91 +
fs/lustre/include/lustre/libiam.h | 145 +
fs/lustre/include/lustre/liblustreapi.h | 43 +
fs/lustre/include/lustre/ll_fiemap.h | 121 +
fs/lustre/include/lustre/lustre_build_version.h | 2 +
fs/lustre/include/lustre/lustre_idl.h | 3514 ++++++++++++++++
fs/lustre/include/lustre/lustre_lfsck_user.h | 95 +
fs/lustre/include/lustre/lustre_user.h | 1090 +++++
fs/lustre/include/lustre/lustreapi.h | 308 ++
fs/lustre/include/lustre_acl.h | 42 +
fs/lustre/include/lustre_capa.h | 305 ++
fs/lustre/include/lustre_cfg.h | 299 ++
fs/lustre/include/lustre_debug.h | 76 +
fs/lustre/include/lustre_disk.h | 559 +++
fs/lustre/include/lustre_dlm.h | 1668 ++++++++
fs/lustre/include/lustre_eacl.h | 117 +
fs/lustre/include/lustre_export.h | 389 ++
fs/lustre/include/lustre_fid.h | 707 ++++
fs/lustre/include/lustre_fld.h | 202 +
fs/lustre/include/lustre_fsfilt.h | 48 +
fs/lustre/include/lustre_ha.h | 67 +
fs/lustre/include/lustre_handles.h | 93 +
fs/lustre/include/lustre_idmap.h | 102 +
fs/lustre/include/lustre_import.h | 349 ++
fs/lustre/include/lustre_lib.h | 667 +++
fs/lustre/include/lustre_linkea.h | 57 +
fs/lustre/include/lustre_lite.h | 147 +
fs/lustre/include/lustre_log.h | 566 +++
fs/lustre/include/lustre_mdc.h | 176 +
fs/lustre/include/lustre_mds.h | 81 +
fs/lustre/include/lustre_mdt.h | 84 +
fs/lustre/include/lustre_net.h | 3072 ++++++++++++++
fs/lustre/include/lustre_param.h | 121 +
fs/lustre/include/lustre_quota.h | 239 ++
fs/lustre/include/lustre_req_layout.h | 334 ++
fs/lustre/include/lustre_sec.h | 1145 ++++++
fs/lustre/include/lustre_update.h | 191 +
fs/lustre/include/lustre_ver.h | 24 +
fs/lustre/include/lvfs.h | 57 +
fs/lustre/include/md_object.h | 926 +++++
fs/lustre/include/obd.h | 1687 ++++++++
fs/lustre/include/obd_cache.h | 39 +
fs/lustre/include/obd_cksum.h | 176 +
fs/lustre/include/obd_class.h | 2287 +++++++++++
fs/lustre/include/obd_lov.h | 126 +
fs/lustre/include/obd_ost.h | 98 +
fs/lustre/include/obd_support.h | 851 ++++
fs/lustre/lclient/glimpse.c | 275 ++
fs/lustre/lclient/lcommon_cl.c | 1325 ++++++
fs/lustre/lclient/lcommon_misc.c | 195 +
fs/lustre/ldlm/interval_tree.c | 764 ++++
fs/lustre/ldlm/l_lock.c | 76 +
fs/lustre/ldlm/ldlm_extent.c | 243 ++
fs/lustre/ldlm/ldlm_flock.c | 849 ++++
fs/lustre/ldlm/ldlm_inodebits.c | 75 +
fs/lustre/ldlm/ldlm_internal.h | 277 ++
fs/lustre/ldlm/ldlm_lib.c | 869 ++++
fs/lustre/ldlm/ldlm_lock.c | 2443 +++++++++++
fs/lustre/ldlm/ldlm_lockd.c | 1242 ++++++
fs/lustre/ldlm/ldlm_plain.c | 72 +
fs/lustre/ldlm/ldlm_pool.c | 1407 +++++++
fs/lustre/ldlm/ldlm_request.c | 2333 +++++++++++
fs/lustre/ldlm/ldlm_resource.c | 1425 +++++++
fs/lustre/libcfs/Makefile | 26 +
fs/lustre/libcfs/crc32-pclmul_asm.S | 360 ++
fs/lustre/libcfs/debug.c | 476 +++
fs/lustre/libcfs/fail.c | 137 +
fs/lustre/libcfs/hash.c | 2135 ++++++++++
fs/lustre/libcfs/heap.c | 475 +++
fs/lustre/libcfs/kernel_user_comm.c | 337 ++
fs/lustre/libcfs/libcfs_cpu.c | 204 +
fs/lustre/libcfs/libcfs_lock.c | 192 +
fs/lustre/libcfs/libcfs_mem.c | 205 +
fs/lustre/libcfs/libcfs_string.c | 647 +++
fs/lustre/libcfs/linux/linux-cpu.c | 1085 +++++
fs/lustre/libcfs/linux/linux-crypto-adler.c | 144 +
fs/lustre/libcfs/linux/linux-crypto-crc32.c | 149 +
fs/lustre/libcfs/linux/linux-crypto-crc32pclmul.c | 193 +
fs/lustre/libcfs/linux/linux-crypto.c | 305 ++
fs/lustre/libcfs/linux/linux-curproc.c | 393 ++
fs/lustre/libcfs/linux/linux-debug.c | 264 ++
fs/lustre/libcfs/linux/linux-fs.c | 113 +
fs/lustre/libcfs/linux/linux-lock.c | 38 +
fs/lustre/libcfs/linux/linux-mem.c | 213 +
fs/lustre/libcfs/linux/linux-module.c | 183 +
fs/lustre/libcfs/linux/linux-prim.c | 343 ++
fs/lustre/libcfs/linux/linux-proc.c | 578 +++
fs/lustre/libcfs/linux/linux-sync.c | 35 +
fs/lustre/libcfs/linux/linux-tcpip.c | 658 +++
fs/lustre/libcfs/linux/linux-tracefile.c | 275 ++
fs/lustre/libcfs/linux/linux-tracefile.h | 48 +
fs/lustre/libcfs/linux/linux-utils.c | 75 +
fs/lustre/libcfs/lwt.c | 266 ++
fs/lustre/libcfs/module.c | 498 +++
fs/lustre/libcfs/nidstrings.c | 868 ++++
fs/lustre/libcfs/prng.c | 139 +
fs/lustre/libcfs/tracefile.c | 1195 ++++++
fs/lustre/libcfs/tracefile.h | 340 ++
fs/lustre/libcfs/upcall_cache.c | 462 +++
fs/lustre/libcfs/watchdog.c | 516 +++
fs/lustre/libcfs/workitem.c | 475 +++
fs/lustre/llite/Makefile | 15 +
fs/lustre/llite/dcache.c | 674 +++
fs/lustre/llite/dir.c | 1977 +++++++++
fs/lustre/llite/file.c | 3022 ++++++++++++++
fs/lustre/llite/llite_capa.c | 661 +++
fs/lustre/llite/llite_close.c | 412 ++
fs/lustre/llite/llite_internal.h | 1577 +++++++
fs/lustre/llite/llite_lib.c | 2404 +++++++++++
fs/lustre/llite/llite_mmap.c | 507 +++
fs/lustre/llite/llite_nfs.c | 318 ++
fs/lustre/llite/llite_rmtacl.c | 300 ++
fs/lustre/llite/lloop.c | 869 ++++
fs/lustre/llite/lproc_llite.c | 1379 +++++++
fs/lustre/llite/namei.c | 1278 ++++++
fs/lustre/llite/remote_perm.c | 332 ++
fs/lustre/llite/rw.c | 1319 ++++++
fs/lustre/llite/rw26.c | 586 +++
fs/lustre/llite/statahead.c | 1738 ++++++++
fs/lustre/llite/super25.c | 228 ++
fs/lustre/llite/symlink.c | 192 +
fs/lustre/llite/vvp_dev.c | 547 +++
fs/lustre/llite/vvp_internal.h | 62 +
fs/lustre/llite/vvp_io.c | 1176 ++++++
fs/lustre/llite/vvp_lock.c | 85 +
fs/lustre/llite/vvp_object.c | 187 +
fs/lustre/llite/vvp_page.c | 559 +++
fs/lustre/llite/xattr.c | 578 +++
fs/lustre/lmv/Makefile | 7 +
fs/lustre/lmv/lmv_fld.c | 88 +
fs/lustre/lmv/lmv_intent.c | 317 ++
fs/lustre/lmv/lmv_internal.h | 158 +
fs/lustre/lmv/lmv_obd.c | 2720 +++++++++++++
fs/lustre/lmv/lproc_lmv.c | 242 ++
fs/lustre/lov/Makefile | 11 +
fs/lustre/lov/lov_cl_internal.h | 821 ++++
fs/lustre/lov/lov_dev.c | 533 +++
fs/lustre/lov/lov_ea.c | 338 ++
fs/lustre/lov/lov_internal.h | 321 ++
fs/lustre/lov/lov_io.c | 967 +++++
fs/lustre/lov/lov_lock.c | 1253 ++++++
fs/lustre/lov/lov_log.c | 278 ++
fs/lustre/lov/lov_merge.c | 220 +
fs/lustre/lov/lov_obd.c | 2918 +++++++++++++
fs/lustre/lov/lov_object.c | 939 +++++
fs/lustre/lov/lov_offset.c | 267 ++
fs/lustre/lov/lov_pack.c | 677 +++
fs/lustre/lov/lov_page.c | 236 ++
fs/lustre/lov/lov_pool.c | 683 ++++
fs/lustre/lov/lov_request.c | 1509 +++++++
fs/lustre/lov/lovsub_dev.c | 212 +
fs/lustre/lov/lovsub_io.c | 55 +
fs/lustre/lov/lovsub_lock.c | 485 +++
fs/lustre/lov/lovsub_object.c | 170 +
fs/lustre/lov/lovsub_page.c | 72 +
fs/lustre/lov/lproc_lov.c | 304 ++
fs/lustre/lvfs/Makefile | 8 +
fs/lustre/lvfs/fsfilt.c | 138 +
fs/lustre/lvfs/fsfilt_ext3.c | 751 ++++
fs/lustre/lvfs/lvfs_lib.c | 173 +
fs/lustre/lvfs/lvfs_linux.c | 295 ++
fs/lustre/mdc/Makefile | 7 +
fs/lustre/mdc/lproc_mdc.c | 183 +
fs/lustre/mdc/mdc_internal.h | 180 +
fs/lustre/mdc/mdc_lib.c | 564 +++
fs/lustre/mdc/mdc_locks.c | 1229 ++++++
fs/lustre/mdc/mdc_reint.c | 489 +++
fs/lustre/mdc/mdc_request.c | 2748 +++++++++++++
fs/lustre/mgc/Makefile | 7 +
fs/lustre/mgc/lproc_mgc.c | 68 +
fs/lustre/mgc/mgc_internal.h | 75 +
fs/lustre/mgc/mgc_request.c | 1859 +++++++++
fs/lustre/obdclass/Makefile | 15 +
fs/lustre/obdclass/acl.c | 889 ++++
fs/lustre/obdclass/capa.c | 400 ++
fs/lustre/obdclass/cl_internal.h | 121 +
fs/lustre/obdclass/cl_io.c | 1753 ++++++++
fs/lustre/obdclass/cl_lock.c | 2302 +++++++++++
fs/lustre/obdclass/cl_object.c | 1155 ++++++
fs/lustre/obdclass/cl_page.c | 1605 ++++++++
fs/lustre/obdclass/class_obd.c | 682 ++++
fs/lustre/obdclass/debug.c | 124 +
fs/lustre/obdclass/dt_object.c | 936 +++++
fs/lustre/obdclass/genops.c | 1865 +++++++++
fs/lustre/obdclass/idmap.c | 473 +++
fs/lustre/obdclass/linkea.c | 195 +
fs/lustre/obdclass/linux/linux-module.c | 430 ++
fs/lustre/obdclass/linux/linux-obdo.c | 223 +
fs/lustre/obdclass/linux/linux-sysctl.c | 445 ++
fs/lustre/obdclass/llog-test.c | 1087 +++++
fs/lustre/obdclass/llog.c | 968 +++++
fs/lustre/obdclass/llog_cat.c | 831 ++++
fs/lustre/obdclass/llog_internal.h | 90 +
fs/lustre/obdclass/llog_ioctl.c | 424 ++
fs/lustre/obdclass/llog_lvfs.c | 870 ++++
fs/lustre/obdclass/llog_obd.c | 319 ++
fs/lustre/obdclass/llog_osd.c | 1292 ++++++
fs/lustre/obdclass/llog_swab.c | 395 ++
fs/lustre/obdclass/llog_test.c | 1087 +++++
fs/lustre/obdclass/local_storage.c | 796 ++++
fs/lustre/obdclass/local_storage.h | 76 +
fs/lustre/obdclass/lprocfs_jobstats.c | 575 +++
fs/lustre/obdclass/lprocfs_status.c | 2725 +++++++++++++
fs/lustre/obdclass/lu_object.c | 2287 +++++++++++
fs/lustre/obdclass/lu_ref.c | 51 +
fs/lustre/obdclass/lustre_handles.c | 263 ++
fs/lustre/obdclass/lustre_peer.c | 218 +
fs/lustre/obdclass/md_attrs.c | 202 +
fs/lustre/obdclass/md_local_object.c | 459 +++
fs/lustre/obdclass/mea.c | 112 +
fs/lustre/obdclass/obd_config.c | 1899 +++++++++
fs/lustre/obdclass/obd_mount.c | 3039 ++++++++++++++
fs/lustre/obdclass/obdo.c | 364 ++
fs/lustre/obdclass/statfs_pack.c | 75 +
fs/lustre/obdclass/uuid.c | 82 +
fs/lustre/obdecho/Makefile | 7 +
fs/lustre/obdecho/echo.c | 672 +++
fs/lustre/obdecho/echo_client.c | 3219 +++++++++++++++
fs/lustre/obdecho/echo_internal.h | 47 +
fs/lustre/obdecho/lproc_echo.c | 55 +
fs/lustre/osc/Makefile | 9 +
fs/lustre/osc/lproc_osc.c | 715 ++++
fs/lustre/osc/osc_cache.c | 2926 +++++++++++++
fs/lustre/osc/osc_cl_internal.h | 679 ++++
fs/lustre/osc/osc_dev.c | 261 ++
fs/lustre/osc/osc_internal.h | 207 +
fs/lustre/osc/osc_io.c | 838 ++++
fs/lustre/osc/osc_lock.c | 1663 ++++++++
fs/lustre/osc/osc_object.c | 275 ++
fs/lustre/osc/osc_page.c | 926 +++++
fs/lustre/osc/osc_quota.c | 332 ++
fs/lustre/osc/osc_request.c | 3658 +++++++++++++++++
fs/lustre/ptlrpc/Makefile | 25 +
fs/lustre/ptlrpc/client.c | 3059 ++++++++++++++
fs/lustre/ptlrpc/connection.c | 248 ++
fs/lustre/ptlrpc/events.c | 595 +++
fs/lustre/ptlrpc/gss/Makefile | 10 +
fs/lustre/ptlrpc/gss/gss_api.h | 179 +
fs/lustre/ptlrpc/gss/gss_asn1.h | 84 +
fs/lustre/ptlrpc/gss/gss_bulk.c | 512 +++
fs/lustre/ptlrpc/gss/gss_cli_upcall.c | 447 ++
fs/lustre/ptlrpc/gss/gss_err.h | 193 +
fs/lustre/ptlrpc/gss/gss_generic_token.c | 285 ++
fs/lustre/ptlrpc/gss/gss_internal.h | 526 +++
fs/lustre/ptlrpc/gss/gss_keyring.c | 1418 +++++++
fs/lustre/ptlrpc/gss/gss_krb5.h | 163 +
fs/lustre/ptlrpc/gss/gss_krb5_mech.c | 1786 ++++++++
fs/lustre/ptlrpc/gss/gss_mech_switch.c | 359 ++
fs/lustre/ptlrpc/gss/gss_pipefs.c | 1252 ++++++
fs/lustre/ptlrpc/gss/gss_rawobj.c | 242 ++
fs/lustre/ptlrpc/gss/gss_svc_upcall.c | 1099 +++++
fs/lustre/ptlrpc/gss/lproc_gss.c | 219 +
fs/lustre/ptlrpc/gss/sec_gss.c | 2916 +++++++++++++
fs/lustre/ptlrpc/import.c | 1609 ++++++++
fs/lustre/ptlrpc/layout.c | 2396 +++++++++++
fs/lustre/ptlrpc/llog_client.c | 354 ++
fs/lustre/ptlrpc/llog_net.c | 75 +
fs/lustre/ptlrpc/llog_server.c | 466 +++
fs/lustre/ptlrpc/lproc_ptlrpc.c | 1410 +++++++
fs/lustre/ptlrpc/niobuf.c | 728 ++++
fs/lustre/ptlrpc/nrs.c | 1850 +++++++++
fs/lustre/ptlrpc/nrs_fifo.c | 273 ++
fs/lustre/ptlrpc/pack_generic.c | 2582 ++++++++++++
fs/lustre/ptlrpc/pers.c | 76 +
fs/lustre/ptlrpc/pinger.c | 743 ++++
fs/lustre/ptlrpc/ptlrpc_internal.h | 282 ++
fs/lustre/ptlrpc/ptlrpc_module.c | 154 +
fs/lustre/ptlrpc/ptlrpcd.c | 827 ++++
fs/lustre/ptlrpc/recover.c | 357 ++
fs/lustre/ptlrpc/sec.c | 2465 +++++++++++
fs/lustre/ptlrpc/sec_bulk.c | 883 ++++
fs/lustre/ptlrpc/sec_config.c | 1233 ++++++
fs/lustre/ptlrpc/sec_gc.c | 251 ++
fs/lustre/ptlrpc/sec_lproc.c | 199 +
fs/lustre/ptlrpc/sec_null.c | 464 +++
fs/lustre/ptlrpc/sec_plain.c | 1021 +++++
fs/lustre/ptlrpc/service.c | 3102 ++++++++++++++
fs/lustre/ptlrpc/wirehdr.c | 47 +
fs/lustre/ptlrpc/wiretest.c | 4509 +++++++++++++++++++++
include/linux/libcfs/bitmap.h | 111 +
include/linux/libcfs/curproc.h | 118 +
include/linux/libcfs/libcfs.h | 319 ++
include/linux/libcfs/libcfs_cpu.h | 214 +
include/linux/libcfs/libcfs_crypto.h | 201 +
include/linux/libcfs/libcfs_debug.h | 350 ++
include/linux/libcfs/libcfs_fail.h | 170 +
include/linux/libcfs/libcfs_hash.h | 850 ++++
include/linux/libcfs/libcfs_heap.h | 200 +
include/linux/libcfs/libcfs_ioctl.h | 222 +
include/linux/libcfs/libcfs_kernelcomm.h | 118 +
include/linux/libcfs/libcfs_prim.h | 120 +
include/linux/libcfs/libcfs_private.h | 568 +++
include/linux/libcfs/libcfs_string.h | 137 +
include/linux/libcfs/libcfs_time.h | 132 +
include/linux/libcfs/libcfs_workitem.h | 110 +
include/linux/libcfs/linux/kp30.h | 303 ++
include/linux/libcfs/linux/libcfs.h | 133 +
include/linux/libcfs/linux/linux-bitops.h | 40 +
include/linux/libcfs/linux/linux-cpu.h | 175 +
include/linux/libcfs/linux/linux-crypto.h | 49 +
include/linux/libcfs/linux/linux-fs.h | 95 +
include/linux/libcfs/linux/linux-lock.h | 204 +
include/linux/libcfs/linux/linux-mem.h | 210 +
include/linux/libcfs/linux/linux-prim.h | 307 ++
include/linux/libcfs/linux/linux-tcpip.h | 87 +
include/linux/libcfs/linux/linux-time.h | 278 ++
include/linux/libcfs/linux/linux-types.h | 38 +
include/linux/libcfs/linux/portals_compat25.h | 101 +
include/linux/libcfs/list.h | 44 +
include/linux/libcfs/lucache.h | 162 +
include/linux/libcfs/params_tree.h | 230 ++
include/linux/lnet/api-support.h | 44 +
include/linux/lnet/api.h | 220 +
include/linux/lnet/lib-lnet.h | 874 ++++
include/linux/lnet/lib-types.h | 762 ++++
include/linux/lnet/linux/api-support.h | 43 +
include/linux/lnet/linux/lib-lnet.h | 72 +
include/linux/lnet/linux/lib-types.h | 45 +
include/linux/lnet/linux/lnet.h | 56 +
include/linux/lnet/lnet-sysctl.h | 51 +
include/linux/lnet/lnet.h | 51 +
include/linux/lnet/lnetctl.h | 80 +
include/linux/lnet/lnetst.h | 491 +++
include/linux/lnet/ptllnd.h | 94 +
include/linux/lnet/ptllnd_wire.h | 124 +
include/linux/lnet/socklnd.h | 103 +
include/linux/lnet/types.h | 503 +++
net/Makefile | 1 +
net/lnet/Kconfig | 25 +
net/lnet/Makefile | 2 +
net/lnet/klnds/Makefile | 4 +
net/lnet/klnds/gnilnd/gnilnd.c | 2698 ++++++++++++
net/lnet/klnds/gnilnd/gnilnd.h | 1787 ++++++++
net/lnet/klnds/gnilnd/gnilnd_api_wrap.h | 1505 +++++++
net/lnet/klnds/gnilnd/gnilnd_cb.c | 4362 ++++++++++++++++++++
net/lnet/klnds/gnilnd/gnilnd_conn.c | 2402 +++++++++++
net/lnet/klnds/gnilnd/gnilnd_debug.c | 108 +
net/lnet/klnds/gnilnd/gnilnd_hss_ops.h | 284 ++
net/lnet/klnds/gnilnd/gnilnd_modparams.c | 500 +++
net/lnet/klnds/gnilnd/gnilnd_proc.c | 1260 ++++++
net/lnet/klnds/gnilnd/gnilnd_stack.c | 563 +++
net/lnet/klnds/gnilnd/gnilnd_sysctl.c | 244 ++
net/lnet/klnds/gnilnd/gnilnd_version.h | 1 +
net/lnet/klnds/o2iblnd/Makefile | 7 +
net/lnet/klnds/o2iblnd/o2iblnd.c | 3256 +++++++++++++++
net/lnet/klnds/o2iblnd/o2iblnd.h | 1058 +++++
net/lnet/klnds/o2iblnd/o2iblnd_cb.c | 3529 ++++++++++++++++
net/lnet/klnds/o2iblnd/o2iblnd_modparams.c | 493 +++
net/lnet/klnds/socklnd/Makefile | 9 +
net/lnet/klnds/socklnd/socklnd.c | 2902 +++++++++++++
net/lnet/klnds/socklnd/socklnd.h | 602 +++
net/lnet/klnds/socklnd/socklnd_cb.c | 2664 ++++++++++++
net/lnet/klnds/socklnd/socklnd_lib-linux.c | 1088 +++++
net/lnet/klnds/socklnd/socklnd_lib-linux.h | 91 +
net/lnet/klnds/socklnd/socklnd_modparams.c | 198 +
net/lnet/klnds/socklnd/socklnd_proto.c | 798 ++++
net/lnet/lnet/Makefile | 10 +
net/lnet/lnet/acceptor.c | 528 +++
net/lnet/lnet/api-ni.c | 1941 +++++++++
net/lnet/lnet/config.c | 1265 ++++++
net/lnet/lnet/lib-eq.c | 447 ++
net/lnet/lnet/lib-md.c | 451 ++
net/lnet/lnet/lib-me.c | 297 ++
net/lnet/lnet/lib-move.c | 2447 +++++++++++
net/lnet/lnet/lib-msg.c | 650 +++
net/lnet/lnet/lib-ptl.c | 938 +++++
net/lnet/lnet/lo.c | 120 +
net/lnet/lnet/module.c | 154 +
net/lnet/lnet/peer.c | 337 ++
net/lnet/lnet/router.c | 1693 ++++++++
net/lnet/lnet/router_proc.c | 950 +++++
net/lnet/selftest/Makefile | 7 +
net/lnet/selftest/brw_test.c | 499 +++
net/lnet/selftest/conctl.c | 932 +++++
net/lnet/selftest/conrpc.c | 1399 +++++++
net/lnet/selftest/conrpc.h | 146 +
net/lnet/selftest/console.c | 2072 ++++++++++
net/lnet/selftest/console.h | 232 ++
net/lnet/selftest/framework.c | 1814 +++++++++
net/lnet/selftest/module.c | 170 +
net/lnet/selftest/ping_test.c | 229 ++
net/lnet/selftest/rpc.c | 1665 ++++++++
net/lnet/selftest/rpc.h | 302 ++
net/lnet/selftest/selftest.h | 611 +++
net/lnet/selftest/timer.c | 254 ++
net/lnet/selftest/timer.h | 53 +
433 files changed, 275260 insertions(+), 0 deletions(-)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 3:33 Mainlining Lustre client Peng, Tao
@ 2013-04-27 13:21 ` Greg Kroah-Hartman
2013-04-27 14:39 ` Peng Tao
2013-04-27 15:56 ` Andi Kleen
0 siblings, 2 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2013-04-27 13:21 UTC (permalink / raw)
To: Peng, Tao
Cc: Al Viro, linux-fsdevel@vger.kernel.org, Christoph Hellwig,
Andreas Dilger, Matthew Wilcox, Andi Kleen, Theodore Ts'o,
Myklebust, Trond, faibish, sorin, Tang, Haiying
On Sat, Apr 27, 2013 at 03:33:26AM +0000, Peng, Tao wrote:
> Now, we would want to ask for your favor on how we can put the code in
> staging tree. What are the requirements for being merged in the
> staging tree? Shall we send the huge patches for review? Which merge
> window shall we target at? And any other issues you have in mind.
> Please share your thoughts. Thank you very much!
The rules for staging are:
- it has to build
- it has to be self-contained in drivers/staging/YOUR_NAME/
- it has to have a correct license (i.e. GPLv2 compatible).
- it has to have a TODO file listing what needs to be done in
order to get it out of staging.
that's it.
So make up a big patch, keeping everything in drivers/staging/lustre/
and send it to me and we can go from there.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 13:21 ` Greg Kroah-Hartman
@ 2013-04-27 14:39 ` Peng Tao
2013-04-27 15:56 ` Andi Kleen
1 sibling, 0 replies; 12+ messages in thread
From: Peng Tao @ 2013-04-27 14:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Al Viro, linux-fsdevel@vger.kernel.org, Christoph Hellwig,
Andreas Dilger, Matthew Wilcox, Andi Kleen, Theodore Ts'o,
Myklebust, Trond, faibish, sorin, Tang, Haiying
Hi Greg,
On Sat, Apr 27, 2013 at 9:21 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Apr 27, 2013 at 03:33:26AM +0000, Peng, Tao wrote:
>> Now, we would want to ask for your favor on how we can put the code in
>> staging tree. What are the requirements for being merged in the
>> staging tree? Shall we send the huge patches for review? Which merge
>> window shall we target at? And any other issues you have in mind.
>> Please share your thoughts. Thank you very much!
>
> The rules for staging are:
> - it has to build
> - it has to be self-contained in drivers/staging/YOUR_NAME/
> - it has to have a correct license (i.e. GPLv2 compatible).
> - it has to have a TODO file listing what needs to be done in
> order to get it out of staging.
> that's it.
>
> So make up a big patch, keeping everything in drivers/staging/lustre/
> and send it to me and we can go from there.
>
Great, thank you very much for the instructions! I will create the big
patch and send it to you soon.
Best Regards,
Tao
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 13:21 ` Greg Kroah-Hartman
2013-04-27 14:39 ` Peng Tao
@ 2013-04-27 15:56 ` Andi Kleen
2013-04-27 16:12 ` Peng Tao
1 sibling, 1 reply; 12+ messages in thread
From: Andi Kleen @ 2013-04-27 15:56 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Peng, Tao, Al Viro, linux-fsdevel@vger.kernel.org,
Christoph Hellwig, Andreas Dilger, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
> The rules for staging are:
> - it has to build
> - it has to be self-contained in drivers/staging/YOUR_NAME/
> - it has to have a correct license (i.e. GPLv2 compatible).
> - it has to have a TODO file listing what needs to be done in
> order to get it out of staging.
> that's it.
Traditionally Lustre needed some patches in fs/*
I don't know if that's still the case.
But if yes you would likely need to get those in first separately.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 15:56 ` Andi Kleen
@ 2013-04-27 16:12 ` Peng Tao
2013-04-27 19:09 ` Andreas Dilger
2013-04-30 21:20 ` J. Bruce Fields
0 siblings, 2 replies; 12+ messages in thread
From: Peng Tao @ 2013-04-27 16:12 UTC (permalink / raw)
To: Andi Kleen
Cc: Greg Kroah-Hartman, Al Viro, linux-fsdevel@vger.kernel.org,
Christoph Hellwig, Andreas Dilger, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
On Sat, Apr 27, 2013 at 11:56 PM, Andi Kleen <ak@linux.intel.com> wrote:
>> The rules for staging are:
>> - it has to build
>> - it has to be self-contained in drivers/staging/YOUR_NAME/
>> - it has to have a correct license (i.e. GPLv2 compatible).
>> - it has to have a TODO file listing what needs to be done in
>> order to get it out of staging.
>> that's it.
>
> Traditionally Lustre needed some patches in fs/*
> I don't know if that's still the case.
>
> But if yes you would likely need to get those in first separately.
>
Those are only needed for Lustre server now. For client, there is no
need to patch other parts out side of fs/lustre and net/lnet.
But thanks for mentioning.
Best Regards,
Tao
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 16:12 ` Peng Tao
@ 2013-04-27 19:09 ` Andreas Dilger
2013-04-28 2:54 ` Peng Tao
2013-04-30 21:20 ` J. Bruce Fields
1 sibling, 1 reply; 12+ messages in thread
From: Andreas Dilger @ 2013-04-27 19:09 UTC (permalink / raw)
To: Peng Tao
Cc: Andi Kleen, Greg Kroah-Hartman, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
On 2013-04-27, at 10:12 AM, Peng Tao wrote:
> On Sat, Apr 27, 2013 at 11:56 PM, Andi Kleen <ak@linux.intel.com> wrote:
>>> The rules for staging are:
>>> - it has to build
>>> - it has to be self-contained in drivers/staging/YOUR_NAME/
>>> - it has to have a correct license (i.e. GPLv2 compatible).
>>> - it has to have a TODO file listing what needs to be done in
>>> order to get it out of staging.
>>> that's it.
>>
>> Traditionally Lustre needed some patches in fs/*
>> I don't know if that's still the case.
>>
>> But if yes you would likely need to get those in first separately.
>
> Those are only needed for Lustre server now. For client, there is no
> need to patch other parts out side of fs/lustre and net/lnet.
>
> But thanks for mentioning.
Tao,
thanks for starting to look into this.
Does it really make sense to stage a filesystem under drivers/*?
IMHO it makes a lot more sense to put the components into the
location where they would live in the upstream kernel tree (i.e.
fs/lustre and net/lnet).
Also a question for you - what version of the Lustre client
are you intending to submit to the staging tree? We are very close
to the 2.4.0 release, so it definitely makes sense to start with
that one.
There is also the question of how you will keep the staging client
in-sync with the development done in the upstream Lustre repo?
There has definitely been a lot of work done to clean up the
Lustre code, but there is still a considerable amount of work
left to be done. In particular, the CLIO layer needs a bunch of
cleanup to become more efficient and understandable.
Cheers, Andreas
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 19:09 ` Andreas Dilger
@ 2013-04-28 2:54 ` Peng Tao
2013-04-29 2:46 ` Greg Kroah-Hartman
0 siblings, 1 reply; 12+ messages in thread
From: Peng Tao @ 2013-04-28 2:54 UTC (permalink / raw)
To: Andreas Dilger
Cc: Andi Kleen, Greg Kroah-Hartman, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
Hi Andreas,
On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@dilger.ca> wrote:
>
> Tao,
> thanks for starting to look into this.
>
Thank you for not complaining me creating more work for you :)
> Does it really make sense to stage a filesystem under drivers/*?
> IMHO it makes a lot more sense to put the components into the
> location where they would live in the upstream kernel tree (i.e.
> fs/lustre and net/lnet).
>
This is how current patches are created. And I agree with you that
putting the code in fs/lustre and net/lnet and depending on
CONFIG_STAGING will be more convenient for future development. It is
also what Trond suggested in last year's LSF-MM summit. Personally I
am OK with either way though.
So it is indeed a question to Greg and Al: Do you have any objections
if we put lustre client code in fs/lustre and net/lnet, depending it
on CONFIG_STAGING? Thanks very much!
> Also a question for you - what version of the Lustre client
> are you intending to submit to the staging tree? We are very close
> to the 2.4.0 release, so it definitely makes sense to start with
> that one.
>
The current patch was created before LUG 2013, based on Whamcloud's
master HEAD at that time, plus several under-review patches in Intel
Jira to get 3.8/3.9 kernel support and code extraction. I will create
the new big patch based on the current master HEAD which is closer to
the 2.4.0 release. And future patches can be ported to staging client
incrementally. Does it sound OK to you?
> There is also the question of how you will keep the staging client
> in-sync with the development done in the upstream Lustre repo?
>
Certainly patches will be ported between staging client and the
development done in Lustre repo back and forth. All bugfix and new
feature patches will be ported to staging client. Cleanup patches will
also be ported to Lustre repo when necessary. As HCH once mentioned,
it is a price we must pay to get a long-time out-of-tree file system
mainlined :-)
> There has definitely been a lot of work done to clean up the
> Lustre code, but there is still a considerable amount of work
> left to be done. In particular, the CLIO layer needs a bunch of
> cleanup to become more efficient and understandable.
>
I agree that there is still a fair amount of work left. IMHO, the CLIO
layer cleanup is more about coping with upstream kernel's
readahead/writeback mechanisms and thus it should more or less involve
Al, Christoph and maybe others' (like Fengguang Wu's) opinions. So it
can be done during the staging time.
Thanks for your strong support all the time!
Best Regards,
Tao
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-28 2:54 ` Peng Tao
@ 2013-04-29 2:46 ` Greg Kroah-Hartman
2013-04-30 14:04 ` Peng Tao
0 siblings, 1 reply; 12+ messages in thread
From: Greg Kroah-Hartman @ 2013-04-29 2:46 UTC (permalink / raw)
To: Peng Tao
Cc: Andreas Dilger, Andi Kleen, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
On Sun, Apr 28, 2013 at 10:54:12AM +0800, Peng Tao wrote:
> On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@dilger.ca> wrote:
> > Does it really make sense to stage a filesystem under drivers/*?
> > IMHO it makes a lot more sense to put the components into the
> > location where they would live in the upstream kernel tree (i.e.
> > fs/lustre and net/lnet).
> >
> This is how current patches are created. And I agree with you that
> putting the code in fs/lustre and net/lnet and depending on
> CONFIG_STAGING will be more convenient for future development. It is
> also what Trond suggested in last year's LSF-MM summit. Personally I
> am OK with either way though.
>
> So it is indeed a question to Greg and Al: Do you have any objections
> if we put lustre client code in fs/lustre and net/lnet, depending it
> on CONFIG_STAGING? Thanks very much!
I will not touch any code outside of drivers/staging/ so you need to
coordinate this with the network and fs maintainers if you don't want
the code in drivers/staging/
Personally, I'd recommend not putting it in fs/ and net/ because it
really isn't ready for that part of the kernel. Also, no one will
realize it is there to be cleaned up, so you will not get help from
others on this. Also, the TAINT_CRAP will not apply to your code, which
is usually not a good thing, because you want your users to realize
this.
And yes, we have had filesystems under drivers/staging. Heck, we had a
whole subarch in there for a while, as long as it's self-contained, I
don't have a probelm with it.
But, if you are just trying to get around the Red Hat rule that they
don't enable drivers in drivers/staging/ well, that's some politics that
I don't want to get in the middle of.
So, again, I'll gladly take the code in drivers/staging/ whenever you
can send me the patch. If you don't want it there, then I can't help
you out.
It's your call,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-29 2:46 ` Greg Kroah-Hartman
@ 2013-04-30 14:04 ` Peng Tao
0 siblings, 0 replies; 12+ messages in thread
From: Peng Tao @ 2013-04-30 14:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andreas Dilger, Andi Kleen, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Matthew Wilcox,
Theodore Ts'o, Myklebust, Trond, faibish, sorin,
Tang, Haiying
On Mon, Apr 29, 2013 at 10:46 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sun, Apr 28, 2013 at 10:54:12AM +0800, Peng Tao wrote:
>> On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@dilger.ca> wrote:
>> > Does it really make sense to stage a filesystem under drivers/*?
>> > IMHO it makes a lot more sense to put the components into the
>> > location where they would live in the upstream kernel tree (i.e.
>> > fs/lustre and net/lnet).
>> >
>> This is how current patches are created. And I agree with you that
>> putting the code in fs/lustre and net/lnet and depending on
>> CONFIG_STAGING will be more convenient for future development. It is
>> also what Trond suggested in last year's LSF-MM summit. Personally I
>> am OK with either way though.
>>
>> So it is indeed a question to Greg and Al: Do you have any objections
>> if we put lustre client code in fs/lustre and net/lnet, depending it
>> on CONFIG_STAGING? Thanks very much!
>
> I will not touch any code outside of drivers/staging/ so you need to
> coordinate this with the network and fs maintainers if you don't want
> the code in drivers/staging/
>
> Personally, I'd recommend not putting it in fs/ and net/ because it
> really isn't ready for that part of the kernel. Also, no one will
> realize it is there to be cleaned up, so you will not get help from
> others on this. Also, the TAINT_CRAP will not apply to your code, which
> is usually not a good thing, because you want your users to realize
> this.
>
> And yes, we have had filesystems under drivers/staging. Heck, we had a
> whole subarch in there for a while, as long as it's self-contained, I
> don't have a probelm with it.
>
Hi Greg,
Thanks for confirming. I will regenerate the patch and put it under
drivers/staging. We can continue the cleanup work there.
> But, if you are just trying to get around the Red Hat rule that they
> don't enable drivers in drivers/staging/ well, that's some politics that
> I don't want to get in the middle of.
>
No, we just want the code mainlined, no intension to mess with Red Hat
rules. :) Red Hat users are well supported by third party packages
provided by Intel/Whamcloud ATM.
> So, again, I'll gladly take the code in drivers/staging/ whenever you
> can send me the patch. If you don't want it there, then I can't help
> you out.
>
Thanks for your support! Will send you the patch once it is ready.
Best Regards,
Tao
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mainlining Lustre client
2013-04-27 16:12 ` Peng Tao
2013-04-27 19:09 ` Andreas Dilger
@ 2013-04-30 21:20 ` J. Bruce Fields
2013-04-30 22:11 ` faibish, sorin
1 sibling, 1 reply; 12+ messages in thread
From: J. Bruce Fields @ 2013-04-30 21:20 UTC (permalink / raw)
To: Peng Tao
Cc: Andi Kleen, Greg Kroah-Hartman, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Andreas Dilger,
Matthew Wilcox, Theodore Ts'o, Myklebust, Trond,
faibish, sorin, Tang, Haiying
On Sun, Apr 28, 2013 at 12:12:27AM +0800, Peng Tao wrote:
> On Sat, Apr 27, 2013 at 11:56 PM, Andi Kleen <ak@linux.intel.com> wrote:
> >> The rules for staging are:
> >> - it has to build
> >> - it has to be self-contained in drivers/staging/YOUR_NAME/
> >> - it has to have a correct license (i.e. GPLv2 compatible).
> >> - it has to have a TODO file listing what needs to be done in
> >> order to get it out of staging.
> >> that's it.
> >
> > Traditionally Lustre needed some patches in fs/*
> > I don't know if that's still the case.
> >
> > But if yes you would likely need to get those in first separately.
> >
> Those are only needed for Lustre server now. For client, there is no
> need to patch other parts out side of fs/lustre and net/lnet.
The Lustre server is in kernel? Are there plans to mainline that?
If not, what does someone need to get to test the client?
--b.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Mainlining Lustre client
2013-04-30 21:20 ` J. Bruce Fields
@ 2013-04-30 22:11 ` faibish, sorin
2013-04-30 22:29 ` faibish, sorin
0 siblings, 1 reply; 12+ messages in thread
From: faibish, sorin @ 2013-04-30 22:11 UTC (permalink / raw)
To: J. Bruce Fields, Peng, Tao
Cc: Andi Kleen, Greg Kroah-Hartman, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Andreas Dilger,
Matthew Wilcox, Theodore Ts'o, Myklebust, Trond,
Tang, Haiying, John Carrier
-----Original Message-----
From: linux-fsdevel-owner@vger.kernel.org [mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of J. Bruce Fields
Sent: Tuesday, April 30, 2013 5:21 PM
To: Peng, Tao
Cc: Andi Kleen; Greg Kroah-Hartman; Al Viro; linux-fsdevel@vger.kernel.org; Christoph Hellwig; Andreas Dilger; Matthew Wilcox; Theodore Ts'o; Myklebust, Trond; faibish, sorin; Tang, Haiying
Subject: Re: Mainlining Lustre client
On Sun, Apr 28, 2013 at 12:12:27AM +0800, Peng Tao wrote:
> On Sat, Apr 27, 2013 at 11:56 PM, Andi Kleen <ak@linux.intel.com> wrote:
> >> The rules for staging are:
> >> - it has to build
> >> - it has to be self-contained in drivers/staging/YOUR_NAME/
> >> - it has to have a correct license (i.e. GPLv2 compatible).
> >> - it has to have a TODO file listing what needs to be done in
> >> order to get it out of staging.
> >> that's it.
> >
> > Traditionally Lustre needed some patches in fs/* I don't know if
> > that's still the case.
> >
> > But if yes you would likely need to get those in first separately.
> >
> Those are only needed for Lustre server now. For client, there is no
> need to patch other parts out side of fs/lustre and net/lnet.
The Lustre server is in kernel? Are there plans to mainline that?
[SF] There is an open source Linux server that is supported by latest kernels that can be installed on any Linux server and can be used for testing at: http://git.whamcloud.com/?p=fs/lustre-release.git;a=summary. At this time we didn't look at mainline the server but if there is interest we can consider this option in the OpenSFS community.
If not, what does someone need to get to test the client?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Mainlining Lustre client
2013-04-30 22:11 ` faibish, sorin
@ 2013-04-30 22:29 ` faibish, sorin
0 siblings, 0 replies; 12+ messages in thread
From: faibish, sorin @ 2013-04-30 22:29 UTC (permalink / raw)
To: faibish, sorin, J. Bruce Fields, Peng, Tao
Cc: Andi Kleen, Greg Kroah-Hartman, Al Viro,
linux-fsdevel@vger.kernel.org, Christoph Hellwig, Andreas Dilger,
Matthew Wilcox, Theodore Ts'o, Myklebust, Trond,
Tang, Haiying, John Carrier
-----Original Message-----
From: linux-fsdevel-owner@vger.kernel.org [mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of faibish, sorin
Sent: Tuesday, April 30, 2013 6:12 PM
To: J. Bruce Fields; Peng, Tao
Cc: Andi Kleen; Greg Kroah-Hartman; Al Viro; linux-fsdevel@vger.kernel.org; Christoph Hellwig; Andreas Dilger; Matthew Wilcox; Theodore Ts'o; Myklebust, Trond; Tang, Haiying; John Carrier
Subject: RE: Mainlining Lustre client
-----Original Message-----
From: linux-fsdevel-owner@vger.kernel.org [mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of J. Bruce Fields
Sent: Tuesday, April 30, 2013 5:21 PM
To: Peng, Tao
Cc: Andi Kleen; Greg Kroah-Hartman; Al Viro; linux-fsdevel@vger.kernel.org; Christoph Hellwig; Andreas Dilger; Matthew Wilcox; Theodore Ts'o; Myklebust, Trond; faibish, sorin; Tang, Haiying
Subject: Re: Mainlining Lustre client
On Sun, Apr 28, 2013 at 12:12:27AM +0800, Peng Tao wrote:
> On Sat, Apr 27, 2013 at 11:56 PM, Andi Kleen <ak@linux.intel.com> wrote:
> >> The rules for staging are:
> >> - it has to build
> >> - it has to be self-contained in drivers/staging/YOUR_NAME/
> >> - it has to have a correct license (i.e. GPLv2 compatible).
> >> - it has to have a TODO file listing what needs to be done in
> >> order to get it out of staging.
> >> that's it.
> >
> > Traditionally Lustre needed some patches in fs/* I don't know if
> > that's still the case.
> >
> > But if yes you would likely need to get those in first separately.
> >
> Those are only needed for Lustre server now. For client, there is no
> need to patch other parts out side of fs/lustre and net/lnet.
The Lustre server is in kernel? Are there plans to mainline that?
[SF] There is an open source Linux server that is supported by latest kernels that can be installed on any Linux server and can be used for testing at: http://git.whamcloud.com/?p=fs/lustre-release.git;a=summary. At this time we didn't look at mainline the server but if there is interest we can consider this option in the OpenSFS community.
[SF] BTW this reference could be useful: http://cloudscale.com/index.php/technology/lustre-on-aws-cloud to build a test bench for Lustre server.
If not, what does someone need to get to test the client?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-04-30 22:30 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-27 3:33 Mainlining Lustre client Peng, Tao
2013-04-27 13:21 ` Greg Kroah-Hartman
2013-04-27 14:39 ` Peng Tao
2013-04-27 15:56 ` Andi Kleen
2013-04-27 16:12 ` Peng Tao
2013-04-27 19:09 ` Andreas Dilger
2013-04-28 2:54 ` Peng Tao
2013-04-29 2:46 ` Greg Kroah-Hartman
2013-04-30 14:04 ` Peng Tao
2013-04-30 21:20 ` J. Bruce Fields
2013-04-30 22:11 ` faibish, sorin
2013-04-30 22:29 ` faibish, sorin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).