Peter Stuge wrote::
On another note, we're experimenting, for various reasons, with
-fPIC mode on v3, so as to support execute-in-place. I have a
question I would like to toss at some willing experimenters. If
anyone is interested I will ask in this forum. Let me know.
This makes sense
On Fri, Aug 10, 2007 at 09:31:28AM -0700, ron minnich wrote:
%p
I am wondering what people think of this idea. Comments?
It's the right thing to do. Are there any drawbacks?
On another note, we're experimenting, for various reasons, with
-fPIC mode on v3, so as to support
ron minnich wrote:
On 8/10/07, Stefan Reinauer [EMAIL PROTECTED] wrote:
This makes sense too. What are the drawbacks? :)
One of four registers gets permanently reserved. The code gets bigger
and about 10% slower.
but linuxbios is infinitely fast, and hence takes 0 time.
On 8/10/07, Stefan Reinauer [EMAIL PROTECTED] wrote:
This makes sense too. What are the drawbacks? :)
One of four registers gets permanently reserved. The code gets bigger
and about 10% slower.
but linuxbios is infinitely fast, and hence takes 0 time.
110% * 0 is 0. Therefore I prove
On Friday 10 August 2007 21:13, ron minnich wrote:
On 8/10/07, Stefan Reinauer [EMAIL PROTECTED] wrote:
Award Co have an 8K bootblock. We're planning on going from 16 to 64k
now?
If Award is 8K, then we can argue that smaller bios'es suck more.
I would like to take a chance on betting on
Thanks very much for this. I have a suggestion. Nowadays, for things
that are pointers, even if they are not typed as such, I've taken to
this style:
On 8/9/07, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote:
+ printk(BIOS_SPEW, base = 0x%04lx, reg = 0x%02x, value =
0x%02x\r\n,
On another note, we're experimenting, for various reasons, with
-fPIC mode on v3, so as to support execute-in-place. I have a
question I would like to toss at some willing experimenters. If
anyone is interested I will ask in this forum. Let me know.
This makes sense too. What are the
This patch removes all printk format warnings from my LBv3 build (Qemu
x86 config). This was tested with gcc 4.1.0 on x86.
However, the code at various locations is not 64bit clean at all and
will probably break down once we have more than 4GB of RAM. My patch
doesn't change that, it is merely
