[LU-5065] lfs should dogfood llapi

Related — Tue, 3 Jun 2014 07:02:54 +0000

As a means to improving/maintaining the usability of llapi (the library defined by lustre/include/lustre/lustreapi.h) I propose that lustre/utils/lfs.c be allowed only to depend on that header and other non-Lustre, non-libcfs, non-lnet headers. This will help us to ensure that the definitions needed to properly use the functions/functionality exported in by llapi are also present. This will require us moving some definitions from lustre_idl.h to lustre_user.h. (I would prefer that llapi properly encapsulate the lustre ioctls and that the contents of lustre_user.h not be exposed via lustreapi.h but proposal to move us in this direction met with disapproval, see the discussion on ~~LU-5011~~.)

Currently lfs depends on the following headers:

/* For dirname() */
#include <libgen.h>

#include <lnet/lnetctl.h>

#include <libcfs/libcfs.h>
#include <lustre/lustre_idl.h>
#include <lustre/lustreapi.h>

#include <libcfs/libcfsutil.h>
#include "obdctl.h"

Here are some goals for people to complain about:

Move everything in lustre_idl.h that is needed to build lfs to lustre_user.h.

Add the following gem to the end of lfs.c:

#ifdef _LUSTRE_IDL_H_
# error "lfs should not include lustre_idl.h"
#endif

Add similar preprocessor trickery to ensure that we're not depending on config.h.
Remove libcfsutil.h. Does anyone actually use the interactive mode of lfs? I've only done so by accident.

lfs also does some mystery cruft with ptl_initialize(), obd_initialize(), obd_finalize() which I believe is only to support llapi_ping_target(). Perhaps this could be moved to lctl, or into llapi, or rewritten to use /proc (or /sys), or deleted entirely. Can anyone offer a convincing explanation as to why users should (be allowed to) ping targets in the first place?

Whamcloud Community JIRA

[LU-5065] lfs should dogfood llapi