On Tue, Nov 10, 2015 at 10:01 PM, Arnd Bergmann arnd@arndb.de wrote:
On Tuesday 10 November 2015 19:27:49 Amitoj Kaur Chawla wrote:
After looking into this further the struct bfa_itnim_ioprofile_s *ioprofile data is being used in several structures in this way:
the structure "bfa_itnim_ioprofile_s" referenced by the structure "bfa_itnim_s" referenced by the structure "bfa_s" referenced by the structure "bfad_s" referenced by bfad_im_bsg_vendor_request() function
The bfad_im_bsg_vendor_request() function is called for the case FC_BSG_HST_VENDOR in bfad_bsg.c file
Correct. So this is a vendor specific command that can get sent from user space to retrieve the profile data. We can't change that format because we don't want to break existing applications using it, so this has to be documented carefully.
An easy way out would be to leave a cast to 'time_t' in the last place that references this, to leave it up to the next person who wants to clean up the driver. Then you only do the other parts that have an easier solution.
Just to ensure that I'm understanding correctly,
So this is what we have presently: struct bfa_itnim_ioprofile_s { ... u32 io_profile_start_time; /* IO profile start time */ ... };
and I make the following change:
struct bfa_itnim_ioprofile_s { ... time_t io_profile_start_time; /* IO profile start time */ ... };
You could also do the same thing as a an intermediate step, and do a final patch on top that removes the time_t and explains in the changelog what the impact of removing that is.
Arnd
The above change would become an intermediate change, and I send a separate(final) patch using time64_t? Also, explain in the changelog that this being used in a vendor specific command to retrieve profile data in both patches and will have an impact when the command is sent from user space?