Hi !
here's the first pre-release of 2.4.34. Nothing really serious, I only
merged the previously queued patches. Pete Zaitcev has issued a bunch
of USB fixes in usbserial and also more general locking to fix a bug
with some usb-storage devices such as the TEAC CD-210PU. We only know
that it fixed the problem for the reporter, but this should definitely
get more testing. There's also an interesting NFS fix from Jeff Layton.
Some people have asked me what the hotfix tree will become. It will
still exist in its current form to provide fixes for older versions.
But I will create a 4 digit version for latest release because people
got used to this since the 2.6-stable branch. The version suffix in
the hotfix will still reflect the equivalent head level (eg: hf33.1
will equal 2.4.33.1). I will prepare one soon with the most important
of the few bugs below.
Also, I've been asked by several people to consider merging Mikael
Pettersson's gcc4 patches :
http://user.it.uu.se/~mikpe/linux/patches/2.4/
I've been reluctant at first for the usual reasons : "who has a 2.4
distro with gcc4 ?", and after recalling all the trouble Marcelo
had to deal with during the gcc3 update. But after discussion with
some people, I realized that the problem is not here, it's for the
kernels those people have to maintain for other systems (eg: servers,
firewalls, etc...) and which they suddenly cannot build anymore after
they have updated the distro on their desktop PC.
With Mikael's help, I've carefully split ant reviewed ALL the fixes,
and carefully logged the error they each fixed. Also, warnings and
errors have been split. I must say that those fixes mostly consist in :
- both static and extern declarations for the same variable
- buggy lvalue casts in assignments
- buggy expressions such as (i < TIMEOUT > 0) and i=(++i) + FOO
- dangerous constructs such as :
foo = (type_foo *)
bar = (type_bar *)(something_else);
Since most of them were sleeping bugs waiting for someone to wake
them up, I considered it was worth merging them provided that we
observe no regression. So I have created a separate tree for it
that I will merge into mainline in a few pre-releases if we don't
encounter any problem.
What has been tested right now :
- make allmodconfig on x86 with gcc-2.95.3, 3.3.6 and 4.1.1
=> builds OK
- make "reasonable" config on x86-smp with all 3 compileres
=> builds and boots
- make "reasonable" config on x86_64 and PPC with gcc 4.1
=> builds and boots
- make "reasonable" config on sparc64-smp with 3.3.5 and 4.1.1
=> builds and boots
- build debian's sparc32 kernel with 4.1.1
=> builds
I have no problem not supporting some rare architectures, and
people who use them are welcome to port them. It's quite easy,
it took me less than two hours to fix both sparc32 and sparc64.
Also, I have checked that the patches were really not intrusive.
I could apply the following cumulative external patches on top
of a gcc4-patched kernel without even one reject :
vhz-jiffies64, pax, strict-overcommit, epoll, dm, netdev,
preempt, low-latency, virtual-servers, squashfs2.2, ntfs,
cifs, acl+ea, a large bunch of netfilter's patch-o-matic,
ebtables, layer7-classifier, openswan-1.0, tux3, loop-aes,
aic79xx, and a lot of small other ones.
Therefore, I consider the drawbacks almost inexistent (mostly
some work on our side) compared to the advantages of getting
cleaner code and making the job easier for the users to
maintain existing setups.
At the moment, it's available as a GIT tree here :
git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4-gcc4.git
and as pure patches (merged and split) here :
http://www.kernel.org/pub/linux/kernel/people/wtarreau/linux-2.4/gcc-4/
Feedback welcome, particularly on sparc/sparc64 where it is
difficult to build a full-featured kernel, and therefore I'm
sure there might still be a few corner cases.
Thanks for your patience during this long mail :-)
Regards,
Willy
Summary of changes from v2.4.33 to v2.4.34-pre1
============================================
Jeff Layton:
2.4 NFS client - update d_cache when server reports ENOENT on an NFS remove
Jukka Partanen:
Fix AVM C4 ISDN card init problems with newer CPUs
Pete Zaitcev:
Bug with USB proc_bulk in 2.4 kernel
USB: Little Rework for usbserial
USB: unsigned long flags
Willy Tarreau:
[BLKMTD] : missing offset sometimes causes panics
AVM C4 ISDN card : use cpu_relax() in busy loops
[PKTGEN] : fix an oops when used with bonding driver (Tien ChenLi)
export memchr() which is used by smbfs and lp driver.
Merge branch 'next'
Change VERSION to 2.4.34-pre1
--
On Wed, Aug 16, 2006 at 10:36:33PM +0000, Willy Tarreau wrote:
> Hi !
Hi Willy!
>...
> I've been reluctant at first for the usual reasons : "who has a 2.4
> distro with gcc4 ?", and after recalling all the trouble Marcelo
> had to deal with during the gcc3 update. But after discussion with
> some people, I realized that the problem is not here, it's for the
> kernels those people have to maintain for other systems (eg: servers,
> firewalls, etc...) and which they suddenly cannot build anymore after
> they have updated the distro on their desktop PC.
>...
> Since most of them were sleeping bugs waiting for someone to wake
> them up, I considered it was worth merging them provided that we
> observe no regression. So I have created a separate tree for it
> that I will merge into mainline in a few pre-releases if we don't
> encounter any problem.
>...
My points against allowing to compile kernel 2.4 with gcc 4 are:
- There isn't much testing coverage - and will never be much testing
coverage - of using a kernel 2.4 compiled with gcc 4.
We've already seen several cases where only some compiler versions
caused miscompilations or exposed a runtime bug in the kernel.
Since there shouldn't be any reason for still using a 2.4 kernel
except for "never change a running system", I don't see a good
reason for allowing such an untested gcc/kernel combination.
- Even if your distribution does no longer ship any gcc 3, it's
easy building and using your own gcc 3.4.6:
wget ftp://ftp.gnu.org/gnu/gcc/gcc-3.4.6/gcc-3.4.6.tar.bz2
tar xjf gcc-3.4.6.tar.bz2
mkdir build-gcc
cd build-gcc
../gcc-3.4.6/configure --enable-languages=c --prefix=/usr/local/gcc-3.4.6
make bootstrap
make install
# change HOSTCC and CC in the toplevel Makefile of the kernel:
# HOSTCC = /usr/local/gcc-3.4.6/bin/gcc
# CC = /usr/local/gcc-3.4.6/bin/gcc
> Regards,
> Willy
>...
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Thu, Aug 17, 2006 at 01:54:59AM +0200, Adrian Bunk wrote:
> Hi Willy!
Hi Adrian !
(I knew you would be the first one to raise your hand :-))
> My points against allowing to compile kernel 2.4 with gcc 4 are:
>
> - There isn't much testing coverage - and will never be much testing
> coverage - of using a kernel 2.4 compiled with gcc 4.
> We've already seen several cases where only some compiler versions
> caused miscompilations or exposed a runtime bug in the kernel.
Yes, and the same arguments were true when moving on to support gcc 3,
and the 3.4 that you propose below has not received much testing
coverage on 2.4 either. However, when you talk about exposing runtime
bugs, I notice that gcc 4 emits a lot of very valid compile time warnings
about constructs that can produced undefined code.
I was a bit disappointed when I saw the bugs Mikael had to fix to make
the kernel compilable by gcc 4. Also, for bad code generation, it's good
to be able to build 2.4 and 2.6 with the same kernels, because it helps
detecting compiler bugs faster.
Right now, I'd prefer getting gcc 4 support than gcc 3.4, because I don't
know if even one common distro has shipped with gcc 3.4 by default. 2.95,
3.0, and 3.3 have been common, and right now, 4.[01] is almost everywhere.
> Since there shouldn't be any reason for still using a 2.4 kernel
> except for "never change a running system",
I think that by "never change", you meant "except for regular updates".
> I don't see a good
> reason for allowing such an untested gcc/kernel combination.
You're very well placed to know that every new 2.6 that comes out has
received too little testing for some people to generally deploy it
everywhere. Probably that one year from now, 2.6.16 will be considered
the most stable kernel (and I hope it too) and people will deploy it
on thousands of remotely managed sites, but right now, they still rely
on 2.4 for this. And it's easier for them to check that a new gcc on
their old kernel runs as expected than to validate that a completely
new kernel (with a new gcc too) runs like the old one.
> - Even if your distribution does no longer ship any gcc 3, it's
> easy building and using your own gcc 3.4.6:
> wget ftp://ftp.gnu.org/gnu/gcc/gcc-3.4.6/gcc-3.4.6.tar.bz2
> tar xjf gcc-3.4.6.tar.bz2
> mkdir build-gcc
> cd build-gcc
> ../gcc-3.4.6/configure --enable-languages=c --prefix=/usr/local/gcc-3.4.6
> make bootstrap
> make install
> # change HOSTCC and CC in the toplevel Makefile of the kernel:
> # HOSTCC = /usr/local/gcc-3.4.6/bin/gcc
> # CC = /usr/local/gcc-3.4.6/bin/gcc
Agreed, and this is what *I* do, but I would understand people who don't
feel confident enough in a freshly built compiler to build their kernel
when they don't know all the relevant build options. BTW, you don't have
to change the makefile contents, you can simply pass CC= to make.
I know that our opinions diverge on the gcc+kernel subject because we
don't evaluate it from the same point of view, but you raised interesting
points anyway.
Thanks,
Willy
> Right now, I'd prefer getting gcc 4 support than gcc 3.4, because I don't
> know if even one common distro has shipped with gcc 3.4 by default. 2.95,
> 3.0, and 3.3 have been common, and right now, 4.[01] is almost everywhere.
but most distros that ship with gcc 4 aren't capable of running a 2.4
kernel.... all the new distros greatly depend on sysfs for example, and
ntpl in glibc requires 2.6 etc etc etc. So I'm rather sceptical about
this argument.
>
> > Since there shouldn't be any reason for still using a 2.4 kernel
> > except for "never change a running system",
>
> I think that by "never change", you meant "except for regular updates".
I think that you'll find that people who run 2.4 today, if you ask them,
will say "please change as little as possible, only serious bugs and
security issues". After all the people who run 2.4 still are generally
those who resist new stuff in favor of stability of existing systems....
But maybe it's worth doing a user survey to find out what the users of
2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
people who use enterprise distro kernels don't count for this since
they'll not go to a newer released 2.4 anyway)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> But maybe it's worth doing a user survey to find out what the users of
> 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> people who use enterprise distro kernels don't count for this since
> they'll not go to a newer released 2.4 anyway)
I have only one machine that is still running a v2.4 kernel (from ftp.kernel.org), and that is an
old P120 that I occasionally use as a wireless acess point.
The compiler on this P120 is indeed gcc-3.4. However, building any kernel on that machine is now
so excruciatingly painful that I am considering using a newer, beefier machine as a build machine
instead. That machine is running FC5, and so uses gcc-4.1. So from my perspective, being able to
build a 2.4 kernel using gcc-4.x would be a benefit.
Cheers,
Chris
____________________________________________________
Yahoo! Photos is now offering a quality print service from just 7p a photo. http://uk.photos.yahoo.com
Arjan van de Ven wrote:
> But maybe it's worth doing a user survey to find out what the users of
> 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> people who use enterprise distro kernels don't count for this since
> they'll not go to a newer released 2.4 anyway)
Currently I'm working with ARM based embedded systems. I prefer 2.4
kernels to 2.6 as they are smaller thus leaving more flash for jffs2.
Not speaking of the kernel a gcc 4.1.1 compile of code for a LPC2103
resulted in a clearly smaller binary as the same compile with gcc 3.4.
Thus I really would like to be able to use gcc 4.x with 2.4 kernels.
There are even kernel miscompiles with gcc 3.4 that might be fixed with
gcc 4 (one has to try).
--
Andreas Steinmetz SPAMmers use [email protected]
Hi Arjan,
On Thu, Aug 17, 2006 at 08:48:51AM +0200, Arjan van de Ven wrote:
>
> > Right now, I'd prefer getting gcc 4 support than gcc 3.4, because I don't
> > know if even one common distro has shipped with gcc 3.4 by default. 2.95,
> > 3.0, and 3.3 have been common, and right now, 4.[01] is almost everywhere.
>
> but most distros that ship with gcc 4 aren't capable of running a 2.4
> kernel.... all the new distros greatly depend on sysfs for example, and
> ntpl in glibc requires 2.6 etc etc etc. So I'm rather sceptical about
> this argument.
I know, and this is not what I'm targetting. People use 2.4 on their file
server or firewall for instance, on an old distro, while they use 2.6 on
their notebook with newer gcc. They build from their fresh new system
(because most often you don't install build tools on a server) and this
is at least why some of them have already been asking for this. To be honnest,
I don't really need gcc 4 myself right now, but I'm more responding to some
users demand that I find somewhat legitimate.
> > > Since there shouldn't be any reason for still using a 2.4 kernel
> > > except for "never change a running system",
> >
> > I think that by "never change", you meant "except for regular updates".
>
> I think that you'll find that people who run 2.4 today, if you ask them,
> will say "please change as little as possible, only serious bugs and
> security issues". After all the people who run 2.4 still are generally
> those who resist new stuff in favor of stability of existing systems....
> But maybe it's worth doing a user survey to find out what the users of
> 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> people who use enterprise distro kernels don't count for this since
> they'll not go to a newer released 2.4 anyway)
Agreed, that's also why I've left it in another tree right now, so that
interested people can test it and other ones have the time to pronounce
themselves against it if needed. Anyway, as I said, most of the fixes were
for real coding bugs, and do not affect either the output code nor external
patches. I don't want to experiment with new killer features at all, if I
accepted to work on 2.4, this is because I'm rather conservative ;-)
Cheers,
Willy
Andreas Steinmetz writes:
> Arjan van de Ven wrote:
> > But maybe it's worth doing a user survey to find out what the users of
> > 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> > people who use enterprise distro kernels don't count for this since
> > they'll not go to a newer released 2.4 anyway)
>
> Currently I'm working with ARM based embedded systems. I prefer 2.4
> kernels to 2.6 as they are smaller thus leaving more flash for jffs2.
> Not speaking of the kernel a gcc 4.1.1 compile of code for a LPC2103
> resulted in a clearly smaller binary as the same compile with gcc 3.4.
> Thus I really would like to be able to use gcc 4.x with 2.4 kernels.
> There are even kernel miscompiles with gcc 3.4 that might be fixed with
> gcc 4 (one has to try).
I've done a fair amount of ARM user-space hacking recently, and the
number of bug fixes one has to apply to gcc-3.3 or gcc-3.4 to make it
even semi-correct on ARM is scary. Since these versions aren't supported
any more, being able to use newer, hopefully less buggy, and _supported_
gcc versions is clearly beneficial.
Of course, this is not an issue for x86 users.
On Thu, Aug 17, 2006 at 10:35:24AM +0200, Andreas Steinmetz wrote:
> Arjan van de Ven wrote:
> > But maybe it's worth doing a user survey to find out what the users of
> > 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> > people who use enterprise distro kernels don't count for this since
> > they'll not go to a newer released 2.4 anyway)
>
> Currently I'm working with ARM based embedded systems. I prefer 2.4
> kernels to 2.6 as they are smaller thus leaving more flash for jffs2.
>...
In this case, kernel 2.4 is a workaround, not a solution, and the
solution is to get kernel 2.6 as small as kernel 2.4.
Can you send me the .config's you are using for 2.4 and 2.6
(preferably for kernel.org kernels)?
> Andreas Steinmetz
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
Hi,
>
> here's the first pre-release of 2.4.34. Nothing really serious, I only
http://www.kernel.org still points to marcelos git tree. Could someone change
this, please?
Thomas
--
Thomas V?gtle email: [email protected]
----- http://www.voegtle-clan.de/thomas ------
Chris Rankin skrev:
>> But maybe it's worth doing a user survey to find out what the users of
>> 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
>> people who use enterprise distro kernels don't count for this since
>> they'll not go to a newer released 2.4 anyway)
>
> I have only one machine that is still running a v2.4 kernel (from ftp.kernel.org), and that is an
> old P120 that I occasionally use as a wireless acess point.
>
> The compiler on this P120 is indeed gcc-3.4. However, building any kernel on that machine is now
> so excruciatingly painful that I am considering using a newer, beefier machine as a build machine
> instead. That machine is running FC5, and so uses gcc-4.1. So from my perspective, being able to
> build a 2.4 kernel using gcc-4.x would be a benefit.
>
>
Why not simply set up chroots to build in ??
--
Thomas
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_ARM=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_UCLINUX=y
MAGIC_ROM_PTR=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_OBSOLETE is not set
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# System Type
#
# CONFIG_ARCH_DSC21 is not set
# CONFIG_ARCH_VC547X is not set
# CONFIG_ARCH_DM270 is not set
# CONFIG_ARCH_CNXT is not set
CONFIG_ARCH_NETARM=y
# CONFIG_ARCH_TA7S is not set
# CONFIG_ARCH_TA7V is not set
# CONFIG_ARCH_SWARM is not set
# CONFIG_ARCH_INL is not set
# CONFIG_ARCH_SAMSUNG is not set
# CONFIG_ARCH_ATMEL is not set
# CONFIG_ARCH_IPOD is not set
CONFIG_CPU_BIG_ENDIAN=y
# CONFIG_NETARM_NET15 is not set
# CONFIG_NETARM_NET40 is not set
# CONFIG_NETARM_NET50 is not set
CONFIG_NETARM_NS7520=y
# CONFIG_BOARD_UNC20 is not set
CONFIG_BOARD_CONNECTME=y
# CONFIG_NETARM_BOOTLOADER_SECOND_SERIAL is not set
# CONFIG_NETARM_BOOTLOADER_DEBUG_OUTPUT is not set
# CONFIG_NETARM_BOOTLOADER_DEBUG_DEBUGGER is not set
# CONFIG_NETARM_BOOTLOADER_DEBUG_RAMPTEST is not set
# CONFIG_SET_MEM_PARAM is not set
CONFIG_RAMKERNEL=y
# CONFIG_ROMKERNEL is not set
CONFIG_CPU_ARM710=y
CONFIG_CPU_ARM7TDMI=y
CONFIG_CPU_32=y
CONFIG_CPU_32v4=y
# CONFIG_CPU_26 is not set
# CONFIG_CPU_WITH_CACHE is not set
CONFIG_NETARM_PLL_BYPASS=y
# CONFIG_CPU_WITH_MCR_INSTRUCTION is not set
CONFIG_NO_PGT_CACHE=y
DRAM_BASE=0x00000000
FLASH_MEM_BASE=0x02000000
DRAM_SIZE=0x00800000
FLASH_SIZE=0x00200000
#
# General setup
#
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_NET=y
# CONFIG_SYSVIPC is not set
CONFIG_REDUCED_MEMORY=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_SYSCTL is not set
# CONFIG_NWFPE is not set
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_FLAT=y
# CONFIG_BINFMT_ZFLAT is not set
CONFIG_BINFMT_SHARED_FLAT=y
# CONFIG_BINFMT_ELF is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_KERNEL_ELF=y
# CONFIG_PM is not set
# CONFIG_ARTHUR is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="root=/dev/mtdblock3 rootfstype=cramfs"
# CONFIG_ALIGNMENT_TRAP is not set
# CONFIG_PCI is not set
CONFIG_RAM_NOTHING_ATTACHED=y
# CONFIG_RAM_ATTACHED_ROMFS is not set
# CONFIG_RAM_ATTACHED_CRAMFS is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
# CONFIG_NET_NEIGH_DEBUG is not set
# CONFIG_NET_RESTRICTED_REUSE is not set
# CONFIG_UNIX is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_ARP_LIMIT is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_ARM_AM79C961A is not set
# CONFIG_ARM_CIRRUS is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
# CONFIG_CNXT_EMAC is not set
# CONFIG_FEC is not set
# CONFIG_CS89x0 is not set
# CONFIG_UCCS8900 is not set
# CONFIG_ETHER_NETARM is not set
CONFIG_ETHER_NS7520=y
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_ELF_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set
# CONFIG_MTD_PSD4256G is not set
#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=2000000
CONFIG_MTD_PHYSMAP_LEN=200000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
# CONFIG_MTD_DRAGONIX is not set
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_SNAPGEODE is not set
# CONFIG_MTD_NETteluC is not set
# CONFIG_MTD_MBVANILLA is not set
# CONFIG_MTD_ML401 is not set
# CONFIG_MTD_SUZAKU is not set
# CONFIG_MTD_KeyTechnology is not set
# CONFIG_MTD_SED_SIOSIII is not set
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_ARM_INTEGRATOR is not set
# CONFIG_MTD_CDB89712 is not set
# CONFIG_MTD_SA1100 is not set
# CONFIG_MTD_DC21285 is not set
# CONFIG_MTD_IQ80310 is not set
# CONFIG_MTD_EPXA10DB is not set
# CONFIG_MTD_FORTUNET is not set
# CONFIG_MTD_AUTCPU12 is not set
# CONFIG_MTD_IXP425 is not set
# CONFIG_MTD_SE4000 is not set
# CONFIG_MTD_SNAPARM is not set
# CONFIG_MTD_DM270 is not set
# CONFIG_MTD_CLPS7500 is not set
# CONFIG_MTD_EDB7312 is not set
# CONFIG_MTD_EDB9301 is not set
# CONFIG_MTD_EDB9302 is not set
# CONFIG_MTD_EDB9312 is not set
# CONFIG_MTD_EDB9315 is not set
# CONFIG_MTD_IMPA7 is not set
# CONFIG_MTD_CEIVA is not set
# CONFIG_MTD_VC547X is not set
# CONFIG_MTD_TIBURON is not set
# CONFIG_MTD_UCLINUX is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PCMCIA is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_MTDCNXT is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCPROBE is not set
#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BLK_DEV_RAMDISK_DATA is not set
# CONFIG_BLK_DEV_BLKMEM is not set
# CONFIG_BLK_STATS is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_QFMT_V2 is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_CRAMFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_EXT2_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_XFS_FS is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_ROOT_NFS is not set
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
# CONFIG_COREDUMP_PRINTK is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set
#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_UINPUT is not set
#
# Character devices
#
CONFIG_SERIAL_NETARM=y
# CONFIG_SERIAL_NETARM_CONSOLE is not set
CONFIG_NETARM_GPIO=y
# CONFIG_NETARM_GPIO_PICOTUX_TEST is not set
# CONFIG_LEDMAN is not set
# CONFIG_SNAPDOG is not set
# CONFIG_FAST_TIMER is not set
# CONFIG_DS1302 is not set
# CONFIG_M41T11M6 is not set
# CONFIG_VT is not set
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_ANAKIN is not set
# CONFIG_SERIAL_ANAKIN_CONSOLE is not set
# CONFIG_SERIAL_AMBA is not set
# CONFIG_SERIAL_AMBA_CONSOLE is not set
# CONFIG_SERIAL_CLPS711X is not set
# CONFIG_SERIAL_CLPS711X_CONSOLE is not set
# CONFIG_SERIAL_21285 is not set
# CONFIG_SERIAL_21285_OLD is not set
# CONFIG_SERIAL_21285_CONSOLE is not set
# CONFIG_SERIAL_UART00 is not set
# CONFIG_SERIAL_UART00_CONSOLE is not set
# CONFIG_SERIAL_SA1100 is not set
# CONFIG_SERIAL_SA1100_CONSOLE is not set
# CONFIG_SERIAL_OMAHA is not set
# CONFIG_SERIAL_OMAHA_CONSOLE is not set
# CONFIG_SERIAL_AT91 is not set
# CONFIG_SERIAL_AT91_CONSOLE is not set
# CONFIG_SERIAL_8250 is not set
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=8
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
# CONFIG_EDB7312_TS is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set
#
# Controller Area Network Cards/Chips
#
# CONFIG_CAN4LINUX is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_SCx200 is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
#
# Direct Rendering Manager (XFree86 DRI support)
#
# CONFIG_DRM is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Support for USB gadgets
#
# CONFIG_USB_GADGET is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set
#
# Kernel hacking
#
CONFIG_FRAME_POINTER=y
# CONFIG_REVISIT is not set
# CONFIG_DEBUG_ERRORS is not set
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_LL is not set
CONFIG_CONTIGUOUS_PAGE_ALLOC=y
# CONFIG_MEM_MAP is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
On Thu, Aug 17, 2006 at 10:50:43AM +0200, Mikael Pettersson wrote:
> Andreas Steinmetz writes:
> > Arjan van de Ven wrote:
> > > But maybe it's worth doing a user survey to find out what the users of
> > > 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> > > people who use enterprise distro kernels don't count for this since
> > > they'll not go to a newer released 2.4 anyway)
> >
> > Currently I'm working with ARM based embedded systems. I prefer 2.4
> > kernels to 2.6 as they are smaller thus leaving more flash for jffs2.
> > Not speaking of the kernel a gcc 4.1.1 compile of code for a LPC2103
> > resulted in a clearly smaller binary as the same compile with gcc 3.4.
> > Thus I really would like to be able to use gcc 4.x with 2.4 kernels.
> > There are even kernel miscompiles with gcc 3.4 that might be fixed with
> > gcc 4 (one has to try).
>
> I've done a fair amount of ARM user-space hacking recently, and the
> number of bug fixes one has to apply to gcc-3.3 or gcc-3.4 to make it
> even semi-correct on ARM is scary. Since these versions aren't supported
> any more, being able to use newer, hopefully less buggy, and _supported_
> gcc versions is clearly beneficial.
>
> Of course, this is not an issue for x86 users.
The only valid point I see for still using kernel 2.4 is
"never touch a running system".
But your ARM work seems to be new development.
If there are any problems preventing people from switching to kernel 2.6
when deploying new systems (e.g. increased kernel size), we should get
these problems reported and fixed in kernel 2.6.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
On Thu, Aug 17, 2006 at 02:48:39PM +0200, Adrian Bunk wrote:
> On Thu, Aug 17, 2006 at 10:50:43AM +0200, Mikael Pettersson wrote:
> > Andreas Steinmetz writes:
> > > Arjan van de Ven wrote:
> > > > But maybe it's worth doing a user survey to find out what the users of
> > > > 2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> > > > people who use enterprise distro kernels don't count for this since
> > > > they'll not go to a newer released 2.4 anyway)
> > >
> > > Currently I'm working with ARM based embedded systems. I prefer 2.4
> > > kernels to 2.6 as they are smaller thus leaving more flash for jffs2.
> > > Not speaking of the kernel a gcc 4.1.1 compile of code for a LPC2103
> > > resulted in a clearly smaller binary as the same compile with gcc 3.4.
> > > Thus I really would like to be able to use gcc 4.x with 2.4 kernels.
> > > There are even kernel miscompiles with gcc 3.4 that might be fixed with
> > > gcc 4 (one has to try).
> >
> > I've done a fair amount of ARM user-space hacking recently, and the
> > number of bug fixes one has to apply to gcc-3.3 or gcc-3.4 to make it
> > even semi-correct on ARM is scary. Since these versions aren't supported
> > any more, being able to use newer, hopefully less buggy, and _supported_
> > gcc versions is clearly beneficial.
> >
> > Of course, this is not an issue for x86 users.
>
> The only valid point I see for still using kernel 2.4 is
> "never touch a running system".
>
> But your ARM work seems to be new development.
>
> If there are any problems preventing people from switching to kernel 2.6
> when deploying new systems (e.g. increased kernel size), we should get
> these problems reported and fixed in kernel 2.6.
No, you don't get it, we're not talking about the same people.
Please let me explain a little bit, I hope it will not be too boring.
There are people out there who design systems that must comply
with very high levels of availability. Currently, it's fairly
easy to achieve 99.999% with "outdated" versions. This is 5mn16s
total downtime per year. While you will occasionnaly find people
running DNS servers on 2.0, most people who need very high
availability run either 2.2 or 2.4. Why ?
Simply because we already know from collective experience that
these versions can achieve very long uptimes (while we don't know
this yet for a fresh new version which got 5700 patches in the
last 3 months), and because with the addition of very few patches,
you can make a bet on security : as long as newly discovered
vulnerabilities don't affect you or are covered by your additionnal
patches, you win. If you need to update and induce excessive
downtime, you lose and pay penalties.
In order to reduce the risk of downtime because of a newly discovered
vulnerability, those people will deploy the very latest fixes hoping
to push forward the next time they'll have to reboot. Generally, the
goal is not to touch those systems for 3-5 years. And it can
generally be achieved. I personnaly got half a dozen of systems to
exceed 1000 days of uptime under sustained moderate load using 2.4.18
based kernels. You see ? you rack the machine today and do not have
to come back to see it again for the next 3 years ! It might sound
stupid to some people, but there are places where one single person
remotely manages 100-300 different systems for various customers.
Simply do the math.
By this time, those people obviously know that they will have more
and more problems getting 2.4 to run reliably on fresh new hardware.
So while their hardware is running fine on remote sites, they have
time to chase bugs on 2.6 and try to validate a completely new
distro. But it takes time to restart from scratch with every new 2.6
release. And I think that your work on 2.6.16 is the best gift anyone
could send them.
I personally have high expectations and hope on what you're doing,
because as most of those people, I'm fairly depending on 2.4 now, and
I hope that 3 years from now, I will be deploying extremely reliable
2.6-based systems.
But before enough positive feedback gets collected, those people still
need to run 2.4 and even deploy fresh new systems on 2.4 right now.
Basically, my goal is to keep all those users trusting Linux (other
systems such as OpenBSD are very present in this area too). And your
goal is to progressively attract them towards 2.6 with strong arguments
in favor of 2.6 (and not against 2.4) that only them will judge relevant
based on their usage. And I can tell you that 2.4 being harder to build
than 2.6 is obviously not a relevant argument in favor of 2.6 for people
who apply more than 100 patches to their kernels.
> cu
> Adrian
Best regards,
Willy
Hi Willy,
first thank you for continuing work for 2.4, our company still relies on it
for a lot of machines.
> By this time, those people obviously know that they will have more
> and more problems getting 2.4 to run reliably on fresh new hardware.
Yes, we've already experienced problems with new hw. We could solve most of
the stuff with some vendor supplied patches. But now we got performance
problems with ICH7 SATA performance: a disk does only about 11MB/s on 2.4
with all 2.4 patches from Jeff applied while we get about 40MB/s on 2.6.16.
Backporting the libata changes done between 2.6.15 (I think that is about the
same codebase as the current 2.4 stuff) and 2.6.16 seems like a big task.
So my question is: what is your policy on new or enhanced drivers (not just
new pciids)?
Kind regards,
Gerd
Hi Gerd,
On Fri, Aug 18, 2006 at 01:41:19AM +0200, Gerd v. Egidy wrote:
> Hi Willy,
>
> first thank you for continuing work for 2.4, our company still relies on it
> for a lot of machines.
>
> > By this time, those people obviously know that they will have more
> > and more problems getting 2.4 to run reliably on fresh new hardware.
>
> Yes, we've already experienced problems with new hw. We could solve most of
> the stuff with some vendor supplied patches. But now we got performance
> problems with ICH7 SATA performance: a disk does only about 11MB/s on 2.4
> with all 2.4 patches from Jeff applied while we get about 40MB/s on 2.6.16.
> Backporting the libata changes done between 2.6.15 (I think that is about the
> same codebase as the current 2.4 stuff) and 2.6.16 seems like a big task.
>
> So my question is: what is your policy on new or enhanced drivers (not just
> new pciids)?
Generally, new drivers should be avoided. The main reason is very simple :
most of the kernel developers spend their time on 2.6. They know they don't
need to touch 2.4 much because what is in it does not change a lot.
Maintaining drivers takes a lot of time, needs a lot of testing and
feedback from the users. And of course, I don't have enough knowledge
to maintain all drivers myself ! So if a completely new driver which does
not overlap at all with anything else is proposed AND a maintainer swears
he's ready to support it for the whole 2.4 life, I might not be opposed
to merge it. But I will not ask current maintainers to support new drivers
in their areas.
In your case (SATA), you have a driver which is working, but performance
is not as good as on 2.6. Well, performance is a good reason to evaluate
2.6. Use 2.4 on the most critical machines, and 2.6 on those which can
suffer more common updates. Your feedback will help 2.6 developers a lot.
Of course, if you find real bugs in 2.4 SATA I'm OK to apply the fixes,
even more if the same fix is already in 2.6.
BTW, I have already looked at the 2.6 SATA code some time ago, and I
noticed that it has evolved very quickly since 2.4 got resynced. So
even if one would like to resync with current 2.6 code, I'm not sure
it would be easy at all. If you manage to provide a backport, we can
ask Jeff if agrees to merge it, but I'm not sure he will accept since
he said that current SATA in 2.4 was his last update.
BTW, another solution for you if you need performance on 2.4 might
be to try an add-on SATA controller of different brand. Those cards
are very cheap and will only use one PCI slot, which is OK if you
don't need it for anything else.
> Kind regards,
>
> Gerd
Regards,
Willy
On Thu, Aug 17, 2006 at 12:16:56PM +0300, Thomas Backlund wrote:
> Chris Rankin skrev:
> >>But maybe it's worth doing a user survey to find out what the users of
> >>2.4 want... (and with that I mean users of the kernel.org 2.4 kernels,
> >>people who use enterprise distro kernels don't count for this since
> >>they'll not go to a newer released 2.4 anyway)
> >
> >I have only one machine that is still running a v2.4 kernel (from
> >ftp.kernel.org), and that is an
> >old P120 that I occasionally use as a wireless acess point.
> >
> >The compiler on this P120 is indeed gcc-3.4. However, building any kernel
> >on that machine is now
> >so excruciatingly painful that I am considering using a newer, beefier
> >machine as a build machine
> >instead. That machine is running FC5, and so uses gcc-4.1. So from my
> >perspective, being able to
> >build a 2.4 kernel using gcc-4.x would be a benefit.
> >
> >
>
> Why not simply set up chroots to build in ??
"simply" :-)
setting up a reliable build chroot is more difficult than just rebuilding
another gcc !
> Thomas
Regards,
willy
Hi Willy,
On Wed, Aug 16, 2006 at 10:36:33PM +0000, Willy Tarreau wrote:
> Also, I've been asked by several people to consider merging Mikael
> Pettersson's gcc4 patches :
>
> http://user.it.uu.se/~mikpe/linux/patches/2.4/
>
> I've been reluctant at first for the usual reasons : "who has a 2.4
> distro with gcc4 ?" ...
We're about to migrate Openwall GNU/*/Linux (Owl) from its current gcc
3.4.5 (which we used in our 2.0 release) to gcc 4+ - and we'd rather
_not_ migrate to Linux 2.6 at the same time, if we can. We'd be more
comfortable migrating to Linux 2.6 a few months later.
So your intent to add gcc 4+ support into Linux 2.4 is very welcome!
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
On Sat, Aug 19, 2006 at 02:48:14AM +0400, Solar Designer wrote:
> Hi Willy,
>
> On Wed, Aug 16, 2006 at 10:36:33PM +0000, Willy Tarreau wrote:
> > Also, I've been asked by several people to consider merging Mikael
> > Pettersson's gcc4 patches :
> >
> > http://user.it.uu.se/~mikpe/linux/patches/2.4/
> >
> > I've been reluctant at first for the usual reasons : "who has a 2.4
> > distro with gcc4 ?" ...
>
> We're about to migrate Openwall GNU/*/Linux (Owl) from its current gcc
> 3.4.5 (which we used in our 2.0 release) to gcc 4+ - and we'd rather
> _not_ migrate to Linux 2.6 at the same time, if we can. We'd be more
> comfortable migrating to Linux 2.6 a few months later.
>...
Considering that it's really easy to compile the kernel with a different
compiler than the userland, do you _really_ want to use such a
relatively untested kernel/gcc combination for a server platform?
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Thu, Aug 17, 2006 at 11:16:11AM +0200, Andreas Steinmetz wrote:
> Adrian Bunk wrote:
> > Can you send me the .config's you are using for 2.4 and 2.6
> > (preferably for kernel.org kernels)?
> >
>
> I can send you only the current 2.4 config I use (not exactly vanilla).
Thanks, but it didn't help me much since it needed some work getting it
compiling with uClinux-2.4.31-uc0, and the next step of creating a
functionally equivalent 2.6 kernel doesn't seem to be reasonably
possible.
My aim is to compare the size of the compiled objects for finding what
causes size regressions in 2.6 compared to 2.4.
Does anyone have an example with working kernels for both 2.4 and 2.6
and a significantely bigger functionally equivalent 2.6 kernel?
> Andreas Steinmetz
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> On Sat, Aug 19, 2006 at 02:48:14AM +0400, Solar Designer wrote:
> > We're about to migrate Openwall GNU/*/Linux (Owl) from its current gcc
> > 3.4.5 (which we used in our 2.0 release) to gcc 4+ - and we'd rather
> > _not_ migrate to Linux 2.6 at the same time, if we can. We'd be more
> > comfortable migrating to Linux 2.6 a few months later.
On Sat, Aug 19, 2006 at 01:11:15AM +0200, Adrian Bunk wrote:
> Considering that it's really easy to compile the kernel with a different
> compiler than the userland,
We want our end users to be able to rebuild all of Owl (including the
kernel) from source using only tools that are a part of Owl, yet we do
not want to be providing multiple versions of gcc (or of any other
package, for that matter). We've been successful at not providing
multiple versions of development tools and libraries so far - keeping
the system small and clean, yet fully self-rebuildable.
> do you _really_ want to use such a
> relatively untested kernel/gcc combination for a server platform?
I expect that we will fully move to Linux 2.6 before our next release,
but being able to move to gcc 4+ in Owl-current first simplifies our
development process. (And, yes, we've got end users of Owl-current who
will be recompiling kernels.)
Also, I expect this kernel/gcc combination to receive quite some testing
soon, if/once it becomes supported.
Alexander
On Sat, 19 Aug 2006 01:25:01 +0200, Adrian Bunk <[email protected]> wrote:
>Does anyone have an example with working kernels for both 2.4 and 2.6
>and a significantely bigger functionally equivalent 2.6 kernel?
grant@peetoo:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 1138921 2006-07-30 07:18 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 1139045 2006-07-30 06:35 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 1139058 2006-07-30 06:00 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 1138830 2006-08-12 15:55 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 1632535 2006-07-29 16:34 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1644014 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1643932 2006-08-14 05:25 /boot/bzImage-2.6.17.8b
-rw-r--r-- 1 root root 1668673 2006-08-09 16:25 /boot/bzImage-2.6.18-rc4a
grant@sempro:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 1129330 2006-07-30 07:04 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 1129379 2006-07-30 06:35 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 1129523 2006-07-30 05:46 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 1133768 2006-08-12 15:55 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 1783286 2006-07-29 16:34 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1746301 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1746294 2006-08-14 05:23 /boot/bzImage-2.6.17.8b
-rw-r--r-- 1 root root 1795269 2006-08-07 09:33 /boot/bzImage-2.6.18-rc3-mm2a
-rw-r--r-- 1 root root 1770411 2006-08-09 16:25 /boot/bzImage-2.6.18-rc4a
grant@silly:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 1042781 2006-07-30 07:25 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 1042926 2006-07-30 06:45 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 1042947 2006-07-30 06:04 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 1042782 2006-08-12 15:55 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 1417798 2006-07-29 16:34 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1430140 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1451699 2006-08-09 16:32 /boot/bzImage-2.6.18-rc4a
grant@stinkpad:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 795909 2006-07-30 07:08 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 795939 2006-07-30 06:23 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 831636 2006-07-30 05:45 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 831623 2006-08-12 16:25 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 831614 2006-07-28 12:08 /boot/bzImage-2.4.33-rc3
-rw-r--r-- 1 root root 1155031 2006-07-29 16:33 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1140869 2006-07-29 14:10 /boot/bzImage-2.6.17.7a
-rw-r--r-- 1 root root 1141543 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1767681 2006-08-02 16:17 /boot/bzImage-2.6.18-rc3a [1]
-rw-r--r-- 1 root root 1770411 2006-08-09 15:59 /boot/bzImage-2.6.18-rc4a [1]
grant@tosh:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 1001949 2006-07-30 07:18 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 1003065 2006-07-30 06:35 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 1001865 2006-07-30 06:01 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 1001815 2006-08-12 15:55 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 1758378 2006-07-29 16:34 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1765996 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1770972 2006-08-09 16:25 /boot/bzImage-2.6.18-rc4a
grant@niner:~$ ls -l /boot/bzImage-2.*
-rw-r--r-- 1 root root 849759 2006-07-30 07:21 /boot/bzImage-2.4.30-hf32.7
-rw-r--r-- 1 root root 849671 2006-07-30 06:35 /boot/bzImage-2.4.31-hf32.7
-rw-r--r-- 1 root root 925166 2006-07-30 06:00 /boot/bzImage-2.4.32-hf32.7
-rw-r--r-- 1 root root 925027 2006-08-12 15:55 /boot/bzImage-2.4.33-final
-rw-r--r-- 1 root root 1331906 2006-07-29 16:33 /boot/bzImage-2.6.16.27a
-rw-r--r-- 1 root root 1340701 2006-08-09 14:49 /boot/bzImage-2.6.17.8a
-rw-r--r-- 1 root root 1361000 2006-08-09 16:25 /boot/bzImage-2.6.18-rc4a
Looks like a consistent ~40% bloat to me ;)
Configs (grep = .config) up on <http://bugsplatter.mine.nu/test/>, very
similar configs as I dual boot 2.4 / 2.6 for testing. NICs and vfst/ntfs
as modules on boxen dual-boot 'doze/linux.
2.6 boots but no longer works properly on box deltree since last couple
releases, I have no desire to take the firewall box down to discover why
2.6 no longer does networking like it used to. 2.6 leaving old hardware
behind, who cares? Is why I stay with 2.4 on older hardware.
[1] fails to boot, locks up just after lilo, too early in boot to gain
any clues at all :( IBM 365X early model, usually runs win98, an orphan?
Grant.
On Sat, Aug 19, 2006 at 01:25:01AM +0200, Adrian Bunk wrote:
> On Thu, Aug 17, 2006 at 11:16:11AM +0200, Andreas Steinmetz wrote:
> > Adrian Bunk wrote:
> > > Can you send me the .config's you are using for 2.4 and 2.6
> > > (preferably for kernel.org kernels)?
> > >
> >
> > I can send you only the current 2.4 config I use (not exactly vanilla).
>
> Thanks, but it didn't help me much since it needed some work getting it
> compiling with uClinux-2.4.31-uc0, and the next step of creating a
> functionally equivalent 2.6 kernel doesn't seem to be reasonably
> possible.
In his case, it is a very valid reason to stay on 2.4 right now, which
was the original question IIRC.
> My aim is to compare the size of the compiled objects for finding what
> causes size regressions in 2.6 compared to 2.4.
Sometimes it will be compilers, but not by that much. Gcc3.[34] generally
produce bigger code than 2.95 at -O2, but I don't think that people in the
embedded world still use 2.95 much.
Cheers,
Willy
On Sat, Aug 19, 2006 at 11:20:22AM +1000, Grant Coady wrote:
> On Sat, 19 Aug 2006 01:25:01 +0200, Adrian Bunk <[email protected]> wrote:
>
> >Does anyone have an example with working kernels for both 2.4 and 2.6
> >and a significantely bigger functionally equivalent 2.6 kernel?
>
> grant@peetoo:~$ ls -l /boot/bzImage-2.*
> -rw-r--r-- 1 root root 1138921 2006-07-30 07:18 /boot/bzImage-2.4.30-hf32.7
> -rw-r--r-- 1 root root 1139045 2006-07-30 06:35 /boot/bzImage-2.4.31-hf32.7
> -rw-r--r-- 1 root root 1139058 2006-07-30 06:00 /boot/bzImage-2.4.32-hf32.7
> -rw-r--r-- 1 root root 1138830 2006-08-12 15:55 /boot/bzImage-2.4.33-final
> -rw-r--r-- 1 root root 1632535 2006-07-29 16:34 /boot/bzImage-2.6.16.27a
> -rw-r--r-- 1 root root 1644014 2006-08-09 14:48 /boot/bzImage-2.6.17.8a
> -rw-r--r-- 1 root root 1643932 2006-08-14 05:25 /boot/bzImage-2.6.17.8b
> -rw-r--r-- 1 root root 1668673 2006-08-09 16:25 /boot/bzImage-2.6.18-rc4a
>...
> Looks like a consistent ~40% bloat to me ;)
>...
Don't trust any statistics you did not fake yourself...
Your numbers show a 46.5% size increase from kernel to 2.4.33 to
2.6.18-rc4.
But it's an extremely unfair comparison when I asked for "functionally
equivalent" kernels, and you do e.g. compile your 2.4 kernel with APM
support and your 2.6 kernel with ACPI support.
Numbers with a more fair comparison for this machine
(.config's attached) are:
-rw-rw-r-- 1 bunk bunk 1076676 2006-08-19 14:59 bzImage-2.4-gcc3.3
-rw-rw-r-- 1 bunk bunk 1431789 2006-08-19 14:59 bzImage-2.6-gcc3.3
That's only a 33% size increase.
Not that a 33% size increase was a good thing... Changes to the
.config's can make the difference a bit smaller or bigger, but unless
I'm cheating with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, I'm not coming even
remotely near to a similar size.
Unfortunately, there is not one thing that is causing the size increase.
If only stuff like ACPI that shouldn't matter in size limited
environments would become bigger it wasn't a big issue.
But looking at the objects, it seems that except for some subsystems
without real development that stay at the same size (e.g. IDE, OSS, ext2),
nearly everything grows by between 10% and 100%... :-(
> Grant.
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Sat, Aug 19, 2006 at 06:45:33AM +0200, Willy Tarreau wrote:
>...
> Sometimes it will be compilers, but not by that much. Gcc3.[34] generally
> produce bigger code than 2.95 at -O2, but I don't think that people in the
> embedded world still use 2.95 much.
Comparing code size different gcc versions produce with -O2 is a bit
unfair, the size of -Os code is more important in this case.
> Cheers,
> Willy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Aug 21, 2006 at 02:35:49AM +0200, Adrian Bunk wrote:
> On Sat, Aug 19, 2006 at 06:45:33AM +0200, Willy Tarreau wrote:
> >...
> > Sometimes it will be compilers, but not by that much. Gcc3.[34] generally
> > produce bigger code than 2.95 at -O2, but I don't think that people in the
> > embedded world still use 2.95 much.
>
> Comparing code size different gcc versions produce with -O2 is a bit
> unfair, the size of -Os code is more important in this case.
Yes, but the code produced by gcc-3.[34] -Os is so unoptimized that it's
practically unusable for anything oocasionnaly using the CPU. I use it
mainly for bootloaders and tools like this. On the opposite, gcc-2.95 -Os
was still relatively well optimized, which often resulted in faster execution
due to smaller cache footprint. And for many programs, I have relied on this
combination.
>
> > Cheers,
> > Willy
>
> cu
> Adrian
Cheers,
Willy
On Thu, Aug 17, 2006 at 10:43:07PM +0200, Willy Tarreau wrote:
> Hi Adrian,
Hi Willy,
>...
> Basically, my goal is to keep all those users trusting Linux (other
> systems such as OpenBSD are very present in this area too). And your
> goal is to progressively attract them towards 2.6 with strong arguments
> in favor of 2.6 (and not against 2.4) that only them will judge relevant
> based on their usage. And I can tell you that 2.4 being harder to build
> than 2.6 is obviously not a relevant argument in favor of 2.6 for people
> who apply more than 100 patches to their kernels.
it was not my goal to make it harder for people to build 2.4.
I'd in fact consider userspace and hardware support the real problems
for people who want to use kernel 2.4 - using a different compiler is
a relatively easy issue compared to this.
And I had mixed two complete different points in this thread:
- untested kernel 2.4 / gcc 4
- kernel 2.6 shouldn't be in any respect worse than kernel 2.4
Looking at the kenrel size, it seems the latter is far from being true
in this respect. :-(
The "untested" still applies.
But I do also understand your points regardingthis issue.
If I was 2.4 maintainer, I wouldn't apply the patch to allow gcc 4.
But you are the 2.4 maintainer, and it's therefore your decision.
> Best regards,
> Willy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Aug 21, 2006 at 02:41:46AM +0200, Willy Tarreau wrote:
> On Mon, Aug 21, 2006 at 02:35:49AM +0200, Adrian Bunk wrote:
> > On Sat, Aug 19, 2006 at 06:45:33AM +0200, Willy Tarreau wrote:
> > >...
> > > Sometimes it will be compilers, but not by that much. Gcc3.[34] generally
> > > produce bigger code than 2.95 at -O2, but I don't think that people in the
> > > embedded world still use 2.95 much.
> >
> > Comparing code size different gcc versions produce with -O2 is a bit
> > unfair, the size of -Os code is more important in this case.
>
> Yes, but the code produced by gcc-3.[34] -Os is so unoptimized that it's
> practically unusable for anything oocasionnaly using the CPU. I use it
> mainly for bootloaders and tools like this. On the opposite, gcc-2.95 -Os
> was still relatively well optimized, which often resulted in faster execution
> due to smaller cache footprint. And for many programs, I have relied on this
> combination.
Embedded people often care more about size than about speed.
E.g. the ARM people always use -Os (in both 2.4 and 2.6).
For people not caring that much about size, the difference of the size
of -O2 output shouldn't matter.
> Cheers,
> Willy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed