[lustre-devel] Using loff_t or u64 for PFL port

Patrick Farrell paf at cray.com
Tue Oct 30 07:55:25 PDT 2018


This would be good to clean up - A few subtle bugs related to loff_t/u64 usage in interfaces have come up over time (and been addressed each time), but I've never found time to try to clean it all up.

- Patrick

On 10/29/18, 10:18 AM, "lustre-devel on behalf of James Simmons" <lustre-devel-bounces at lists.lustre.org on behalf of jsimmons at infradead.org> wrote:

    
    > On Oct 28, 2018, at 21:49, James Simmons <jsimmons at infradead.org> wrote:
    > > 
    > > 
    > > While doing the PFL port I noticed a inconsistent use of loff_t and u64.
    > > While in Greg's branch several patches landed to make the prototypes
    > > match the function with changing any unmatching loff_t/u64 to use u64.
    > > I don't know if using u64 solely as the proper solution. What is the
    > > proper unit to use?
    > 
    > James, could you please clarify what part of the code you are referencing?
    
    I see where the divergence happened. The linux client commit 
    
    21aef7d9d6544 (staging/lustre: get rid of obd_* typedefs)
    
    Changed the old obd_off to u64 while in the OpenSFS branch some were
    changed to loff_t. A good example is 
    
    int lov_stripe_offset(struct lov_stripe_md *lsm, int index,
    		      loff_t lov_off, int stripeno, loff_t *obd_off);
    
    For upstream client its:
    
    int lov_stripe_offset(struct lov_stripe_md *lsm, u64 lov_off,
                          int stripeno, u64 *u64);
    
    The big difference between the two is that loff_t can be a negative
    value. I can compile a list of the difference so an audit cna be done.
    Then we can go over what should be loff_t and what should be u64.
    
    _______________________________________________
    lustre-devel mailing list
    lustre-devel at lists.lustre.org
    http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
    



More information about the lustre-devel mailing list