* [Lustre-devel] moving obd_fail_check to libcfs
@ 2009-02-22 17:15 Nic Henke
2009-02-23 8:11 ` Robert Read
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Nic Henke @ 2009-02-22 17:15 UTC (permalink / raw)
To: lustre-devel
Would there be any objection to a patch that'd move the current
obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
able to use the same logic inside LNET and our new LND without
replicating the code.
I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.
Thoughts or suggestions?
Nic
^ permalink raw reply [flat|nested] 8+ messages in thread* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-22 17:15 [Lustre-devel] moving obd_fail_check to libcfs Nic Henke @ 2009-02-23 8:11 ` Robert Read 2009-02-23 21:39 ` Eric Barton 2009-02-23 14:56 ` Eric Barton 2009-03-09 20:26 ` Nicholas Henke 2 siblings, 1 reply; 8+ messages in thread From: Robert Read @ 2009-02-23 8:11 UTC (permalink / raw) To: lustre-devel I don't think libcfs currently initializes any proc entries, so it's not clear how you will set obd_fail_loc. In theory libcfs should just thin library of porting primitives, and things like logging and fail_check should be in a layer just above libcfs which could have a management interface. So far we've just put some extra low-level functionality into libcfs, but at some point it should be refactored. I think when we need to add initialization code and an interface is that point. robert On Feb 22, 2009, at 8:15 PM, Nic Henke wrote: > Would there be any objection to a patch that'd move the current > obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be > able to use the same logic inside LNET and our new LND without > replicating the code. > > I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well. > > Thoughts or suggestions? > > Nic > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-23 8:11 ` Robert Read @ 2009-02-23 21:39 ` Eric Barton 2009-02-23 22:50 ` di wang 0 siblings, 1 reply; 8+ messages in thread From: Eric Barton @ 2009-02-23 21:39 UTC (permalink / raw) To: lustre-devel 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... Cheers, Eric > -----Original Message----- > From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Robert Read > Sent: 23 February 2009 11:11 AM > To: Nic Henke > Cc: lustre-devel at lists.lustre.org > Subject: Re: [Lustre-devel] moving obd_fail_check to libcfs > > I don't think libcfs currently initializes any proc entries, so it's > not clear how you will set obd_fail_loc. In theory libcfs should just > thin library of porting primitives, and things like logging and > fail_check should be in a layer just above libcfs which could have a > management interface. So far we've just put some extra low-level > functionality into libcfs, but at some point it should be refactored. > I think when we need to add initialization code and an interface is > that point. > > robert > > > On Feb 22, 2009, at 8:15 PM, Nic Henke wrote: > > > Would there be any objection to a patch that'd move the current > > obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be > > able to use the same logic inside LNET and our new LND without > > replicating the code. > > > > I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well. > > > > Thoughts or suggestions? > > > > Nic > > _______________________________________________ > > Lustre-devel mailing list > > Lustre-devel at lists.lustre.org > > http://lists.lustre.org/mailman/listinfo/lustre-devel > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-23 21:39 ` Eric Barton @ 2009-02-23 22:50 ` di wang 2009-02-23 23:53 ` Nicholas Henke 0 siblings, 1 reply; 8+ messages in thread From: di wang @ 2009-02-23 22:50 UTC (permalink / raw) To: lustre-devel 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... > > 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. 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. Thanks WangDi > Cheers, > Eric > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-23 22:50 ` di wang @ 2009-02-23 23:53 ` Nicholas Henke 2009-02-24 1:04 ` di wang 0 siblings, 1 reply; 8+ messages in thread From: Nicholas Henke @ 2009-02-23 23:53 UTC (permalink / raw) To: lustre-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-23 23:53 ` Nicholas Henke @ 2009-02-24 1:04 ` di wang 0 siblings, 0 replies; 8+ messages in thread From: di wang @ 2009-02-24 1:04 UTC (permalink / raw) To: lustre-devel Hello, Nicholas Henke wrote: > > 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. It is in the b_hd_params, and you can also check bug 15384. Thanks WangDi >> 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-22 17:15 [Lustre-devel] moving obd_fail_check to libcfs Nic Henke 2009-02-23 8:11 ` Robert Read @ 2009-02-23 14:56 ` Eric Barton 2009-03-09 20:26 ` Nicholas Henke 2 siblings, 0 replies; 8+ messages in thread From: Eric Barton @ 2009-02-23 14:56 UTC (permalink / raw) To: lustre-devel Seems a fine thing to do - lets see the patch... Cheers, Eric > -----Original Message----- > From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Nic Henke > Sent: 22 February 2009 5:16 PM > To: lustre-devel at lists.lustre.org > Subject: [Lustre-devel] moving obd_fail_check to libcfs > > Would there be any objection to a patch that'd move the current > obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be > able to use the same logic inside LNET and our new LND without > replicating the code. > > I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well. > > Thoughts or suggestions? > > Nic > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Lustre-devel] moving obd_fail_check to libcfs 2009-02-22 17:15 [Lustre-devel] moving obd_fail_check to libcfs Nic Henke 2009-02-23 8:11 ` Robert Read 2009-02-23 14:56 ` Eric Barton @ 2009-03-09 20:26 ` Nicholas Henke 2 siblings, 0 replies; 8+ messages in thread From: Nicholas Henke @ 2009-03-09 20:26 UTC (permalink / raw) To: lustre-devel Nic Henke wrote: > Would there be any objection to a patch that'd move the current > obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be > able to use the same logic inside LNET and our new LND without > replicating the code. > > I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well. > > Thoughts or suggestions? > > Nic For those of you playing the at-home game, bug 18750 is filed for this. Nic ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-03-09 20:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-02-22 17:15 [Lustre-devel] moving obd_fail_check to libcfs Nic Henke 2009-02-23 8:11 ` Robert Read 2009-02-23 21:39 ` Eric Barton 2009-02-23 22:50 ` di wang 2009-02-23 23:53 ` Nicholas Henke 2009-02-24 1:04 ` di wang 2009-02-23 14:56 ` Eric Barton 2009-03-09 20:26 ` Nicholas Henke
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.