Isapnp: Kill warning if CONFIG_PCI is not set
--- linux-2.5.x/drivers/pnp/resource.c Tue May 27 19:03:04 2003
+++ linux-m68k-2.5.x/drivers/pnp/resource.c Sun Jun 8 13:31:20 2003
@@ -97,7 +97,9 @@
int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
{
+#ifdef CONFIG_PCI
int i;
+#endif
struct pnp_resources *res;
struct pnp_irq *ptr;
res = pnp_find_resources(dev,depnum);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sul, 2003-06-15 at 19:36, Geert Uytterhoeven wrote:
> Isapnp: Kill warning if CONFIG_PCI is not set
>
> --- linux-2.5.x/drivers/pnp/resource.c Tue May 27 19:03:04 2003
> +++ linux-m68k-2.5.x/drivers/pnp/resource.c Sun Jun 8 13:31:20 2003
> @@ -97,7 +97,9 @@
>
> int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
> {
> +#ifdef CONFIG_PCI
> int i;
> +#endif
This is far uglier than te warning
On 21 Jun 2003, Alan Cox wrote:
> On Sul, 2003-06-15 at 19:36, Geert Uytterhoeven wrote:
> > Isapnp: Kill warning if CONFIG_PCI is not set
> >
> > --- linux-2.5.x/drivers/pnp/resource.c Tue May 27 19:03:04 2003
> > +++ linux-m68k-2.5.x/drivers/pnp/resource.c Sun Jun 8 13:31:20 2003
> > @@ -97,7 +97,9 @@
> >
> > int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
> > {
> > +#ifdef CONFIG_PCI
> > int i;
> > +#endif
>
> This is far uglier than te warning
It depends on your goals. These warnings distract us from the real harmful
warnings. Will we ever have a kernel that compiles with -Werror?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert Uytterhoeven <[email protected]> writes:
> On 21 Jun 2003, Alan Cox wrote:
>> On Sul, 2003-06-15 at 19:36, Geert Uytterhoeven wrote:
>> > Isapnp: Kill warning if CONFIG_PCI is not set
>> >
>> > --- linux-2.5.x/drivers/pnp/resource.c Tue May 27 19:03:04 2003
>> > +++ linux-m68k-2.5.x/drivers/pnp/resource.c Sun Jun 8 13:31:20 2003
>> > @@ -97,7 +97,9 @@
>> >
>> > int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
>> > {
>> > +#ifdef CONFIG_PCI
>> > int i;
>> > +#endif
>>
>> This is far uglier than te warning
>
> It depends on your goals. These warnings distract us from the real harmful
> warnings. Will we ever have a kernel that compiles with -Werror?
Unless GCC never emits an invalid warning, no.
Geert Uytterhoeven <[email protected]> wrote:
>
> > > int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
> > > {
> > > +#ifdef CONFIG_PCI
> > > int i;
> > > +#endif
> >
> > This is far uglier than te warning
>
> It depends on your goals. These warnings distract us from the real harmful
> warnings. Will we ever have a kernel that compiles with -Werror?
It would be nice. But as soon as we do that, some gcc guy will have a
brainfart and we'll get a whole new batch of warnings which we cannot turn
off. Again. I've been involved in projects where it was unacceptable to
upgrade the gcc version for this sole reason.
Meanwhile, let's do this:
diff -puN drivers/pnp/resource.c~misc6 drivers/pnp/resource.c
--- 25/drivers/pnp/resource.c~misc6 2003-06-21 12:47:23.000000000 -0700
+++ 25-akpm/drivers/pnp/resource.c 2003-06-21 12:47:44.000000000 -0700
@@ -97,7 +97,6 @@ int pnp_get_max_depnum(struct pnp_dev *d
int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
{
- int i;
struct pnp_resources *res;
struct pnp_irq *ptr;
res = pnp_find_resources(dev,depnum);
@@ -113,9 +112,13 @@ int pnp_add_irq_resource(struct pnp_dev
else
res->irq = data;
#ifdef CONFIG_PCI
- for (i=0; i<16; i++)
- if (data->map & (1<<i))
- pcibios_penalize_isa_irq(i);
+ {
+ int i;
+
+ for (i=0; i<16; i++)
+ if (data->map & (1<<i))
+ pcibios_penalize_isa_irq(i);
+ }
#endif
return 0;
}
_
On Sat, 21 Jun 2003, Andrew Morton wrote:
>
> Meanwhile, let's do this:
I'd prefer the C99 thing, ie
for (int i = xxx ...)
syntax. I know gcc-3.x supports it, maybe 2.96 does too? If so, we could
just add "-std=c99" or whatever, and start using that.
Linus
Em Sat, Jun 21, 2003 at 04:53:32PM -0700, Linus Torvalds escreveu:
>
> On Sat, 21 Jun 2003, Andrew Morton wrote:
> >
> > Meanwhile, let's do this:
>
> I'd prefer the C99 thing, ie
>
> for (int i = xxx ...)
>
> syntax. I know gcc-3.x supports it, maybe 2.96 does too? If so, we could
> just add "-std=c99" or whatever, and start using that.
Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good stuff
like this one, anonymous structs, etc, etc, lots of stuff could be done in
an easier way, but are we ready to abandon gcc 2.95.*? Can anyone confirm
if gcc 2.96 accepts this?
- Arnaldo
On Sat, Jun 21, 2003 at 09:11:01PM -0300, Arnaldo Carvalho de Melo wrote:
> Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good
> stuff like this one, anonymous structs, etc, etc, lots of stuff
> could be done in an easier way, but are we ready to abandon gcc
> 2.95.*? Can anyone confirm if gcc 2.96 accepts this?
What *requires* 2.96 still? Is it a large number of people or obscure
architecture?
--cw
Em Sat, Jun 21, 2003 at 08:41:02PM -0500, Chris Wedgwood escreveu:
> On Sat, Jun 21, 2003 at 09:11:01PM -0300, Arnaldo Carvalho de Melo wrote:
>
> > Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good
> > stuff like this one, anonymous structs, etc, etc, lots of stuff
> > could be done in an easier way, but are we ready to abandon gcc
> > 2.95.*? Can anyone confirm if gcc 2.96 accepts this?
>
> What *requires* 2.96 still? Is it a large number of people or obscure
> architecture?
I don't know, I was just trying to figure out the impact of requiring gcc 3
to compile the kernel. I never used gcc 2.96 btw.
- Arnaldo
Arnaldo Carvalho de Melo <[email protected]> wrote:
>
> Em Sat, Jun 21, 2003 at 08:41:02PM -0500, Chris Wedgwood escreveu:
> > On Sat, Jun 21, 2003 at 09:11:01PM -0300, Arnaldo Carvalho de Melo wrote:
> >
> > > Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good
> > > stuff like this one, anonymous structs, etc, etc, lots of stuff
> > > could be done in an easier way, but are we ready to abandon gcc
> > > 2.95.*? Can anyone confirm if gcc 2.96 accepts this?
> >
> > What *requires* 2.96 still? Is it a large number of people or obscure
> > architecture?
>
> I don't know, I was just trying to figure out the impact of requiring gcc 3
> to compile the kernel. I never used gcc 2.96 btw.
>
Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
kernel which is 200k larger.
It is simply worthless.
On Sat, Jun 21, 2003 at 07:17:05PM -0700, Andrew Morton wrote:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and
> produces a kernel which is 200k larger.
Do we know why this is the case? I assume the fix is far from
trivial?
> It is simply worthless.
I stopped using 2.95.x recently because of miscompiles. Even vendor
compilers seemed to break at times :(
--cw
Chris Wedgwood <[email protected]> wrote:
>
> On Sat, Jun 21, 2003 at 07:17:05PM -0700, Andrew Morton wrote:
>
> > Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and
> > produces a kernel which is 200k larger.
>
> Do we know why this is the case? I assume the fix is far from
> trivial?
Alignment mainly. It pads stuff all over the place. A lot of it can be
defeated - but not all, last time I looked.
--Andrew Morton <[email protected]> wrote (on Saturday, June 21, 2003 19:17:05 -0700):
> Arnaldo Carvalho de Melo <[email protected]> wrote:
>>
>> Em Sat, Jun 21, 2003 at 08:41:02PM -0500, Chris Wedgwood escreveu:
>> > On Sat, Jun 21, 2003 at 09:11:01PM -0300, Arnaldo Carvalho de Melo wrote:
>> >
>> > > Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good
>> > > stuff like this one, anonymous structs, etc, etc, lots of stuff
>> > > could be done in an easier way, but are we ready to abandon gcc
>> > > 2.95.*? Can anyone confirm if gcc 2.96 accepts this?
>> >
>> > What *requires* 2.96 still? Is it a large number of people or obscure
>> > architecture?
>>
>> I don't know, I was just trying to figure out the impact of requiring gcc 3
>> to compile the kernel. I never used gcc 2.96 btw.
>>
>
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
>
> It is simply worthless.
Agreed. 2.95.4 is also still the default debian compiler. Requiring
3.x seems like a bad plan, until they get it to a point where it's
actually better than 2.95, stable, and widely distributed. It's
definitely not there yet (seems kind of stable, but not the others).
M.
Andrew Morton writes:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
I just tried it on PPC. Compared to 2.95.4, gcc-3.3 took 36% longer
to compile and produced a kernel which was 120k smaller.
Paul.
On Sat, Jun 21, 2003 at 07:17:05PM -0700, Andrew Morton wrote:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
>
> It is simply worthless.
gcc 2.95.3 does compile faster than 3.3, but I don't think 3.3 is simply
worthless:
[barryn gcc-size-test]$ ls -l
total 23272
-rw-r--r-- 1 barryn barryn 820727 Jun 21 21:49 bzImage.egcs-O2
-rw-r--r-- 1 barryn barryn 808348 Jun 21 21:47 bzImage.egcs-Os
-rw-r--r-- 1 barryn barryn 783636 Jun 21 21:09 bzImage.gcc2953-O2
-rw-r--r-- 1 barryn barryn 774024 Jun 21 21:02 bzImage.gcc2953-Os
-rw-rw-r-- 1 barryn barryn 822046 Jun 21 21:35 bzImage.gcc296-O2
-rw-rw-r-- 1 barryn barryn 783735 Jun 21 21:36 bzImage.gcc296-Os
-rw-r--r-- 1 barryn barryn 841195 Jun 21 21:10 bzImage.gcc33-O2
-rw-r--r-- 1 barryn barryn 752662 Jun 21 21:02 bzImage.gcc33-Os
-rwxr-xr-x 1 barryn barryn 2212335 Jun 21 21:49 vmlinux.egcs-O2*
-rwxr-xr-x 1 barryn barryn 2204143 Jun 21 21:47 vmlinux.egcs-Os*
-rwxr-xr-x 1 barryn barryn 2168795 Jun 21 21:10 vmlinux.gcc2953-O2*
-rwxr-xr-x 1 barryn barryn 2156483 Jun 21 21:01 vmlinux.gcc2953-Os*
-rwxrwxr-x 1 barryn barryn 2202351 Jun 21 21:36 vmlinux.gcc296-O2*
-rwxrwxr-x 1 barryn barryn 2145007 Jun 21 21:36 vmlinux.gcc296-Os*
-rwxr-xr-x 1 barryn barryn 2249099 Jun 21 21:10 vmlinux.gcc33-O2*
-rwxr-xr-x 1 barryn barryn 2068791 Jun 21 21:01 vmlinux.gcc33-Os*
[barryn gcc-size-test]$ size vmlinux.*
text data bss dec hex filename
1420101 282484 170084 1872669 1c931d vmlinux.egcs-O2
1410846 282484 170084 1863414 1c6ef6 vmlinux.egcs-Os
1380645 285204 166948 1832797 1bf75d vmlinux.gcc2953-O2
1366775 285204 166948 1818927 1bc12f vmlinux.gcc2953-Os
1409086 285360 161084 1855530 1c502a vmlinux.gcc296-O2
1350206 285360 161084 1796650 1b6a2a vmlinux.gcc296-Os
1458614 286608 161772 1906994 1d1932 vmlinux.gcc33-O2
1280355 286608 161772 1728735 1a60df vmlinux.gcc33-Os
This is kernel 2.4.21-ac1, with the .config at the end of this message.
egcs is plain egcs 2.91.66, gcc 2.95.3 is plain gcc 2.95.3, gcc 2.96 is
gcc-2.96-118.7.2, and gcc 3.3 is gcc-3.3-1mdk.
gcc 3.3 produces both the largest and the smallest kernels. It just
depends on your compile options. :)
I probably have more important things to do, but, *maybe* I'll be able
to find the time and energy to run some benchmarks and see what's
fastest. Does anyone have any suggestions or recommendations?
-Barry K. Nathan <[email protected]>
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_HAS_TSC=y
CONFIG_X86_PPRO_FENCE=y
# CONFIG_X86_F00F_WORKS_OK is not set
CONFIG_X86_MCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_HIGHMEM is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_UP_IOAPIC is not set
# CONFIG_X86_TSC_DISABLE is not set
CONFIG_X86_TSC=y
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PM is not set
# CONFIG_ACPI is not set
# CONFIG_APM is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# 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_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP 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
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK 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
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=2
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=7
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=7
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI 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
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# 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_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
# CONFIG_ELMC is not set
# CONFIG_ELMC_II is not set
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# 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
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI 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
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
#
# Input core support is needed for gameports
#
#
# Input core support is needed for joysticks
#
# 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
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_RNG is not set
# CONFIG_INTEL_RNG 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
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA 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_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_UMSDOS_FS=y
CONFIG_VFAT_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
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=y
# 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 is not set
# CONFIG_DEVFS_MOUNT is not set
# 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=y
# 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
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# 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_LOCKD_V4=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
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_FRAME_POINTER is not set
#
# PaX options
#
CONFIG_PAX_NOEXEC=y
# CONFIG_PAX_PAGEEXEC is not set
CONFIG_PAX_SEGMEXEC=y
CONFIG_PAX_EMUTRAMP=y
# CONFIG_PAX_EMUSIGRT is not set
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_RANDEXEC=y
#
# Library routines
#
# CONFIG_ZLIB_INFLATE is not set
# CONFIG_ZLIB_DEFLATE is not set
Andrew Morton <[email protected]> wrote:
>
> Alignment mainly. It pads stuff all over the place. A lot of it can be
> defeated - but not all, last time I looked.
And if you're compiling for i386, the main increase comes from
out-of-line branches.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, 22 Jun 2003, Paul Mackerras wrote:
> Andrew Morton writes:
> > Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> > kernel which is 200k larger.
>
> I just tried it on PPC. Compared to 2.95.4, gcc-3.3 took 36% longer
> to compile and produced a kernel which was 120k smaller.
I have the same experience w.r.t. kernel size on MIPS, using 2.95.4 from Debian
woody on the target, and 3.2.2 for cross-compiling.
Perhaps the code increase is for CISC only?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sat, 21 June 2003 20:41:02 -0500, Chris Wedgwood wrote:
> On Sat, Jun 21, 2003 at 09:11:01PM -0300, Arnaldo Carvalho de Melo wrote:
>
> > Humm, I'd love to do that, i.e. to make gcc 3 required, lots of good
> > stuff like this one, anonymous structs, etc, etc, lots of stuff
> > could be done in an easier way, but are we ready to abandon gcc
> > 2.95.*? Can anyone confirm if gcc 2.96 accepts this?
>
> What *requires* 2.96 still? Is it a large number of people or obscure
> architecture?
Try these two litter things in Assembler code:
#define LONG_MACRO \
asm \
#ifdef something \
asm \
#else \
asm \
asm \
#endif \
asm
Compiles just fine with all 3.x I've tried.
jump 92f
...
81: ...
...
92 ...
Again, compiles just fine.
Both are clearly wrong and should not be in the source code. But
Assembler bugs are subtle, nasty and Code Checkers for Assembler are
rare. My vote is to keep 2.95+ support.
J?rn
--
"Error protection by error detection and correction."
-- from a university class
On Sat, Jun 21, 2003 at 10:43:45PM -0300, Arnaldo Carvalho de Melo wrote:
> I don't know, I was just trying to figure out the impact of requiring gcc 3
> to compile the kernel. I never used gcc 2.96 btw.
So, for ARM, we end up with the following gcc versions which appear to
work:
- gcc 2.95.3 + patch
- gcc 2.95.4
- gcc 3.2.2 + patch
- gcc 3.2.3 + patch
- gcc 3.3
(Some of the gcc people may beg to differ, but the above list results
from many reports and real life experiences from several people.)
>From what I understand, the gcc people are not all that happy about
the gcc 3.2.x patch, based upon the fact that it has not been applied.
It is also possible that gcc 3.3 happens to work because the bug got
hidden by other changes, or, the real bug did get fixed. No one seems
to know. Certainly the bugzilla entry remains open and unresolved.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sul, 2003-06-22 at 06:39, Barry K. Nathan wrote:
> On Sat, Jun 21, 2003 at 07:17:05PM -0700, Andrew Morton wrote:
> > Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> > kernel which is 200k larger.
> >
> > It is simply worthless.
>
> gcc 2.95.3 does compile faster than 3.3, but I don't think 3.3 is simply
> worthless:
With 2.95 people did benchmarks a long time back and -Os was outperforming
-O2 on some platforms at least. I'd bet the same is true with 3.3 on a
celeron too
Hi Andrew,
On Sunday 22 June 2003 04:17, you wrote:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
>
> It is simply worthless.
Recently, we did an unscientific but nonetheless informative tour through
various optimization and compiler version questions here:
http://marc.theaimsgroup.com/?t=105167074500002&r=3&w=2
[RFC][PATCH] Faster generic_fls
As a result, my general impression is GCC 3.2 (and, I presume, GCC 3.3 as
well) comes out better than 2.95.3 in terms of binary performance on x86. I
seem to recall there was one case in one algorithm variation on one procesor
type where 2.95.3 won marginally, and otherwise GCC 3.2 took the trophy every
time, sometimes by a significant margin. I was able to get satisfactory
performance in terms of size as well, by tweaking compile options. (In
general, just mindlessly setting O3 seems to work well.)
So I like GCC 3.2 in terms of code quality, at least for the limited set of
things I've tested, but that's not the only consideration. Current GCC is a
whole lot better in terms of C99 compliance and produces better warnings.
As for compilation speed, yes, that sucks. I doubt there's any rational
reason for it, but I also agree with the idea that correctness and binary
code performance should come first, then the compilation speed issue should
be addressed. I hope the gcc team does make it a priority at some point.
For my own part, I'm putting together a cluster to address the compilation
speed issue, i.e., I don't really care about it. Even a dual PIII turns in
satisfactory results in that regard, or a single K7.
Regards,
Daniel
On Sunday 22 June 2003 10:32, Geert Uytterhoeven wrote:
> On Sun, 22 Jun 2003, Paul Mackerras wrote:
> > Andrew Morton writes:
> > > Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces
> > > a kernel which is 200k larger.
> >
> > I just tried it on PPC. Compared to 2.95.4, gcc-3.3 took 36% longer
> > to compile and produced a kernel which was 120k smaller.
>
> I have the same experience w.r.t. kernel size on MIPS, using 2.95.4 from
> Debian woody on the target, and 3.2.2 for cross-compiling.
>
> Perhaps the code increase is for CISC only?
In another branch of this thread Andrew said it's due to extra alignment
padding (presumably with a view to improving execution speed) and Herbert Xu
mentioned out-of-line conditional branch compilation, both of which sould
reasonable to me. They also sound like they could or should be trivially
switchable.
Regards,
Daniel
Hi Alan,
On Saturday 21 June 2003 14:31, Alan Cox wrote:
> On Sul, 2003-06-15 at 19:36, Geert Uytterhoeven wrote:
> > Isapnp: Kill warning if CONFIG_PCI is not set
> >
> > --- linux-2.5.x/drivers/pnp/resource.c Tue May 27 19:03:04 2003
> > +++ linux-m68k-2.5.x/drivers/pnp/resource.c Sun Jun 8 13:31:20 2003
> > @@ -97,7 +97,9 @@
> >
> > int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
> > {
> > +#ifdef CONFIG_PCI
> > int i;
> > +#endif
>
> This is far uglier than te warning
How about:
#define if_pci(tokens...) tokens
int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
{
if_pci(int i);
...
}
Admittedly uglier than just having the warning disabled by default.
Regards,
Daniel
On Sun, 2003-06-22 16:07:14 +0200, Daniel Phillips <[email protected]>
wrote in message <[email protected]>:
> Hi Alan,
>
> On Saturday 21 June 2003 14:31, Alan Cox wrote:
> > On Sul, 2003-06-15 at 19:36, Geert Uytterhoeven wrote:
>
> How about:
>
> #define if_pci(tokens...) tokens
>
> int pnp_add_irq_resource(struct pnp_dev *dev, int depnum, struct pnp_irq *data)
> {
> if_pci(int i);
> ...
> }
>
> Admittedly uglier than just having the warning disabled by default.
Even whilest I don't like defining variables where I need them (at an
opening "{" or like in "for (int i, i < x, i++)" as Linus suggested it),
this is quite ugly, too. "if_pci(int i)" looks linke an uglyfied
function call, and even while being ugly, it should basically "work"
like a function call. Here, it doesn't, so I consider this a Bad Thing.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
Daniel Phillips <[email protected]> wrote:
>
> As for compilation speed, yes, that sucks. I doubt there's any rational
> reason for it, but I also agree with the idea that correctness and binary
> code performance should come first, then the compilation speed issue should
> be addressed.
No. Compilation inefficiency directly harms programmer efficiency and the
quality and volume of code the programmer produces. These are surely the
most important things by which a toolchain's usefulness should be judged.
I compile with -O1 all the time and couldn't care the teeniest little bit
about the performance of the generated code - it just doesn't matter.
I'm happy allowing those thousands of people who do not compile kernels all
the time to shake out any 3.2/3.3 compilation problems.
Compilation inefficiency is the most serious thing wrong with gcc.
On Sun, 22 Jun 2003, Andrew Morton wrote:
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
Well, sometimes it _does_ matter from a correctness standpoint. For
example, gcc without optimizations was simply unusable, because of the
lack of inlining or the lack of even trivial optimizations (ie static dead
code removal).
And a (unrelated) gcc list thread showed that even with just -O1, one
particular project had gone from 131 seconds (gcc-2.7.2) to 180 seconds
(2.95.3) to 282 seconds (3.3) to 327 seconds (the tree-ssa branch).
Linus
> No. Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces. These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
>
> I'm happy allowing those thousands of people who do not compile kernels all
> the time to shake out any 3.2/3.3 compilation problems.
>
>
> Compilation inefficiency is the most serious thing wrong with gcc.
Code for hardware that almost nobody has anymore isn't easily tested
for subtle compilation errors.
The math emulation code didn't even compile for a while, and that went
unnoticed. IFF there are substantial benefits to dropping 2.95.3
should we risk drivers for things like obscure SCSI cards being
mis-compiled and randomly corrupting data.
There _must_ be hardware that nobody has tested a gcc 3 compiled
kernel on.
All 2.5.X trees, and most 2.4.x trees have had a _lot_ of testing with
GCC 2.95.3, in a lot of different environments. Especially in the
case of 2.4.X, a lot of that code hasn't seen significant changes in
the last year or so, and those code paths have been shown to be very
stable with gcc 2.95.3.
Eliminating gcc 2.95.3 support when a lot of people are still using
it, and having a large number of users migrate to gcc 3.3 could
uncover subtle compiler bugs a month or two later, and we'd end up
having to either live with that, or add support for gcc 2.95.3 back
in.
John.
Andrew Morton <[email protected]> writes:
Your problem is not the compiler but the build tool / system which
forces you to recompile all of your kernel if you change only small
parts.
Regards
Henning
>Daniel Phillips <[email protected]> wrote:
>>
>> As for compilation speed, yes, that sucks. I doubt there's any rational
>> reason for it, but I also agree with the idea that correctness and binary
>> code performance should come first, then the compilation speed issue should
>> be addressed.
>No. Compilation inefficiency directly harms programmer efficiency and the
>quality and volume of code the programmer produces. These are surely the
>most important things by which a toolchain's usefulness should be judged.
>I compile with -O1 all the time and couldn't care the teeniest little bit
>about the performance of the generated code - it just doesn't matter.
>I'm happy allowing those thousands of people who do not compile kernels all
>the time to shake out any 3.2/3.3 compilation problems.
>Compilation inefficiency is the most serious thing wrong with gcc.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[email protected] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "Never argue with an idiot. They drag you down
to their level, then beat you with experience." ---
"Henning P. Schmiedehausen" <[email protected]> wrote:
>
> Your problem is not the compiler but the build tool / system which
> forces you to recompile all of your kernel if you change only small
> parts.
No, the build system is OK. And ccache nicely fixes up any mistakes which
the build system makes, and distcc speeds things up by 2x to 3x.
None of that gets around the fact that code needs to be tested with various
combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
spinlock debugging, etc, etc. If the compiler is slow people don't bother
doing this and the code breaks.
Cause and effect.
On Sun, Jun 22, 2003 at 06:58:04PM +0000, Henning P. Schmiedehausen wrote:
> Andrew Morton <[email protected]> writes:
>
> Your problem is not the compiler but the build tool / system which
> forces you to recompile all of your kernel if you change only small
> parts.
If you know of any cases where too much is build after a change in
the 2.5 kernel I would like to know that.
In the above keep in mind that the finest granularity is on a file basis,
except for .config, where it is on a config entry granularity.
Sam
On Sunday 22 June 2003 19:32, Andrew Morton wrote:
> Daniel Phillips <[email protected]> wrote:
> > As for compilation speed, yes, that sucks. I doubt there's any rational
> > reason for it, but I also agree with the idea that correctness and
> > binary code performance should come first, then the compilation speed
> > issue should be addressed.
>
> No. Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces. These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
True, and then gdb works much better as well. I was really thinking about
production quality. Well, I want to have it all, I wonder if the gcc crew
could come up with a compile speed optimization switch, which produces sucky
code but does it in record time.
There are many other ways of improving kernel build speed of course. One of
the best was to use Keith Owen's kbuild 2.5, which did an impressive job of
speeding the build up, especially the incremental stuff that matters most to
developers. But alas, it died on the horns of politics.
> Compilation inefficiency is the most serious thing wrong with gcc.
If that's the case then it's a good sign I think.
Regards,
Daniel
Hi,
well to me that sounds like a perfect job for a continous build tool. If
a human must wait on this, then yes, you're right.
Regards
Henning
On Sun, 2003-06-22 at 21:13, Andrew Morton wrote:
> "Henning P. Schmiedehausen" <[email protected]> wrote:
> >
> > Your problem is not the compiler but the build tool / system which
> > forces you to recompile all of your kernel if you change only small
> > parts.
>
> No, the build system is OK. And ccache nicely fixes up any mistakes which
> the build system makes, and distcc speeds things up by 2x to 3x.
>
> None of that gets around the fact that code needs to be tested with various
> combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
> spinlock debugging, etc, etc. If the compiler is slow people don't bother
> doing this and the code breaks.
>
> Cause and effect.
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Sun, Jun 22, 2003 at 06:58:04PM +0000, Henning P. Schmiedehausen wrote:
> Andrew Morton <[email protected]> writes:
>
> Your problem is not the compiler but the build tool / system which
> forces you to recompile all of your kernel if you change only small
> parts.
That's not true in 2.5, the 2.5 build system only recompiles files that
have to be recompiled.
But if you edit an often used header file many fils have to be
recompiled.
> Regards
> Henning
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
> No, the build system is OK. And ccache nicely fixes up any mistakes which
> the build system makes, and distcc speeds things up by 2x to 3x.
>
> None of that gets around the fact that code needs to be tested with various
> combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
> spinlock debugging, etc, etc. If the compiler is slow people don't bother
> doing this and the code breaks.
>
> Cause and effect.
Are the benchmarks that show gcc 3.3 to be much slower at compile time
being done with a natively compiled gcc 3.3? I.E. gcc 3.3 compiled
with itself?
When I upgraded a few machines from 2.95.3 to 3.2.3, I noticed that
the last of the three compiles, (I.E. a gcc-3.2.3 compiled gcc-3.2.3
compiling the gcc-3.2.3 source), was noticably quicker than the first
two, to the extent that it was easily mesaurable by a wall clock.
I am just wondering whether there gcc-3.X binaries in use that were
compiled with gcc-2.95.3, that are swaying benchmarks in favour of
2.95.3 compiled with itself.
I haven't benchmarked gcc-2.95.3 compiled with gcc-3.2.3, though.
John.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 22 June 2003 22:07, John Bradford wrote:
> > No, the build system is OK. And ccache nicely fixes up any mistakes
> > which the build system makes, and distcc speeds things up by 2x to 3x.
> >
> > None of that gets around the fact that code needs to be tested with
> > various combinations of CONFIG_SMP, CONFIG_PREEMPT, different
> > subarchitectures, spinlock debugging, etc, etc. If the compiler is slow
> > people don't bother doing this and the code breaks.
> >
> > Cause and effect.
>
> Are the benchmarks that show gcc 3.3 to be much slower at compile time
> being done with a natively compiled gcc 3.3? I.E. gcc 3.3 compiled
> with itself?
>
> When I upgraded a few machines from 2.95.3 to 3.2.3, I noticed that
> the last of the three compiles, (I.E. a gcc-3.2.3 compiled gcc-3.2.3
> compiling the gcc-3.2.3 source), was noticably quicker than the first
> two, to the extent that it was easily mesaurable by a wall clock.
>
> I am just wondering whether there gcc-3.X binaries in use that were
> compiled with gcc-2.95.3, that are swaying benchmarks in favour of
> 2.95.3 compiled with itself.
>
> I haven't benchmarked gcc-2.95.3 compiled with gcc-3.2.3, though.
The preferred build command for gcc is
$ make bootstrap
AFAIK that compiles the compiler in three stages.
stage1 => normal with currently installed compiler
stage2 => with stage1 compiler
stage3 => I don't know. Either with stage1 or stage2.
So if you built it with bootstrap it's impossible to have
bad or good performance, just because it was built this
this or that compiler.
Please correct me if I'm wrong. :)
> John.
- --
Regards Michael B?sch
http://www.8ung.at/tuxsoft
22:23:42 up 1:25, 1 user, load average: 1.01, 1.02, 0.97
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+9hEfoxoigfggmSgRAgMSAJ9VI4qcNZZSrvvNv+yAsAehBPAc8wCeJmc2
7C5KMOzhgBYO3ccFSO9oikA=
=UHkb
-----END PGP SIGNATURE-----
If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
faster than the later versions. I used to yank newer versions of gcc
off systems and put 2.7.2 on, I think it was close to 2x faster at
compilation and made no difference on BK performance.
On Sun, Jun 22, 2003 at 10:32:51AM -0700, Andrew Morton wrote:
> Daniel Phillips <[email protected]> wrote:
> >
> > As for compilation speed, yes, that sucks. I doubt there's any rational
> > reason for it, but I also agree with the idea that correctness and binary
> > code performance should come first, then the compilation speed issue should
> > be addressed.
>
> No. Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces. These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
>
> I'm happy allowing those thousands of people who do not compile kernels all
> the time to shake out any 3.2/3.3 compilation problems.
>
>
> Compilation inefficiency is the most serious thing wrong with gcc.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
> faster than the later versions. I used to yank newer versions of gcc
> off systems and put 2.7.2 on, I think it was close to 2x faster at
> compilation and made no difference on BK performance.
Out of interest, have you tried compiling BK with tcc?
John.
On Mon, Jun 23, 2003 at 08:40:52AM +0100, John Bradford wrote:
> > If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
> > faster than the later versions. I used to yank newer versions of gcc
> > off systems and put 2.7.2 on, I think it was close to 2x faster at
> > compilation and made no difference on BK performance.
>
> Out of interest, have you tried compiling BK with tcc?
Nope. I can if you want but I'll bet it doesn't support all our platforms.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi!
> If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
> faster than the later versions. I used to yank newer versions of gcc
> off systems and put 2.7.2 on, I think it was close to 2x faster at
> compilation and made no difference on BK performance.
Perhaps someone schould create 2.7.3 with long long bugs fixed
and with c99 initializers?
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
On Fri, Jan 04, 2002 at 12:32:05PM +0100, Pavel Machek wrote:
> Perhaps someone schould create 2.7.3 with long long bugs fixed
> and with c99 initializers?
2.7 does have C99 initializers.
On Thu, Jul 17, 2003 at 11:18:05AM +0100, Christoph Hellwig wrote:
> On Fri, Jan 04, 2002 at 12:32:05PM +0100, Pavel Machek wrote:
> > Perhaps someone schould create 2.7.3 with long long bugs fixed
> > and with c99 initializers?
>
> 2.7 does have C99 initializers.
No, neither egcs 1.1.x nor gcc 2.95*.
They handle some C99 initializers, but definitely not what the
standard mandates.
Jakub
On Thu, Jul 17, 2003 at 06:23:50AM -0400, Jakub Jelinek wrote:
> They handle some C99 initializers, but definitely not what the
> standard mandates.
Umm, it does handle the common case of C99 struct initializers used
in the kernel. It might not handle some cases that aren't used by
the kernel which make you right from the language lawyer perspective
but which is rather irrelevant for this discussion.