[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". ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
