x86_64 checks if we're building a big kernel to make sure that it's <= 4MB. Should we be doing something similar for i386? Or perhaps we shouldn't be
imposing this limit on x86_64?
Below is the relevant code diff that I'm asking about.
Thanks,
Daniel
---
This patch was previously sent on 2005-02-13:
http://marc.theaimsgroup.com/?l=linux-kernel=110826336917607=2
It still applies against 2.6.12-rc1-bk1.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
This patch was previously sent on 2005-02-13:
http://marc.theaimsgroup.com/?l=linux-kernelm=110826336917607w=2
It still applies against 2.6.12-rc1-bk1.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
x86_64 checks if we're building a big kernel to make sure that it's = 4MB. Should we be doing something similar for i386? Or perhaps we shouldn't be
imposing this limit on x86_64?
Below is the relevant code diff that I'm asking about.
Thanks,
Daniel
---
For the m32r architecture, is there a reason not to use the generic bug.h
definition?
Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
--- linux-2.6.11-rc4/include/asm-m32r/bug.h 2004-12-24 16:34:01.0
-0500
+++ linux/include/asm-m32r/bug.h2005-02-13 03:39:39.775236000
For the m32r architecture, is there a reason not to use the generic bug.h
definition?
Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
--- linux-2.6.11-rc4/include/asm-m32r/bug.h 2004-12-24 16:34:01.0
-0500
+++ linux/include/asm-m32r/bug.h2005-02-13 03:39:39.775236000 -0500
As per http://www.nist.gov/dads/HTML/shellsort.html, this should be referred to
as a Shell sort. Shell-Metzner is a misnomer.
Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-bk9/kernel/sys.c 2005-02-12 22:17:26.801294776 -0500
+++ linux/kernel/sys.c 2005-02-12
As per http://www.nist.gov/dads/HTML/shellsort.html, this should be referred to
as a Shell sort. Shell-Metzner is a misnomer.
Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
--- linux-2.6.11-rc3-bk9/kernel/sys.c 2005-02-12 22:17:26.801294776 -0500
+++ linux/kernel/sys.c 2005-02-12 17:53
Here is a small patch to main.c.
It does the following:
- makes sure that asm/mtrr.h actually gets included, and
- changes formatting in one place as per Documentation/CodingStyle
--- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001
+++ linux/init/main.c Sat Jun 16 11:48:42 2001
@@ -50,7
Here is a small patch to main.c.
It does the following:
- makes sure that asm/mtrr.h actually gets included, and
- changes formatting in one place as per Documentation/CodingStyle
--- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001
+++ linux/init/main.c Sat Jun 16 11:48:42 2001
@@ -50,7
Okay, I didn't realize how much opposition there would be to this,
thanks for all the input. If you'd like to add anything to this, please
email me personally -- the mailing list has probably seen enough traffic
regarding this issue. :-)
Thanks
Daniel
-
To unsubscribe from this list: send
Okay, I didn't realize how much opposition there would be to this,
thanks for all the input. If you'd like to add anything to this, please
email me personally -- the mailing list has probably seen enough traffic
regarding this issue. :-)
Thanks
Daniel
-
To unsubscribe from this list: send
Hi Andrew,
Thanks for your email. I am aware of the "traditions" of the Linux kernel,
and this is really why I wanted to start a discussion going about this.
Basically one of the things I am wondering is how complex the kernel code
can grow to become. All I am proposing is that old features
Hi Andrew,
Thanks for your email. I am aware of the traditions of the Linux kernel,
and this is really why I wanted to start a discussion going about this.
Basically one of the things I am wondering is how complex the kernel code
can grow to become. All I am proposing is that old features start
14 matches
Mail list logo
