On Thu, Nov 9, 2017 at 1:06 PM, Dilger, Andreas <andreas.dilger@xxxxxxxxx> wrote: > On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister@xxxxxxxxx> wrote: >> >> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote: >>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote: >>>> There are two reasons for that: >>>> 1) As Linus Torvalds said we should use kernel types: >>>> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html >>>> >>>> 2) There are only few places in the lustre codebase that use such types. >>>> In the most cases it uses '__u32' and '__u64'. >>> >>>> drivers/staging/lustre/lustre/include/lustre_sec.h | 4 ++-- >>>> drivers/staging/lustre/lustre/llite/vvp_dev.c | 2 +- >>>> drivers/staging/lustre/lustre/lov/lov_internal.h | 12 ++++++------ >>>> drivers/staging/lustre/lustre/osc/osc_internal.h | 6 +++--- >>>> 4 files changed, 12 insertions(+), 12 deletions(-) >>> >>> The __ types are only needed for when you cross the user/kernel boundry. >>> Otherwise just use the "normal" types of u32 and u64. >>> >>> Do the changes you made here all cross that boundry? If not, please fix >>> this up. >> >> Thanks, Greg. >> >> I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right? > > Sorry for not getting back to you sooner, I was traveling. > > I'm not sure what you mean by the .h files aren't used in client code? > I checked all of the headers, and all of the structures that were changed, > and they all looked to be in use. Thanks, Andreas. But let me clarify: did you mean that those structures are being used in userspace code and this patch could be accepted? Or those structures are being used only in the kernel code and I should change it according to Greg's remark? Kind regards, Roman > > Cheers, Andreas > -- > Andreas Dilger > Lustre Principal Architect > Intel Corporation > > > > > > > -- Kind regards, Roman _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
