* [lustre-devel] Using loff_t or u64 for PFL port @ 2018-10-29 3:49 James Simmons 2018-10-29 9:23 ` Andreas Dilger 0 siblings, 1 reply; 4+ messages in thread From: James Simmons @ 2018-10-29 3:49 UTC (permalink / raw) To: lustre-devel 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lustre-devel] Using loff_t or u64 for PFL port 2018-10-29 3:49 [lustre-devel] Using loff_t or u64 for PFL port James Simmons @ 2018-10-29 9:23 ` Andreas Dilger 2018-10-29 15:18 ` James Simmons 0 siblings, 1 reply; 4+ messages in thread From: Andreas Dilger @ 2018-10-29 9:23 UTC (permalink / raw) To: lustre-devel On Oct 28, 2018, at 21:49, James Simmons <jsimmons@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? Cheers, Andreas --- Andreas Dilger Principal Lustre Architect Whamcloud ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lustre-devel] Using loff_t or u64 for PFL port 2018-10-29 9:23 ` Andreas Dilger @ 2018-10-29 15:18 ` James Simmons 2018-10-30 14:55 ` Patrick Farrell 0 siblings, 1 reply; 4+ messages in thread From: James Simmons @ 2018-10-29 15:18 UTC (permalink / raw) To: lustre-devel > On Oct 28, 2018, at 21:49, James Simmons <jsimmons@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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lustre-devel] Using loff_t or u64 for PFL port 2018-10-29 15:18 ` James Simmons @ 2018-10-30 14:55 ` Patrick Farrell 0 siblings, 0 replies; 4+ messages in thread From: Patrick Farrell @ 2018-10-30 14:55 UTC (permalink / raw) To: lustre-devel 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@infradead.org> wrote: > On Oct 28, 2018, at 21:49, James Simmons <jsimmons@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-10-30 14:55 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-29 3:49 [lustre-devel] Using loff_t or u64 for PFL port James Simmons 2018-10-29 9:23 ` Andreas Dilger 2018-10-29 15:18 ` James Simmons 2018-10-30 14:55 ` Patrick Farrell
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.