* Re: radeon warning on 64-bit platforms [not found] ` <1077058106.2713.88.camel@thor.asgaard.local> @ 2004-02-17 23:28 ` David Mosberger 2004-02-17 23:44 ` Michel Dänzer ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: David Mosberger @ 2004-02-17 23:28 UTC (permalink / raw) To: torvalds, Michel Dänzer; +Cc: davidm, linux-kernel, linux-ia64 Linus and Michel, Here is a proposed patch for fixing the compile-warning that shows up when compiling radeon_state.c on a 64-bit platform (Itanium, in my case). According to Michel, RADEON_PARAM_SAREA_HANDLE is used only on embedded platforms and since it is not possible to fix the problem without breaking backwards-compatibility for those platforms, the interim fix is to simply desupport this particular ioctl() on 64-bit platforms (i.e., make it fail with EINVAL). If there are no objections, please apply. --david === drivers/char/drm/radeon_state.c 1.23 vs edited ==--- 1.23/drivers/char/drm/radeon_state.c Tue Feb 3 21:29:26 2004 +++ edited/drivers/char/drm/radeon_state.c Tue Feb 17 15:23:01 2004 @@ -2186,9 +2186,24 @@ value = dev_priv->ring_rptr_offset; break; case RADEON_PARAM_SAREA_HANDLE: - /* The lock is the first dword in the sarea. */ - value = (int)dev->lock.hw_lock; - break; + /* + * This ioctl() doesn't work on 64-bit platforms because hw_lock is a + * pointer which can't fit into an int-sized variable. According to + * Michael Dänzer, the ioctl() is only used on embedded platforms, so not + * supporting it shouldn't be a problem. If the same functionality is + * needed on 64-bit platforms, a new ioctl() would have to be added, so + * backwards-compatibility for the embedded platforms can be maintained. + * --davidm 4-Feb-2004. + */ + if (sizeof (dev->lock.hw_lock) <= sizeof (int)) + /* + * The lock is the first dword in the sarea. Cast to "long" so it + * compiles without warning on 64-bit platforms. + */ + value = (long)dev->lock.hw_lock; + else + return DRM_ERR(EINVAL); + break; case RADEON_PARAM_GART_TEX_HANDLE: value = dev_priv->gart_textures_offset; break; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-17 23:28 ` radeon warning on 64-bit platforms David Mosberger @ 2004-02-17 23:44 ` Michel Dänzer 2004-02-17 23:48 ` Anton Blanchard 2004-02-17 23:53 ` Linus Torvalds 2 siblings, 0 replies; 12+ messages in thread From: Michel Dänzer @ 2004-02-17 23:44 UTC (permalink / raw) To: davidm; +Cc: torvalds, linux-kernel, linux-ia64 David, looks good to me, except for a detail: > + * Michael Dänzer, the ioctl() is only used on embedded platforms, so not ^^^^^^^ That's not quite my first name. :) I'd appreciate a heads up when this (or whatever becomes of it) goes in so I can apply it to DRI CVS as well. On the other hand, I'll probably see it at the latest when Ben merges it into his tree. :) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?rÚenzer ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-17 23:28 ` radeon warning on 64-bit platforms David Mosberger 2004-02-17 23:44 ` Michel Dänzer @ 2004-02-17 23:48 ` Anton Blanchard 2004-02-18 0:51 ` David Mosberger 2004-02-17 23:53 ` Linus Torvalds 2 siblings, 1 reply; 12+ messages in thread From: Anton Blanchard @ 2004-02-17 23:48 UTC (permalink / raw) To: davidm; +Cc: torvalds, Michel D?nzer, linux-kernel, linux-ia64 > Here is a proposed patch for fixing the compile-warning that shows up > when compiling radeon_state.c on a 64-bit platform (Itanium, in my > case). According to Michel, RADEON_PARAM_SAREA_HANDLE is used only on > embedded platforms and since it is not possible to fix the problem > without breaking backwards-compatibility for those platforms, the > interim fix is to simply desupport this particular ioctl() on 64-bit > platforms (i.e., make it fail with EINVAL). > > If there are no objections, please apply. A small thing, could the comment be constrained to 80 columns? :) Anton ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-17 23:48 ` Anton Blanchard @ 2004-02-18 0:51 ` David Mosberger 2004-02-18 1:54 ` Matthew Wilcox 0 siblings, 1 reply; 12+ messages in thread From: David Mosberger @ 2004-02-18 0:51 UTC (permalink / raw) To: torvalds, Michel D?nzer, Anton Blanchard; +Cc: davidm, linux-kernel, linux-ia64 >>>>> On Wed, 18 Feb 2004 10:48:49 +1100, Anton Blanchard <anton@samba.org> said: Anton> A small thing, could the comment be constrained to 80 Anton> columns? :) I don't really see the point of that, given that pretty much all existing Linux source code is formatted for 100 columns. I don't feel strongly about it, however, so I changed it. >>>>> On Tue, 17 Feb 2004 15:53:05 -0800 (PST), Linus Torvalds <torvalds@osdl.org> said: Linus> How about this alternate edited one that gets indentation Linus> right and is more explicit about what's going on? Does this Linus> work for you? Fine by me. >>>>> On Wed, 18 Feb 2004 00:44:16 +0100, Michel Dänzer <michel@daenzer.net> said: Michel> looks good to me, except for a detail: >> + * Michael Dänzer, the ioctl() is only used on embedded >> platforms, so not Michel> ^^^^^^^ That's not quite my first name. :) Sorry about that, fixed below (or so I hope). --david === drivers/char/drm/radeon_state.c 1.23 vs edited ==--- 1.23/drivers/char/drm/radeon_state.c Tue Feb 3 21:29:26 2004 +++ edited/drivers/char/drm/radeon_state.c Tue Feb 17 16:49:15 2004 @@ -2185,10 +2185,21 @@ case RADEON_PARAM_STATUS_HANDLE: value = dev_priv->ring_rptr_offset; break; +#if BITS_PER_LONG = 32 + /* + * This ioctl() doesn't work on 64-bit platforms because hw_lock is a + * pointer which can't fit into an int-sized variable. According to + * Michel Dänzer, the ioctl() is only used on embedded platforms, so + * not supporting it shouldn't be a problem. If the same functionality + * is needed on 64-bit platforms, a new ioctl() would have to be added, + * so backwards-compatibility for the embedded platforms can be + * maintained. --davidm 4-Feb-2004. + */ case RADEON_PARAM_SAREA_HANDLE: /* The lock is the first dword in the sarea. */ - value = (int)dev->lock.hw_lock; - break; + value = (long)dev->lock.hw_lock; + break; +#endif case RADEON_PARAM_GART_TEX_HANDLE: value = dev_priv->gart_textures_offset; break; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-18 0:51 ` David Mosberger @ 2004-02-18 1:54 ` Matthew Wilcox 2004-02-18 1:59 ` David Mosberger 0 siblings, 1 reply; 12+ messages in thread From: Matthew Wilcox @ 2004-02-18 1:54 UTC (permalink / raw) To: davidm; +Cc: torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 On Tue, Feb 17, 2004 at 04:51:24PM -0800, David Mosberger wrote: > >>>>> On Wed, 18 Feb 2004 10:48:49 +1100, Anton Blanchard <anton@samba.org> said: > > Anton> A small thing, could the comment be constrained to 80 > Anton> columns? :) > > I don't really see the point of that, given that pretty much all > existing Linux source code is formatted for 100 columns. I don't feel > strongly about it, however, so I changed it. Um, only your crap. Everybody else follows Documentation/CodingStyle. This is mentioned in a couple of places: Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. ... Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well. I wish the ia64 code weren't indented to 100 columns. It's why I hate working with your code. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-18 1:54 ` Matthew Wilcox @ 2004-02-18 1:59 ` David Mosberger 2004-02-18 2:28 ` Matthew Wilcox 0 siblings, 1 reply; 12+ messages in thread From: David Mosberger @ 2004-02-18 1:59 UTC (permalink / raw) To: Matthew Wilcox Cc: davidm, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 >>>>> On Wed, 18 Feb 2004 01:54:23 +0000, Matthew Wilcox <willy@debian.org> said: >> I don't really see the point of that, given that pretty much all >> existing Linux source code is formatted for 100 columns. I don't feel >> strongly about it, however, so I changed it. Matthew> Um, only your crap. Everybody else follows Matthew> Documentation/CodingStyle. Wow. Revisionists at work? ;-) I personally would be more than happy to reformat things to 80 cols, but it's a waste of time unless almost all Linux code gets reformatted. --david ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-18 1:59 ` David Mosberger @ 2004-02-18 2:28 ` Matthew Wilcox 2004-02-18 4:48 ` David Mosberger 2004-02-19 22:30 ` Valdis.Kletnieks 0 siblings, 2 replies; 12+ messages in thread From: Matthew Wilcox @ 2004-02-18 2:28 UTC (permalink / raw) To: davidm Cc: Matthew Wilcox, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 On Tue, Feb 17, 2004 at 05:59:12PM -0800, David Mosberger wrote: > I personally would be more than happy to reformat things to 80 cols, > but it's a waste of time unless almost all Linux code gets > reformatted. Hm? I don't know where you're getting that from. Let's talk numbers. Of the 60525 lines in .c files in arch/i386, 460 are longer than 80 cols. Of the 67398 lines in .c files in arch/ia64, 1189 are longer than 80 cols. Of the 496510 lines in .c files in drivers/net, 4044 are longer than 80 cols. So arch/i386 has 0.76% > 80 column lines, drivers/net is 0.81% and arch/ia64 is 1.76%. Seems fairly convincing to me that ia64 is out of step with the rest of Linux. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-18 2:28 ` Matthew Wilcox @ 2004-02-18 4:48 ` David Mosberger 2004-02-19 22:30 ` Valdis.Kletnieks 1 sibling, 0 replies; 12+ messages in thread From: David Mosberger @ 2004-02-18 4:48 UTC (permalink / raw) To: Matthew Wilcox Cc: davidm, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 >>>>> On Wed, 18 Feb 2004 02:28:31 +0000, Matthew Wilcox <willy@debian.org> said: Matthew> On Tue, Feb 17, 2004 at 05:59:12PM -0800, David Mosberger Matthew> wrote: >> I personally would be more than happy to reformat things to 80 >> cols, but it's a waste of time unless almost all Linux code gets >> reformatted. Matthew> Hm? I don't know where you're getting that from. Let's Matthew> talk numbers. If it bothers you, you're perfectly free to submit patches. Source-code width is not something I get overly excited about. --david ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-18 2:28 ` Matthew Wilcox 2004-02-18 4:48 ` David Mosberger @ 2004-02-19 22:30 ` Valdis.Kletnieks 2004-02-20 15:51 ` Andreas Schwab 1 sibling, 1 reply; 12+ messages in thread From: Valdis.Kletnieks @ 2004-02-19 22:30 UTC (permalink / raw) To: Matthew Wilcox Cc: davidm, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 [-- Attachment #1: Type: text/plain, Size: 1467 bytes --] On Wed, 18 Feb 2004 02:28:31 GMT, Matthew Wilcox said: > On Tue, Feb 17, 2004 at 05:59:12PM -0800, David Mosberger wrote: > > I personally would be more than happy to reformat things to 80 cols, > > but it's a waste of time unless almost all Linux code gets > > reformatted. > > Hm? I don't know where you're getting that from. Let's talk numbers. > > Of the 60525 lines in .c files in arch/i386, 460 are longer than 80 cols. > Of the 67398 lines in .c files in arch/ia64, 1189 are longer than 80 cols. > Of the 496510 lines in .c files in drivers/net, 4044 are longer than 80 cols. You apparently made the mistake of looking at character count < 80, not lines that extend past column 80. For 2.6.3-mm1, I see: [/usr/src/linux-2.6.3-mm1/arch/i386]2 find . -name '*.c' | xargs cat | wc -l 64542 [/usr/src/linux-2.6.3-mm1/arch/i386]2 find . -name '*.c' | xargs cat | awk 'length() > 80 { print $0}' | wc -l 477 [/usr/src/linux-2.6.3-mm1/arch/i386]2 find . -name '*.c' | xargs cat |sed 's/\t/ /g'| awk 'length() > 80 { print $0}' | wc -l 1291 (replace \t with whatever your shell needs to enter a literal tab . Yes, this botches on the relatively rare line that has an embedded tab. Deal with it. ;). In other words, the situation is a lot worse if you count columns, not characters. (For IA64, it's 67,376 and either 1,185 or 3,222, and for drivers/net I see 493,027 and either 4,004 or 15,606 - ia64 is worse at the 80-col thing either way) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-19 22:30 ` Valdis.Kletnieks @ 2004-02-20 15:51 ` Andreas Schwab 2004-02-20 22:14 ` Valdis.Kletnieks 0 siblings, 1 reply; 12+ messages in thread From: Andreas Schwab @ 2004-02-20 15:51 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Matthew Wilcox, davidm, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 Valdis.Kletnieks@vt.edu writes: > [/usr/src/linux-2.6.3-mm1/arch/i386]2 find . -name '*.c' | xargs cat |sed 's/\t/ /g'| awk 'length() > 80 { print $0}' | wc -l > 1291 > > (replace \t with whatever your shell needs to enter a literal tab . Yes, this > botches on the relatively rare line that has an embedded tab. Deal with it. ;). Use expand. $ find . -name '*.c' | xargs cat | expand | awk 'length() > 80 { print $0}' | wc -l 1125 Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-20 15:51 ` Andreas Schwab @ 2004-02-20 22:14 ` Valdis.Kletnieks 0 siblings, 0 replies; 12+ messages in thread From: Valdis.Kletnieks @ 2004-02-20 22:14 UTC (permalink / raw) To: Andreas Schwab Cc: Matthew Wilcox, davidm, torvalds, Michel D?nzer, Anton Blanchard, linux-kernel, linux-ia64 [-- Attachment #1: Type: text/plain, Size: 232 bytes --] On Fri, 20 Feb 2004 16:51:00 +0100, Andreas Schwab said: > Use expand. Learn something new every day. Usually, the task at hand is the inverse task - fixing a file that has leading blanks to have leading tabs instead. ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: radeon warning on 64-bit platforms 2004-02-17 23:28 ` radeon warning on 64-bit platforms David Mosberger 2004-02-17 23:44 ` Michel Dänzer 2004-02-17 23:48 ` Anton Blanchard @ 2004-02-17 23:53 ` Linus Torvalds 2 siblings, 0 replies; 12+ messages in thread From: Linus Torvalds @ 2004-02-17 23:53 UTC (permalink / raw) To: davidm; +Cc: Michel Dänzer, linux-kernel, linux-ia64 On Tue, 17 Feb 2004, David Mosberger wrote: > > Here is a proposed patch for fixing the compile-warning that shows up > when compiling radeon_state.c on a 64-bit platform (Itanium, in my > case). How about this alternate edited one that gets indentation right and is more explicit about what's going on? Does this work for you? Linus --- === drivers/char/drm/radeon_state.c 1.23 vs edited ==--- 1.23/drivers/char/drm/radeon_state.c Tue Feb 3 21:29:26 2004 +++ edited/drivers/char/drm/radeon_state.c Tue Feb 17 15:51:53 2004 @@ -2185,10 +2185,21 @@ case RADEON_PARAM_STATUS_HANDLE: value = dev_priv->ring_rptr_offset; break; +#if BITS_PER_LONG = 32 + /* + * This ioctl() doesn't work on 64-bit platforms because hw_lock is a + * pointer which can't fit into an int-sized variable. According to + * Michel Dänzer, the ioctl() is only used on embedded platforms, so not + * supporting it shouldn't be a problem. If the same functionality is + * needed on 64-bit platforms, a new ioctl() would have to be added, so + * backwards-compatibility for the embedded platforms can be maintained. + * --davidm 4-Feb-2004. + */ case RADEON_PARAM_SAREA_HANDLE: /* The lock is the first dword in the sarea. */ value = (int)dev->lock.hw_lock; break; +#endif case RADEON_PARAM_GART_TEX_HANDLE: value = dev_priv->gart_textures_offset; break; ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-02-20 22:14 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <16434.35199.597235.894615@napali.hpl.hp.com>
[not found] ` <1077054385.2714.72.camel@thor.asgaard.local>
[not found] ` <16434.36137.623311.751484@napali.hpl.hp.com>
[not found] ` <1077055209.2712.80.camel@thor.asgaard.local>
[not found] ` <16434.37025.840577.826949@napali.hpl.hp.com>
[not found] ` <1077058106.2713.88.camel@thor.asgaard.local>
2004-02-17 23:28 ` radeon warning on 64-bit platforms David Mosberger
2004-02-17 23:44 ` Michel Dänzer
2004-02-17 23:48 ` Anton Blanchard
2004-02-18 0:51 ` David Mosberger
2004-02-18 1:54 ` Matthew Wilcox
2004-02-18 1:59 ` David Mosberger
2004-02-18 2:28 ` Matthew Wilcox
2004-02-18 4:48 ` David Mosberger
2004-02-19 22:30 ` Valdis.Kletnieks
2004-02-20 15:51 ` Andreas Schwab
2004-02-20 22:14 ` Valdis.Kletnieks
2004-02-17 23:53 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox