On Sat, Jan 22, 2005 at 10:05:16PM -0500, D. Hugh Redelmeier wrote: > [Sorry that this isn't a proper reply. I just this minute subscribed > and am replying to an archived message.] > > Axel.Thimm wrote: > > | The current "u32 then" only interacts with jiffies which already is > | (unconditionally) a u64. Is this a 64bits issue at all? > | > | I wonder why the build gives no warnings when assigning a u64 value to > | a u32. > > I'm not a kernel programmer, but I am reading Robert Love's book "Linux > Kernel Development". In that, he explains the somewhat convoluted > "jiffies" variable. > > It seems that the "jiffies" variable is always of type "unsigned > long". There is a separate variable "jiffies_64" that is always 64 > bits (but it requires locking to access since access may not be atomic > and isn't declared as volatile) (access to "unigned long" is not > guaranteed to be atomic by the C standards, but maybe LINUX assumes > this). > > Apparently, through linker magic, "jiffies" is an alias for the > low-order part or whole of jiffies_64. YUCK! > > Have a look in <linux/jiffies.h> in 2.6 (I don't know about 2.4): > /* > * The 64-bit value is not volatile - you MUST NOT read it > * without sampling the sequence number in xtime_lock. > * get_jiffies_64() will do this for you as appropriate. > */ > extern u64 jiffies_64; > extern unsigned long volatile jiffies; > > > So: I suspect that a number of the "then" variables should be declared > "unsigned long", not "u32" and not "u64". Besides being correct, this > is also portable. Since I've only read the diff, I cannot be sure of > the uses of "this".
Then probably also the jiffies as used in the api_cmd struct are to be converted to unsigned long. Currently the variable `then' is u32, and the struct member is u64. It should create warning during the build on both 32bit and 64bit platforms. But I may still be missing something. -- Axel.Thimm at ATrpms.net
pgpOMtCdiVIRM.pgp
Description: PGP signature
