02/12/2019 10:24, Morten Brørup: > Thomas, > > > -----Original Message----- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Monday, December 2, 2019 10:12 AM > > > > 02/12/2019 07:09, Gavin Hu (Arm Technology China): > > > Hi Bruce, Thomas, > > > > > > This series of patches was reported a compilation issue[1] on 32bit > > Ubuntu. > > > On mainstream 64-bit OS, "unsigned long" is 64-bit in size and we > > uses the 64-bit variant of APIs. But the 32-bit OS expect 32-bit > > 'unsigned long' arguments. > > > This is where the error happens. > > > > Please could you be more specific? What is the exact error? > > The PMD has a private structure with an unsigned long field. > > The patch for the PMD uses the 64 bit operations on this field. The patch > fails to compile for a 32 bit target, because the struct field is only 32 bit > there. > > > > > > My question is how 32-bit OSes shall we support, put another way, can > > we ignore this compilation issue? > > > If we still need to care, how about making 'obsolete' of 'unsigned > > long' and use 'uint32' instead to be multi-OS friendly? > > > > Which unsigned long? > > If it is in the (not merged) bit API, it can still be changed no? > > > > The patch for the PMD can be changed to use the 64 or 32 bit operations > depending on whether it is being compiled for a 64 or 32 bit target. > > However, the question seems to be if we want to either 1) do something like > that, or 2) drop support for 32 bit targets, or 3) make these target > dependent fields obsolete (i.e. ban the use of unsigned long) and require > explicit sizes, e.g. uint32_t.
We should support both, and use the appropriate instruction. But I wonder why this field has not a fixed size. It would be probably better to change the field to uint32_t or uint64_t.
