| Message ID | af1856e7606e948308919d0e66dcae3766318c6c.1653295437.git.lin.liu@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Implement byteswap and update references | expand |
On 23.05.2022 11:52, Lin Liu wrote: > --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c > +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c > @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) > return cpu_to_le32(*p); > } > > +static inline u32 le32_to_cpu(u32 val) > +{ > + return le32_to_cpup((const u32 *)&val); > +} Why the cast? And why not uint32_t? Jan
On 23.05.2022 11:52, Lin Liu wrote: >> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >> return cpu_to_le32(*p); >> } >> >> +static inline u32 le32_to_cpu(u32 val) >> +{ >> + return le32_to_cpup((const u32 *)&val); >> +} > >Why the cast? And why not uint32_t? > >Jan le32_to_cpup has following prototye and definition static inline u32 le32_to_cpup(const u32 *p) { return cpu_to_le32(*p); } xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent typedef uint32_t u32;
On 24.05.2022 04:13, Lin Liu （刘林） wrote: > On 23.05.2022 11:52, Lin Liu wrote: >>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >>> return cpu_to_le32(*p); >>> } >>> >>> +static inline u32 le32_to_cpu(u32 val) >>> +{ >>> + return le32_to_cpup((const u32 *)&val); >>> +} >> >> Why the cast? And why not uint32_t? >> >> Jan > > le32_to_cpup has following prototye and definition > > static inline u32 le32_to_cpup(const u32 *p) > { > return cpu_to_le32(*p); > } > > xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent > typedef uint32_t u32; This answers neither part of my question. For u32 vs uint32_t, please also see ./CODING_STYLE. Jan
>> On 23.05.2022 11:52, Lin Liu wrote: >>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >>>> return cpu_to_le32(*p); >>>> } >>>> >>>> +static inline u32 le32_to_cpu(u32 val) >>>> +{ >>>> + return le32_to_cpup((const u32 *)&val); >>>> +} >>> >>> Why the cast? And why not uint32_t? >>> >>> Jan >> >> le32_to_cpup has following prototye and definition >> >> static inline u32 le32_to_cpup(const u32 *p) >> { >> return cpu_to_le32(*p); >> } >> >> xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent >> typedef uint32_t u32; > >This answers neither part of my question. For u32 vs uint32_t, please >also see ./CODING_STYLE. Type cast is unnecessary, will be removed in next version of patch CODING_STYLE encourage uint32_t instead of u32, However, Current xg_dom_decompress_unsafe_xz.c already use u32 instead of unit32_t, so I use u32 to keep censistent, otherwise, the code look strange
On 24.05.2022 08:52, Lin Liu （刘林） wrote: >>> On 23.05.2022 11:52, Lin Liu wrote: >>>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >>>>> return cpu_to_le32(*p); >>>>> } >>>>> >>>>> +static inline u32 le32_to_cpu(u32 val) >>>>> +{ >>>>> + return le32_to_cpup((const u32 *)&val); >>>>> +} >>>> >>>> Why the cast? And why not uint32_t? >>>> >>>> Jan >>> >>> le32_to_cpup has following prototye and definition >>> >>> static inline u32 le32_to_cpup(const u32 *p) >>> { >>> return cpu_to_le32(*p); >>> } >>> >>> xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent >>> typedef uint32_t u32; >> >> This answers neither part of my question. For u32 vs uint32_t, please >> also see ./CODING_STYLE. > > Type cast is unnecessary, will be removed in next version of patch > CODING_STYLE encourage uint32_t instead of u32, > However, Current xg_dom_decompress_unsafe_xz.c already use u32 instead of unit32_t, so I > use u32 to keep censistent, otherwise, the code look strange Strange or not, that's the only way to phase out certain things without using gigantic patches / series touching the entire tree at one time. New code should not use these deprecated (for our purposes) types anymore. Note how the file you adjust here already has to introduce these type aliases for things to build. These typedefs really want to go away, and any new use of those types is another hindrance in doing so. Jan
>>>> On 23.05.2022 11:52, Lin Liu wrote: >>>>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >>>>>> return cpu_to_le32(*p); >>>>>> } >>>>>> >>>>>> +static inline u32 le32_to_cpu(u32 val) >>>>>> +{ >>>>>> + return le32_to_cpup((const u32 *)&val); >>>>>> +} >>>>> >>>>> Why the cast? And why not uint32_t? >>>>> >>>>> Jan >>>> >>>> le32_to_cpup has following prototye and definition >>>> >>>> static inline u32 le32_to_cpup(const u32 *p) >>>> { >>>> return cpu_to_le32(*p); >>>> } >>>> >>>> xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent >>>> typedef uint32_t u32; >>> >>> This answers neither part of my question. For u32 vs uint32_t, please >>> also see ./CODING_STYLE. >> >> Type cast is unnecessary, will be removed in next version of patch >> CODING_STYLE encourage uint32_t instead of u32, >> However, Current xg_dom_decompress_unsafe_xz.c already use u32 instead of unit32_t, so I >> use u32 to keep censistent, otherwise, the code look strange > >Strange or not, that's the only way to phase out certain things without >using gigantic patches / series touching the entire tree at one time. >New code should not use these deprecated (for our purposes) types >anymore. Note how the file you adjust here already has to introduce >these type aliases for things to build. These typedefs really want to >go away, and any new use of those types is another hindrance in doing well, you convinced me to use uint32_t instead of u32. However, This patch will not update other u32(s) to get focus. I can raise another patch to update parts if necessary. Cheers, Lin
On 24.05.2022 09:17, Lin Liu （刘林） wrote: >>>>> On 23.05.2022 11:52, Lin Liu wrote: >>>>>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c >>>>>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) >>>>>>> return cpu_to_le32(*p); >>>>>>> } >>>>>>> >>>>>>> +static inline u32 le32_to_cpu(u32 val) >>>>>>> +{ >>>>>>> + return le32_to_cpup((const u32 *)&val); >>>>>>> +} >>>>>> >>>>>> Why the cast? And why not uint32_t? >>>>>> >>>>>> Jan >>>>> >>>>> le32_to_cpup has following prototye and definition >>>>> >>>>> static inline u32 le32_to_cpup(const u32 *p) >>>>> { >>>>> return cpu_to_le32(*p); >>>>> } >>>>> >>>>> xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep consistent >>>>> typedef uint32_t u32; >>>> >>>> This answers neither part of my question. For u32 vs uint32_t, please >>>> also see ./CODING_STYLE. >>> >>> Type cast is unnecessary, will be removed in next version of patch >>> CODING_STYLE encourage uint32_t instead of u32, >>> However, Current xg_dom_decompress_unsafe_xz.c already use u32 instead of unit32_t, so I >>> use u32 to keep censistent, otherwise, the code look strange >> >> Strange or not, that's the only way to phase out certain things without >> using gigantic patches / series touching the entire tree at one time. >> New code should not use these deprecated (for our purposes) types >> anymore. Note how the file you adjust here already has to introduce >> these type aliases for things to build. These typedefs really want to >> go away, and any new use of those types is another hindrance in doing > > well, you convinced me to use uint32_t instead of u32. > However, This patch will not update other u32(s) to get focus. Of course, that's fine. > I can raise another patch to update parts if necessary. FTAOD: This would certainly be appreciated, but is by no means a requirement here. Jan
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c index fc48198741..493427d517 100644 --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p) return cpu_to_le32(*p); } +static inline u32 le32_to_cpu(u32 val) +{ + return le32_to_cpup((const u32 *)&val); +} + #define __force #define always_inline diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c index 01eafaaaa6..b06f2e767f 100644 --- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c +++ b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c @@ -31,7 +31,8 @@ typedef uint64_t __be64; #define __BYTEORDER_HAS_U64__ #define __TYPES_H__ /* xen/types.h guard */ -#include "../../xen/include/xen/byteorder/little_endian.h" +#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ +#include "../../xen/include/xen/byteorder.h" #define __ASM_UNALIGNED_H__ /* asm/unaligned.h guard */ #include "../../xen/include/xen/unaligned.h" #include "../../xen/include/xen/xxhash.h"
Include new header to use new byteswap helper No functional change. Signed-off-by: Lin Liu <lin.liu@citrix.com> --- Cc: Wei Liu <wl@xen.org> Cc: Anthony PERARD <anthony.perard@citrix.com> Cc: Juergen Gross <jgross@suse.com> --- tools/libs/guest/xg_dom_decompress_unsafe_xz.c | 5 +++++ tools/libs/guest/xg_dom_decompress_unsafe_zstd.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-)