[lustre-devel] [PATCH 00/24] lustre - more cleanups including module reduction.

[Patrick Farrell]

Ah, sorry, lost your mail in the shuffle, Neil.

The name, mostly.  ptlrpc is one subdirectory and one subsystem, so I don’t want to use it for a module that explicitly includes all of several.  I’m not sure of a better name immediately - is this module intended to be shared between client and server?


________________________________
From: James Simmons <jsimmons at infradead.org>
Sent: Monday, June 25, 2018 8:13:22 PM
To: NeilBrown
Cc: Patrick Farrell; Andreas Dilger; Oleg Drokin; Lustre Development List
Subject: Re: [lustre-devel] [PATCH 00/24] lustre - more cleanups including module reduction.


> > Ah, thanks Andreas.  Perhaps not coincidentally, Lustre 2.4 is the first release I worked on.
> >
> > Neil, I am really unenamored of the idea of the shared ptlrpc ldlm module being named ptlrpc...
>
> Can you say why?  Is it the choice of name that bothers you, or the
> combining of two things into the one kernel module, or something else?
> Currently in  git://git.hpdd.intel.com/fs/lustre-release.git
> (or the git tree that was until recently at the above address),
> the module named "ptlrpc" contains ptlrpc code, ldlm code, and target
> code.  I wonder what "target" means in this context.

target is the server code built into ptlrpc which is for the "Unified
Target". Its the shared code that is used by both the MDS and OSS code.
Andreas or Oleg can add more details than this. BTW also the nodemap
code also get built into ptlrpc module as well for the server side.

> > Also, Lustre currently has a bunch of module parameters which are used for configuration.  Thoughts on that?
>
> Yes, the module parameters are an interesting part of the story.
> libcfs has a bunch of module parameters that are symlinked from debugfs.
> It seems that user-space largely uses the debugfs links to access them,
> so they can become part of the "lnet" module with minimal pain.
> Other modules have parameters that I haven't yet looked in to.
>
> There probably will need to be user-space changes to support reduction
> in the number of modules.

The test suite will need some changes since it loads the modules. We
need to handle the case if its built into the kernel as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20180626/bc8c6124/attachment.html>