<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
Ah, sorry, lost your mail in the shuffle, Neil.<br>
<br>
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?<br>
<br>
<br>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> James Simmons <jsimmons@infradead.org><br>
<b>Sent:</b> Monday, June 25, 2018 8:13:22 PM<br>
<b>To:</b> NeilBrown<br>
<b>Cc:</b> Patrick Farrell; Andreas Dilger; Oleg Drokin; Lustre Development List<br>
<b>Subject:</b> Re: [lustre-devel] [PATCH 00/24] lustre - more cleanups including module reduction.</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
> > Ah, thanks Andreas. Perhaps not coincidentally, Lustre 2.4 is the first release I worked on.<br>
> ><br>
> > Neil, I am really unenamored of the idea of the shared ptlrpc ldlm module being named ptlrpc...<br>
> <br>
> Can you say why? Is it the choice of name that bothers you, or the<br>
> combining of two things into the one kernel module, or something else?<br>
> Currently in git://git.hpdd.intel.com/fs/lustre-release.git<br>
> (or the git tree that was until recently at the above address),<br>
> the module named "ptlrpc" contains ptlrpc code, ldlm code, and target<br>
> code. I wonder what "target" means in this context.<br>
<br>
target is the server code built into ptlrpc which is for the "Unified <br>
Target". Its the shared code that is used by both the MDS and OSS code.<br>
Andreas or Oleg can add more details than this. BTW also the nodemap<br>
code also get built into ptlrpc module as well for the server side.<br>
<br>
> > Also, Lustre currently has a bunch of module parameters which are used for configuration. Thoughts on that?<br>
> <br>
> Yes, the module parameters are an interesting part of the story.<br>
> libcfs has a bunch of module parameters that are symlinked from debugfs.<br>
> It seems that user-space largely uses the debugfs links to access them,<br>
> so they can become part of the "lnet" module with minimal pain.<br>
> Other modules have parameters that I haven't yet looked in to.<br>
> <br>
> There probably will need to be user-space changes to support reduction<br>
> in the number of modules.<br>
<br>
The test suite will need some changes since it loads the modules. We<br>
need to handle the case if its built into the kernel as well.<br>
</div>
</span></font></div>
</body>
</html>