[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