[lustre-devel] An alternate approach to preparing lustre for upstream submission

[NeilBrown]

Hi Andreas,
 thanks for your thorough review.

 I've created

  LU-14291 - Improve use of HAVE_SERVER_SUPPORT and others for
    Linux-kernel client
  LU-14290 - Convert fault-injection framework to match the model using
    in linux
  LU-14289 - Restrict libcfs to compatibility code only
  LU-14288 - Enhance nodemap ranges to work better with IPv6

 With respect to CDEBUG(), while no-one else may have stated a
 requirement to remove CDEBUG() for upstream submission, it is something
 that I personally feel strongly about.
 It isn't CDEBUG itself that is the problem, it is the back-end code for
 gathering the logs and writing them out.  I wouldn't feel comfortable
 submitting that code upstream.  This is the ring-buffer code that you
 mentioned.

 While tracepoint are often quite verbose code-wise as you suggest, I
 don't think they have to be.  I think (without actually having tried
 it) that trace_printk() can be used to crate an alternate CDEBUG()
 macro, so that all the CDEBUG() calls can be left unchanged.
 Converting some or all of these to more traditional tracepoints could
 be done later as the need or desire arose.  I will see if I can make
 this work in due course.

 I'm looking forward to the 2.14.0 release :-)

Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20210104/c6424ed9/attachment.sig>