Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-25 Thread Mikko Rapeli
On Thu, Aug 25, 2016 at 04:24:11AM +, Bart Van Assche wrote: > On 08/23/16 13:42, Mikko Rapeli wrote: > > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: > >> On 08/23/16 06:57, Bart Van Assche wrote: > >>> On 08/22/16 11:32, Mikko Rapeli wrote: > - * uint32_t

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-25 Thread Mikko Rapeli
On Thu, Aug 25, 2016 at 04:24:11AM +, Bart Van Assche wrote: > On 08/23/16 13:42, Mikko Rapeli wrote: > > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: > >> On 08/23/16 06:57, Bart Van Assche wrote: > >>> On 08/22/16 11:32, Mikko Rapeli wrote: > - * uint32_t

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-24 Thread Bart Van Assche
On 08/23/16 13:42, Mikko Rapeli wrote: > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: >> On 08/23/16 06:57, Bart Van Assche wrote: >>> On 08/22/16 11:32, Mikko Rapeli wrote: - * uint32_t (*get_region_size)(struct dm_dirty_log *log); + * __u32 (*get_region_size)(struct

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-24 Thread Bart Van Assche
On 08/23/16 13:42, Mikko Rapeli wrote: > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: >> On 08/23/16 06:57, Bart Van Assche wrote: >>> On 08/22/16 11:32, Mikko Rapeli wrote: - * uint32_t (*get_region_size)(struct dm_dirty_log *log); + * __u32 (*get_region_size)(struct

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Mikko Rapeli
On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: > On 08/23/16 06:57, Bart Van Assche wrote: > > On 08/22/16 11:32, Mikko Rapeli wrote: > >> - * uint32_t (*get_region_size)(struct dm_dirty_log *log); > >> + * __u32 (*get_region_size)(struct dm_dirty_log *log); > > > > uint32_t is a

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Mikko Rapeli
On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: > On 08/23/16 06:57, Bart Van Assche wrote: > > On 08/22/16 11:32, Mikko Rapeli wrote: > >> - * uint32_t (*get_region_size)(struct dm_dirty_log *log); > >> + * __u32 (*get_region_size)(struct dm_dirty_log *log); > > > > uint32_t is a

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Bart Van Assche
On 08/23/16 06:57, Bart Van Assche wrote: > On 08/22/16 11:32, Mikko Rapeli wrote: >> - * uint32_t (*get_region_size)(struct dm_dirty_log *log); >> + * __u32 (*get_region_size)(struct dm_dirty_log *log); > > uint32_t is a type that is defined by ANSI C but __u32 not. So this > change looks wrong

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Bart Van Assche
On 08/23/16 06:57, Bart Van Assche wrote: > On 08/22/16 11:32, Mikko Rapeli wrote: >> - * uint32_t (*get_region_size)(struct dm_dirty_log *log); >> + * __u32 (*get_region_size)(struct dm_dirty_log *log); > > uint32_t is a type that is defined by ANSI C but __u32 not. So this > change looks wrong

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Bart Van Assche
On 08/22/16 11:32, Mikko Rapeli wrote: > - * uint32_t (*get_region_size)(struct dm_dirty_log *log); > + * __u32 (*get_region_size)(struct dm_dirty_log *log); uint32_t is a type that is defined by ANSI C but __u32 not. So this change looks wrong to me. Would it have been sufficient to add

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

2016-08-23 Thread Bart Van Assche
On 08/22/16 11:32, Mikko Rapeli wrote: > - * uint32_t (*get_region_size)(struct dm_dirty_log *log); > + * __u32 (*get_region_size)(struct dm_dirty_log *log); uint32_t is a type that is defined by ANSI C but __u32 not. So this change looks wrong to me. Would it have been sufficient to add