mainly a note to me:
duplicate definitions in include/linux/fs.h and include/linux/buffer_head.h??
buffer_##name
if this is so, i could probably shave a few bytes off a kernel! wow…..
mainly a note to me:
duplicate definitions in include/linux/fs.h and include/linux/buffer_head.h??
buffer_##name
if this is so, i could probably shave a few bytes off a kernel! wow…..
I’ve built those in /linux/kernel/debs/ on Debian Unstable, and am currently building the same kernel on a Debian stable machine. This shouldn’t really make a difference, but Timmeah! had an issue on a stable box, so i’m trying it this way.
I’ve also switched down to gcc 2.95 instead of 3.3 for reasons ‘compatibility’ and some reports of ‘mysterious problems’ from some people on lkml.
This is the kernel I’m running on my SMP box and it’s going fine. Will be switching my gateway to it tomorrow methinks…. (it needs an upgrade. :)
There are basically no other changes between this an the last release.
In other related news, Linus is moving places of work (for at least a year) and working full time on kernel. This is cool :)
http://www.flamingspork.com/linux/kernel/debs/
Debs for 2.4.21-rc7-ac1-stew1 are up. Basically a bit of a test release this – trying to see how pany people actually like compete, nice, remotely optimized builds of the kernel in an easy to swallow .deb package. That and I want an easy package for myself to carry around and give to people :)
I’ll probably have more of my own patches into the next revision… actually.. i should really port the generic-x86 one over.
I’ve also got http://www.flamingspork.com/linux/kernel/stew-patches/ set up (or it will be when i finally rsync the site back up again) where i’ll dump any patches i have or am currently working on. I might reorganize that directory though – maby split up into v2.4/ and v2.5/.
One day soon I swear I’m going to go through the CONFIG options and replace half the descriptions with something better….. hmmm….
of the linux kernel, specifically lib.a and how things are built and linked in lib/
Hmmm….. had to get something tricky to do, couldn’t have just been an easy fix. Although, if i move some stuff around the previous patch might be accepted (there were some wrong things with the last one….
From: Stewart SmithDate: Wed Jun 4, 2003 3:56:09 PM Australia/Melbourne To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, David Woodhouse , Stewart Smith Subject: [PATCH] fixed: CRC32=y && 8193TOO=m unresolved symbols
Linus,
please apply – this fixes unresolved symbols when CONFIG_CRC32=y and CONFIG_8139TOO=m (it also appeared on some other ethernet device drivers). I think this is the right way to fix this problem. It at least now builds, links and boots (and hey, even my ethernet works so it can’t all be bad :)
patches cleanly against 2.5.70 and 2.5.70-bk8
--- linux-2.5.70-orig/include/linux/crc32.h 2003-05-05 09:53:08.000000000 +1000 +++ linux-2.5.70-stew3/include/linux/crc32.h 2003-06-04 15:27:34.000000000 +1000 @@ -6,6 +6,7 @@ #define _LINUX_CRC32_H #include+#include extern u32 crc32_le(u32 crc, unsigned char const *p, size_t len); extern u32 crc32_be(u32 crc, unsigned char const *p, size_t len); @@ -21,7 +22,16 @@ * is in bit nr 0], thus it must be reversed before use. Except for * nics that bit swap the result internally... */ -#define ether_crc(length, data) bitreverse(crc32_le(~0, data, length)) -#define ether_crc_le(length, data) crc32_le(~0, data, length) +static inline u32 ether_crc(size_t length, unsigned char const *data) +{ + return bitreverse(crc32_le(~0, data, length)); +} +EXPORT_SYMBOL(ether_crc); + +static inline u32 ether_crc_le(size_t length, unsigned char const *data) +{ + return crc32_le(~0, data, length); +} +EXPORT_SYMBOL(ether_crc_le); #endif /* _LINUX_CRC32_H */ --- linux-2.5.70-orig/kernel/ksyms.c 2003-06-02 23:28:32.000000000 +1000 +++ linux-2.5.70-stew3/kernel/ksyms.c 2003-06-04 15:11:37.000000000 +1000 @@ -58,6 +58,7 @@ #include #include #include +#include #include #if defined(CONFIG_PROC_FS)
shrinking an FS with allocation groups should only involve the redistributing of data in the last allocation group.
expanding should be pretty simple. possible resizing of last allocation group, plus the adding of empty ones.
hmm… i want resize() call in vfs!
Rusty has said it’s good, so he’s taking it on as the trivial patch monkey he is :)
basically ripping out the old UPDATE_ATIME macro and making people use the function (which has been there for a while, so nobody should really be using the capitalised version, but they were).