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
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
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
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
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 > >
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
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 >
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? > > NicFor those of you playing the at-home game, bug 18750 is filed for this. Nic