[lustre-devel] lprocfs Helper Issues
Drokin, Oleg
oleg.drokin at intel.com
Fri Oct 2 17:29:52 PDT 2015
On Oct 2, 2015, at 8:26 PM, Christopher J. Morrone wrote:
> On 09/30/2015 08:21 PM, Drokin, Oleg wrote:
>>
>> On Sep 30, 2015, at 8:32 PM, Christopher J. Morrone wrote:
>>
>>> On 09/30/2015 12:46 PM, Di Natale, Giuseppe wrote:
>>>> I looked around to see where the helpers are used. It looks to me that they are always used in proc related functions. I agree with the issues you mentioned at the top of the email as well.
>>>
>>> Yes, but I meant to say we need to consider future use. Largely motivated by the effort to upstream the Lustre client into Linux, the /proc interfaces are slowly going away. So I was just suggesting that we should check that these functions will still be used by the new debugfs/sysfs/whatever interfaces in the future. Nothing really needed to consider though; they are generic enough to still be used well into the future.
>>
>> The thing with the upstream kernel is that effectively procfs was split into two parts. The parts that are 1 value per file are in sysfs, the rest is in ldiskfs and resuses huge chunks
>> of old code (including the functions mentioned).
>> This is not to say we cannot replace them, of course.
>> But upstream they want us to explore other avenues for many of our stuff too, like perf code for performance/usage gathering.
>
> Yes, and ultimately they might be opposed to even doing this much parsing of user strings in kernel space. I can see an argument for sys files only taking simple integers, and leaving it to lustre libraries and command line tools to all niceties like specifying a number with units.
The universal agreement that I heard so far is "you can do whatever you want in debugfs as long as your code works with debugfs disabled".
> But in the sort term, cleaning up these functions is only a good thing, I think.
Indeed.
Bye,
Oleg
More information about the lustre-devel
mailing list