[Lustre-devel] moving obd_fail_check to libcfs

[Nicholas Henke <nic@cray.com>]

di wang wrote:
> Hello,
> Eric Barton wrote:
>> Although I could agree that there should be levels of abstraction
>> above libcfs, it is, de facto, the place we put _all_ generic code
>> - not just stateless porting primitives, but everything that can be
>> used everywhere.
>>
>> I don't actually think of obd_fail_check as inexorably bound with
>> /proc.  But since that's the current implementation, it's probably
>> my oversight not to have shared that sense of direction.
>>
>> Nic, is the patch totally /proc - centric?  Wangdi is doing the work
>> to remove /proc-ness and make our tuneables, configurables and monitoring
>> more portable.  He needs to be involved...

Not totally, no - just the user-space data manipulation. Once that variable is 
set, the code is pretty agnostic.

> Yes, after we have our own /proc stuff in lustre, which might be land to 
> HEAD in 2 or 3 weeks. All the new proc stuff is implemented in libcfs 
> layer, then we will move as much as obd proc stuff(obd lprocfs layer) to 
> libcfs layer, then they(include obd_fail_check) can be shared with LNET.
> 

Is there a branch name I could checkout to look at this ? I'd like to make sure 
the fail_loc move would be easy to tie into that.

> The only difference for those sysctl parameters is that you may not use 
> /etc/sysctl.conf to control them anymore, and lctl set_param is the only 
> interface here.
> 
> Actually, you can also move this now. but it means you need move those 
> obd proc api to libcfs layer,  which  might  not  be  small  amount  of  
> work.

It isn't too bad - they use the CFS_PROC_PROTO and not all of the lprocfs_XXX() 
functionality.

It should like this would have a limited lifetime in 1.6.X and 1.8.X, but I'm 
fine with that. That gives us a bit of time :-)

Nic