Re: CVS commit: src/sys/dev/pci
On 24.12.10 00:56, Michael wrote: Hello, On Dec 23, 2010, at 4:34 PM, Christoph Egger wrote: Module Name:src Committed By:cegger Date:Thu Dec 23 21:34:02 UTC 2010 Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Christoph
Re: CVS commit: src/sys/dev/pci
Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Adding a bogus fix to make ALL buildable is quite silly. bus_space_read_8(9) is a documented MI API and MD implementation should provide bus_space_read_8() if the machine really needs the driver in its kernel, or don't enable the device on i386. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/pci
On 24.12.10 11:07, Izumi Tsutsui wrote: Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Adding a bogus fix to make ALL buildable is quite silly. bus_space_read_8(9) is a documented MI API and MD implementation should provide bus_space_read_8() if the machine really needs the driver in its kernel, or don't enable the device on i386. The 'reg' variable is of type 'uint32_t'. So why using bus_space_read_8() when bus_space_read_4() gives the same result? Christoph
Re: CVS commit: src/sys/dev/pci
The 'reg' variable is of type 'uint32_t'. So why using bus_space_read_8() when bus_space_read_4() gives the same result? Did you confirm if it really gave the same result? Some bus/device might require certain access size on I/O. I don't know if the device have such restriction, but making ALL buildable can't be an excuse for changes without tests in this case. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/pci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Dec 24, 2010, at 4:13 AM, Christoph Egger wrote: On 24.12.10 00:56, Michael wrote: Hello, On Dec 23, 2010, at 4:34 PM, Christoph Egger wrote: Module Name:src Committed By:cegger Date:Thu Dec 23 21:34:02 UTC 2010 Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Are you trying to tell me that i386 doesn't have bus_space_*_8() methods? I'd call that a bug. The 64bit access in voyagerfb was most likely a typo on my side but there is hardware which has registers that must be accessed in 64bit quantities and voyagerfb was written for a machine with a 64bit CPU - you can't blindly assume that 64bit accesses can be split up. That said, I very much doubt that there is a lot of x86 hardware out there which uses Silicon Motion SM50x chips, so adding that driver to anything in i386 makes little sense. For starters, it doesn't bother with VGA compatibility. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTRSb8MpnzkX8Yg2nAQIbqgf/T5O9a6abvO2Be6MUMxki2DXkpFIEmaVD Uc7JZf/xlog63rbaqlo/7rNT8+wxYNWZ8Cx5sFtdNdzqD6cNwkN6ByS/Ufk7EYJA PQVFk7uWtdImQV7g2rV8RCwe5Irpxk/AUExpAxlk1FcWIeVR/BE/enDJfU5yUSLl mXp3SQ3nnTJRm0o3lglRCxgsN7gm7nCgJvR5q1INKlOiboodW+9K1/hYWh/D2k29 VTc8slGjTmXxfWEkydFgW3MqylwBr8TlRe6cr1u2cjM/2zFwIrBdajH9OSGug2Oq 8cp7ZzKmPjqwK6o2BUa3EyI3C8JEokjtXZ8Bv2wdS/Xvx9FU2l8i4g== =BZHp -END PGP SIGNATURE-
Re: CVS commit: src/sys/arch/i386/stand
On Wed, Dec 22, 2010 at 08:46:43PM +, Jonathan A. Kollasch wrote: Log Message: It just so happens we don't need -Wno-attributes if we place __packed in the right place. Does that need __packed (which would force unaligned access code) be added for all accesses, or just __attribute__((aligned(n))) for some fields? This doesn't make much difference on i386, but will on archs that don't support misaligned accesses. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl2/lvm2
In article fefc4453-cdc4-4771-b16f-7f31c8555...@gmail.com, Adam Hamsik haa...@gmail.com wrote: Index: src/external/gpl2/lvm2/dist/daemons/cmirrord/functions.c This file is not even build please revert your change. Index: src/external/gpl2/lvm2/dist/libdm/ioctl/libdm-iface.c This is original linux file which is not build, please revert your change. I think that the fixes are correct though, so I would prefer to ask upstream to take them. PR is about block devices not about char control devices this part changes /dev/mapper/control do we really want to have 640 there if yes I'm fine with it I just want to be sure that you wanted to do that. Yes that was problematic, and we needed to add permission checks in the kernel portion. What's nice about it is that perhaps this will allow an operator to query the state of the volumes now. Most of this was hashed out privately. christos
Re: CVS commit: src/external/gpl2/lvm2
On Dec,Friday 24 2010, at 4:50 PM, Christos Zoulas wrote: In article fefc4453-cdc4-4771-b16f-7f31c8555...@gmail.com, Adam Hamsik haa...@gmail.com wrote: Index: src/external/gpl2/lvm2/dist/daemons/cmirrord/functions.c This file is not even build please revert your change. Index: src/external/gpl2/lvm2/dist/libdm/ioctl/libdm-iface.c This is original linux file which is not build, please revert your change. I think that the fixes are correct though, so I would prefer to ask upstream to take them. Then can you please request to import these changes to upstream repository ? PR is about block devices not about char control devices this part changes /dev/mapper/control do we really want to have 640 there if yes I'm fine with it I just want to be sure that you wanted to do that. Yes that was problematic, and we needed to add permission checks in the kernel portion. What's nice about it is that perhaps this will allow an operator to query the state of the volumes now. Most of this was hashed out privately. Yeah thanks. Regards Adam.
Re: CVS commit: src/sys/dev/pci
On 24.12.10 14:11, Michael wrote: Hello, On Dec 24, 2010, at 4:13 AM, Christoph Egger wrote: On 24.12.10 00:56, Michael wrote: Hello, On Dec 23, 2010, at 4:34 PM, Christoph Egger wrote: Module Name:src Committed By:cegger Date:Thu Dec 23 21:34:02 UTC 2010 Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Are you trying to tell me that i386 doesn't have bus_space_*_8() methods? I'd call that a bug. It is declared but not implemented. I got an 'undefined reference' linking error. Christoph
Re: CVS commit: src/sys/arch/i386/stand
On Fri, Dec 24, 2010 at 03:13:28PM +, David Laight wrote: On Wed, Dec 22, 2010 at 08:46:43PM +, Jonathan A. Kollasch wrote: Log Message: It just so happens we don't need -Wno-attributes if we place __packed in the right place. Does that need __packed (which would force unaligned access code) be added for all accesses, or just __attribute__((aligned(n))) for some fields? This doesn't make much difference on i386, but will on archs that don't support misaligned accesses. My intention here was only to make the existing code syntactically correct, not second guess the original author's intentions. Anyway, it's PXE, AFAIK that's i386-only anyway. Jonathan Kollasch
Re: CVS commit: src/external/gpl2/lvm2
In article dbbe99c7-5176-4fd4-8ac3-fc70b3a49...@gmail.com, Adam Hamsik haa...@gmail.com wrote: Then can you please request to import these changes to upstream repository ? https://bugzilla.redhat.com/show_bug.cgi?id=665562 christos
Re: CVS commit: src/sys/dev/pci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Dec 24, 2010, at 11:43 AM, Christoph Egger wrote: On 24.12.10 14:11, Michael wrote: Hello, On Dec 24, 2010, at 4:13 AM, Christoph Egger wrote: On 24.12.10 00:56, Michael wrote: Hello, On Dec 23, 2010, at 4:34 PM, Christoph Egger wrote: Module Name:src Committed By:cegger Date:Thu Dec 23 21:34:02 UTC 2010 Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Are you trying to tell me that i386 doesn't have bus_space_*_8() methods? I'd call that a bug. It is declared but not implemented. I got an 'undefined reference' linking error. That's about the worst possible reason for getting rid of a 64bit access. For all you know the hardware may need it. Either way, voyagerfb makes little to no sense on x86 anyway. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTRT59cpnzkX8Yg2nAQKQwQgAiupdJkHDbhr7YBl0VgjYALm9QGwrQKyZ AZWzdssyawxW+d4ozEthpoDrF5Sm4aKzS4mJxbvazCdkl1cXj87fxuGyGI+dW1B6 kdP/tyBx4l2Ww3vwKpBfcVNkaJJUz9K44HSxA04ZpJd3hy5w0DwID7gNsbXrvfEi 3b8G/hPL2nncEyYjTA0lGyxCR0DDe1lvfRGuHDIAtKb3rYQzsTiWl6du7rAPqljZ uvR1zeRWLDnYAfRY2taRZn3gsYiZ4dCIIVD1cXYlxe8FUifu2jnBPCuVxD7uRBBo BNILtenUkIHijmKZFq6Hb8nTxUSzGDmWxvZL4RoGd8Beq/zi5UoIeA== =DGbG -END PGP SIGNATURE-
Re: CVS commit: src/sys/arch/i386/stand/lib
In article 20101224203651.e3c4117...@cvs.netbsd.org,
Jonathan A. Kollasch source-changes-d@NetBSD.org wrote:
-=-=-=-=-=-
Module Name: src
Committed By: jakllsch
Date: Fri Dec 24 20:36:51 UTC 2010
Modified Files:
src/sys/arch/i386/stand/lib: biosdisk.c biosdisk.h biosdisk_ll.c
Log Message:
Sprinkle daddr_t.
Adjust DISK_DEBUG printf formats to match.
To generate a diff of this commit:
cvs rdiff -u -r1.31 -r1.32 src/sys/arch/i386/stand/lib/biosdisk.c
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/i386/stand/lib/biosdisk.h
cvs rdiff -u -r1.26 -r1.27 src/sys/arch/i386/stand/lib/biosdisk_ll.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
@@ -178,7 +178,7 @@
lp = (struct disklabel *) (d-buf + LABELOFFSET);
if (lp-d_magic != DISKMAGIC || dkcksum(lp)) {
#ifdef DISK_DEBUG
- printf(warning: no disklabel in sector %u\n, sector);
+ printf(warning: no disklabel in sector %lld\n, sector);
#endif
Are you sure this is right? My guess is that you would need PRId64
instead of lld.
christos
Re: CVS commit: src/sys/arch/i386/stand/lib
On Fri, Dec 24, 2010 at 11:00:40PM +, Christos Zoulas wrote:
In article 20101224203651.e3c4117...@cvs.netbsd.org,
Jonathan A. Kollasch source-changes-d@NetBSD.org wrote:
-=-=-=-=-=-
Module Name: src
Committed By:jakllsch
Date:Fri Dec 24 20:36:51 UTC 2010
Modified Files:
src/sys/arch/i386/stand/lib: biosdisk.c biosdisk.h biosdisk_ll.c
Log Message:
Sprinkle daddr_t.
Adjust DISK_DEBUG printf formats to match.
To generate a diff of this commit:
cvs rdiff -u -r1.31 -r1.32 src/sys/arch/i386/stand/lib/biosdisk.c
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/i386/stand/lib/biosdisk.h
cvs rdiff -u -r1.26 -r1.27 src/sys/arch/i386/stand/lib/biosdisk_ll.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
@@ -178,7 +178,7 @@
lp = (struct disklabel *) (d-buf + LABELOFFSET);
if (lp-d_magic != DISKMAGIC || dkcksum(lp)) {
#ifdef DISK_DEBUG
-printf(warning: no disklabel in sector %u\n, sector);
+printf(warning: no disklabel in sector %lld\n, sector);
#endif
Are you sure this is right? My guess is that you would need PRId64
instead of lld.
Well, maybe. But I expect int64_t will always be long long on i386.
Re: CVS commit: src/sys/arch/i386/stand/lib
Log Message: Sprinkle daddr_t. Adjust DISK_DEBUG printf formats to match. : -printf(warning: no disklabel in sector %u\n, sector); +printf(warning: no disklabel in sector %lld\n, sector); #endif Are you sure this is right? My guess is that you would need PRId64 instead of lld. libsa's printf(3) doesn't support %lld unless -DLIBSA_PRINTF_LONGLONG_SUPPORT is specified. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/i386/stand/lib
On Dec 24, 11:05pm, jakll...@kollasch.net (Jonathan A. Kollasch) wrote: -- Subject: Re: CVS commit: src/sys/arch/i386/stand/lib | Are you sure this is right? My guess is that you would need PRId64 | instead of lld. | | Well, maybe. But I expect int64_t will always be long long on i386. Isn't this code shared with amd64? Anyway PRId64 is more correct and works in all cases. christos
RE: CVS commit: src/sys/lib/libsa
Module Name:src Committed By: christos Date: Fri Dec 24 23:12:29 UTC 2010 Modified Files: src/sys/lib/libsa: stand.h Log Message: panic takes a printf format too. This changes breaks the build on port-amd64: /build/netbsd-local/src/sys/arch/i386/stand/boot/biosboot/../../../../../lib/libsa/alloc.c:217: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'char *' - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/arch/i386/stand/lib
On Fri, Dec 24, 2010 at 06:14:13PM -0500, Christos Zoulas wrote: On Dec 24, 11:05pm, jakll...@kollasch.net (Jonathan A. Kollasch) wrote: -- Subject: Re: CVS commit: src/sys/arch/i386/stand/lib | Are you sure this is right? My guess is that you would need PRId64 | instead of lld. | | Well, maybe. But I expect int64_t will always be long long on i386. Isn't this code shared with amd64? Anyway PRId64 is more correct and works in all cases. It is shared, in the sense that i386 stand code is built as part of the amd64 build. The kernel is responsible for the transition to Long Mode. Anyway, point taken...
Re: CVS commit: src/sys/arch/i386/stand/lib
On Sat, Dec 25, 2010 at 08:07:50AM +0900, Izumi Tsutsui wrote: Log Message: Sprinkle daddr_t. Adjust DISK_DEBUG printf formats to match. : - printf(warning: no disklabel in sector %u\n, sector); + printf(warning: no disklabel in sector %lld\n, sector); #endif Are you sure this is right? My guess is that you would need PRId64 instead of lld. libsa's printf(3) doesn't support %lld unless -DLIBSA_PRINTF_LONGLONG_SUPPORT is specified. True, that but it's not like this code path is often compiled. I should probably at least add the necessary gunk commented out in the makefile.
Re: CVS commit: src/sys/arch/i386/stand/lib
On Sat, Dec 25, 2010 at 12:09:43AM +, Jonathan A. Kollasch wrote: On Sat, Dec 25, 2010 at 08:07:50AM +0900, Izumi Tsutsui wrote: Log Message: Sprinkle daddr_t. Adjust DISK_DEBUG printf formats to match. : -printf(warning: no disklabel in sector %u\n, sector); +printf(warning: no disklabel in sector %lld\n, sector); #endif Are you sure this is right? My guess is that you would need PRId64 instead of lld. libsa's printf(3) doesn't support %lld unless -DLIBSA_PRINTF_LONGLONG_SUPPORT is specified. True, that but it's not like this code path is often compiled. I should probably at least add the necessary gunk commented out in the makefile. That has the problem that I can't find a nice way to enable 64-bit division runtime support in the amd64 libkern compiled for i386.
Re: CVS commit: src/sys/dev/pci
It is declared but not implemented. I got an 'undefined reference' linking error. Revert your change first. It's author's request and you didn't test it on hardware. No positive reason to keep it. Buildability of i386 ALL can't be an excuse in your case. You should make it defined reference in MD implementation, that's what the error pointed out. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/pci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Dec 24, 2010, at 8:51 PM, Izumi Tsutsui wrote: It is declared but not implemented. I got an 'undefined reference' linking error. Revert your change first. It's author's request and you didn't test it on hardware. No positive reason to keep it. Buildability of i386 ALL can't be an excuse in your case. You should make it defined reference in MD implementation, that's what the error pointed out. Well, the change isn't harmful - this time - and using bus_space_read_8() there was most likely a typo I made. I just wanted to warn him against: - - making changes in drivers he can't test, trivial or not, since there can be side effects as you already pointed out - - messing with drivers for hardware he's not remotely familiar with have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTRViNcpnzkX8Yg2nAQK7XwgAssIFmjmDTlM6opBLBC/3hXxtGjlybDCP ZTanG34+hqJ8ySdc+dpdpBoD3abAG6vWmrb1kW7chkbWQ6E2tY0gKr0a0A3jCbXb 6UwtpNaSkNNwwGtYqrHoD2W2JLq1vJY8NXm/1MI8ZA1pG/9UQ9SmneU8NxyZ7iOl Flm8OJ8wvHiUpyL/3lLwLxjwdyH1J9svl7ZfqaW2s6uKy/eC6HoSX6+VLNKO2Srw NrJlf+LpX1ilzgjMnVElo1Y7tUH78HWboTqqSwBT2MnRNT0fJDDVrm+N/X6TzkGv N1xJM9WR+cznah6F8GoiMWi3pWGRQeY8d+YEsI5NPiUUp0YpzLEwyg== =EUu+ -END PGP SIGNATURE-
Re: CVS commit: src/sys/dev/pci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Dec 24, 2010, at 5:11 AM, Christoph Egger wrote: On 24.12.10 11:07, Izumi Tsutsui wrote: Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Adding a bogus fix to make ALL buildable is quite silly. bus_space_read_8(9) is a documented MI API and MD implementation should provide bus_space_read_8() if the machine really needs the driver in its kernel, or don't enable the device on i386. The 'reg' variable is of type 'uint32_t'. So why using bus_space_read_8() when bus_space_read_4() gives the same result? Because you can't assume that all hardware allows partial register accesses. It may be true on (almost?) all x86 hardware but that's about it. Registers are in no way guaranteed to behave like memory locations. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTRVi8cpnzkX8Yg2nAQLkWwf9EcP2bPxTNbyg7IV89d9IK1y6fkX9MNwV DfW/mnsNbS8YAMAavcKSFty18wMI/3fVdVophTd+udVzL/A6lh8+zr5UZPPShJuT pshy/LgM5y9C6YYxN6gcHOdEN+MrMUNLen7poNyCSJ1IFVwLzS0YnBb6qScUm+V8 3JQFnz/zkiKtjBziWcxf7FjL9wwDoFiqSuGBAtzB+Hy0Llk24iZYkeSu1x/GwZIp Jzu1nOA+xmuqsYtzkxzQ8hMeTZHrqECW35475e+mTW0YtZqDMlNE4l483ptpnB2Q GrfcAz1FBopZk5Dh6CslBTPteafB8OE/AEK/watDKR6pftza7OiVVQ== =UoRH -END PGP SIGNATURE-
Re: CVS commit: src/sys/dev/pci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Dec 24, 2010, at 5:07 AM, Izumi Tsutsui wrote: Modified Files: src/sys/dev/pci: voyagerfb.c Log Message: read 32bits instead of 64bits and truncate the upper 32bits Please stop making unnecessary changes to drivers you can't test on actual hardware. Sorry, should have mentioned this makes the i386 ALL kernel linking. Adding a bogus fix to make ALL buildable is quite silly. bus_space_read_8(9) is a documented MI API and MD implementation should provide bus_space_read_8() if the machine really needs the driver in its kernel, or don't enable the device on i386. I wrote voyagerfb for the Gdium Liberty, a MIPS-based netbook. The graphics controller is part of a Silicon Motion SM502 which you're not likely to find in anything x86 ( probably because it lacks VGA compatibility ) but which seems to be popular with chinese MIPS hardware vendors. As far as I can tell there is no reason to have it in any i386 config. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTRVjnspnzkX8Yg2nAQKrSQf9FJvuxdynVOZ4PKrQLbBw69nHaQuki3L/ VzZwC65LOQ70PEzO2TPJhVlsN6h3CK8v4KKj5CdE0r5K1/7jAixCCX5k0GvjEmxR CGKo7tQ+OuN1jlsC/tsW4g8hqB/5bsPVSfcmCCX1WbzyDX5cWeNnyMk5ASzrsfzN hYJe3C6mCuqxsctlyDfa6+RqJGUgYXWCKZsXY4YTynaoweIL1acWnaiQQ83S5mjn m71t95meew8dGYLYY+KGmD4XcGh9N0FLY+9yA2h20M4eqLM7eKeeVfwERTAKDtOg Cnkd9ZUCEMYlehMfrmkKhMmWXW0ZZHUemVmOV6NJ6UOHoO4i+It0jw== =xfRd -END PGP SIGNATURE-
Re: CVS commit: src/sys/arch/i386/stand/lib
On Dec 25, 12:06am, jakll...@kollasch.net (Jonathan A. Kollasch) wrote: -- Subject: Re: CVS commit: src/sys/arch/i386/stand/lib | On Fri, Dec 24, 2010 at 06:14:13PM -0500, Christos Zoulas wrote: | On Dec 24, 11:05pm, jakll...@kollasch.net (Jonathan A. Kollasch) wrote: | -- Subject: Re: CVS commit: src/sys/arch/i386/stand/lib | | | Are you sure this is right? My guess is that you would need PRId64 | | instead of lld. | | | | Well, maybe. But I expect int64_t will always be long long on i386. | | Isn't this code shared with amd64? Anyway PRId64 is more correct and | works in all cases. | | It is shared, in the sense that i386 stand code is built as part of | the amd64 build. The kernel is responsible for the transition to Long | Mode. | | Anyway, point taken... Yes and because all the code is compiled with -m32 %ll will always work for int64_t because it is going to be long long. Strictly speaking this is about writing correct code, so always print int64_t with PRId64. christos
Re: CVS commit: src/sys/arch/i386/stand/lib
On Sat, Dec 25, 2010 at 01:27:43AM +, Jonathan A. Kollasch wrote: libsa's printf(3) doesn't support %lld unless -DLIBSA_PRINTF_LONGLONG_SUPPORT is specified. True, that but it's not like this code path is often compiled. I should probably at least add the necessary gunk commented out in the makefile. That has the problem that I can't find a nice way to enable 64-bit division runtime support in the amd64 libkern compiled for i386. It is fairly easy to write the printf code so that it can convert long long to decimal without requiring the 64bit division code (or any division code!). (Similarly you can avoid the double-word shifts for %x.) David -- David Laight: da...@l8s.co.uk
