LinuxLists.cc - Linux 2.5.70

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 10:48:29AM +0200, DevilKin wrote:
> include/linux/mmzone.h:18:1: warning: this is the location of the previous
> definition
> arch/i386/kernel/numaq.c: In function `initialize_physnode_map':
> arch/i386/kernel/numaq.c:95: error: `physnode_map' undeclared (first use in
> this function)
> arch/i386/kernel/numaq.c:95: error: (Each undeclared identifier is reported
> only once
> arch/i386/kernel/numaq.c:95: error: for each function it appears in.)
> make[2]: *** [arch/i386/kernel/numaq.o] Error 1
> make[1]: *** [arch/i386/kernel] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.5.70'
> make: *** [stamp-build] Error 2

I suspect you're attempting to shoot yourself in the foot. .config?

-- wli

2003-05-27 15:17:47

by DevilKin

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
> I suspect you're attempting to shoot yourself in the foot. .config?

Ah, quite. I saw NUMA was activated, and disabling it fixed my problem. Odd
though, that it should become active just by doing a 'make oldconfig' with my
2.7.69 config file...

Anywayz, it works, this kernel solves all my outstanding issues sofar (being
mostly with the irda) so I'm happy :P

Jan
--
You look like a million dollars. All green and wrinkled.

2003-05-27 15:23:17

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>> I suspect you're attempting to shoot yourself in the foot. .config?

On Tue, May 27, 2003 at 05:29:48PM +0200, DevilKin-LKML wrote:
> Ah, quite. I saw NUMA was activated, and disabling it fixed my problem. Odd
> though, that it should become active just by doing a 'make oldconfig' with my
> 2.7.69 config file...
> Anywayz, it works, this kernel solves all my outstanding issues sofar (being
> mostly with the irda) so I'm happy :P

It should be even more obscure than that; CONFIG_X86_NUMAQ is basically
"you had _better_ have this machine and you had _better_ know what you're
doing even if you have one".

At any rate, one of us will look at making the option at least harder to
accidentally turn on.

-- wli

2003-05-27 15:25:08

by Sean Neakums

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

DevilKin-LKML <[email protected]> writes:

> On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>> I suspect you're attempting to shoot yourself in the foot. .config?
>
> Ah, quite. I saw NUMA was activated, and disabling it fixed my
> problem. Odd though, that it should become active just by doing a
> 'make oldconfig' with my 2.7.69 config file...

I guess in the future, all boxes are NUMA.

--
Sean Neakums - <[email protected]>

2003-05-27 15:36:04

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

William> It should be even more obscure than that; CONFIG_X86_NUMAQ is
William> basically "you had _better_ have this machine and you had
William> _better_ know what you're doing even if you have one".

William> At any rate, one of us will look at making the option at
William> least harder to accidentally turn on.

I ran into this as well, since the 2.5.69-70 config entry is *really*
unclear on what you need to enter there, it's not in the standard
Y/N/M format for options. For example:

Kernel module loader (KMOD) [Y/n/?] y
*
* Processor type and features
*
Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW)

What the hell am I supposed to enter here? This is just friggin ugly
and un-readable. It should be cleaned up. Or is it just that the
help entry is appended to the question improperly here? That's sorta
what it looks like peering at it with my head turned to the left all
the way.

Are these choices all mutually exclusive? Or can you build a kernel
which will run on all these machines? Now that would be interesting
for a distro to have... not. *grin*

John

2003-05-27 15:39:59

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
> Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW)
> What the hell am I supposed to enter here? This is just friggin ugly
> and un-readable. It should be cleaned up. Or is it just that the
> help entry is appended to the question improperly here? That's sorta
> what it looks like peering at it with my head turned to the left all
> the way.

If you don't know, then just hit "enter".

On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
> Are these choices all mutually exclusive? Or can you build a kernel
> which will run on all these machines? Now that would be interesting
> for a distro to have... not. *grin*

Yes, they're mutually exclusive. You can't build one that will run on
all those machines because the programming isn't done right for that.
But the generic architecture option will run on at least 3.

-- wli

2003-05-27 15:39:17

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> DevilKin-LKML <[email protected]> writes:
>
>> On Tuesday 27 May 2003 15:05, William Lee Irwin III wrote:
>>> I suspect you're attempting to shoot yourself in the foot. .config?
>>
>> Ah, quite. I saw NUMA was activated, and disabling it fixed my
>> problem. Odd though, that it should become active just by doing a
>> 'make oldconfig' with my 2.7.69 config file...
>
> I guess in the future, all boxes are NUMA.

However, in the future, all boxes are also not i386, so we're OK still ;-)

M.

2003-05-27 16:23:21

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

>>>>> "William" == William Lee Irwin <[email protected]> writes:

William> On Tue, May 27, 2003 at 11:48:56AM -0400, John Stoffel wrote:
>> Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW)
>> What the hell am I supposed to enter here? This is just friggin ugly
>> and un-readable. It should be cleaned up. Or is it just that the
>> help entry is appended to the question improperly here? That's sorta
>> what it looks like peering at it with my head turned to the left all
>> the way.

William> If you don't know, then just hit "enter".

Sure, I understand that, but what I'm really complaining about is the
text of the prompt. When I do a 'make menuconfig' it's alot cleaner
and more understandable what's happening here.

Part of the problem is the specification in arch/i386/Kconfig, which I
think needs to be re-worked.

In my case, I specified that the max number of CPUS is 2, since I only
have a dual CPU box. So it's not a BIGCPU box. Not sure how to make
this change... I'll have to find some time and play with this.

William> Yes, they're mutually exclusive. You can't build one that
William> will run on all those machines because the programming isn't
William> done right for that. But the generic architecture option
William> will run on at least 3.

I see that when I dod the menuconfig, it's not clear at all when
running oldconfig.

John

2003-05-27 16:29:58

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

"William" == William Lee Irwin <[email protected]> writes:
William> If you don't know, then just hit "enter".

On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
> Sure, I understand that, but what I'm really complaining about is the
> text of the prompt. When I do a 'make menuconfig' it's alot cleaner
> and more understandable what's happening here.
> Part of the problem is the specification in arch/i386/Kconfig, which I
> think needs to be re-worked.
> In my case, I specified that the max number of CPUS is 2, since I only
> have a dual CPU box. So it's not a BIGCPU box. Not sure how to make
> this change... I'll have to find some time and play with this.

CONFIG_NR_CPUS should appear under the processor type and features menu.
I fixed sparse physical APIC ID wakeup, so setting it to 2 should be
fine now. If the configurator is hiding it from you, please contact
Roman Zippel, and in the meantime vi .config and search for NR_CPUS and
set that to the desired value. AFAIK the option is visible, but I've
not got unusual configs.

"William" == William Lee Irwin <[email protected]> writes:
William> Yes, they're mutually exclusive. You can't build one that
William> will run on all those machines because the programming isn't
William> done right for that. But the generic architecture option
William> will run on at least 3.

On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
> I see that when I dod the menuconfig, it's not clear at all when
> running oldconfig.

make oldconfig is not meant for those in need of explanations. It's
barely meant to be interactive if at all. menuconfig might be a better
configuration method for you.

-- wli

2003-05-27 16:47:02

by Ricky Beam

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Mon, 26 May 2003, Linus Torvalds wrote:
>... to start the "pre-2.6" series ...

You're kidding, right? 2.5 is no where near ready to be called anything
like "2.6". With an actual code freeze -- as in fix the shit that's broken,
non-functional, and/or incompletely implemented without adding any more
stuff or rebuilding entire subsystems as opposed to the standard Linus
"code freeze" that's much like a slushy in the 9th level of Hell (assuming
it gets there, it doesn't last long and really does no go) -- 2.5 is about
a year away from having the current code base fully functional and on it's
way to stable.

Count up the number of drivers that haven't been updated to the current
PCI, hotplug, and modules interfaces.

Take a look at the number of arch's that haven't seen much testing (and
in many respects are thus broken)... does anyone have a functional 2.5.70
sparc64 kernel? I've built several but they're all too big to be booted
(i.e. over 3.5M, and yes, I've turned off everything possible.)

--Ricky

2003-05-27 17:14:02

by Linus Torvalds

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 27 May 2003, Ricky Beam wrote:
>
> Count up the number of drivers that haven't been updated to the current
> PCI, hotplug, and modules interfaces.

Tough. If people don't use them, they don't get supported. It's that easy.

The thing is, these things won't change before 2.6 (or at least a
pre-2.6). When 2.6.0 comes out, and somebody notices that they haven't
bothered to try the 2.5.x series, _then_ maybe some of those odd-ball
drivers get fixed.

Or not. Some of them may be literally due for retirement, with users just
running an old kernel on old hardware.

Btw, this is nothing new. It has _always_ been the case that a lot of
people didn't use the latest stable kernel until it was released, and then
they complained because the drivers they used weren't up to spec.

Linus

2003-05-27 17:33:50

by Alan

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Maw, 2003-05-27 at 18:26, Linus Torvalds wrote:
> On Tue, 27 May 2003, Ricky Beam wrote:
> >
> > Count up the number of drivers that haven't been updated to the current
> > PCI, hotplug, and modules interfaces.
>
> Tough. If people don't use them, they don't get supported. It's that easy.

Its also a lot easier to update them once the core stops changing! There
are some things I worry about - the bio splitting has to be resolved,
IDE raid can't happen until that occurs and I'm also waiting for the IDE
taskfile stuff/bio splitting bits to resolve so I can merge a load of
IDE updates to make things like SII IDE and newer HPT chips work in
2.5.x/2.6

Architectures are also normally just a sync up job and its again easier
to do once the core has stoppee changing.

2003-05-27 17:39:51

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

>>>>> "William" == William Lee Irwin <[email protected]> writes:

William> "William" == William Lee Irwin <[email protected]> writes:
William> If you don't know, then just hit "enter".

William> On Tue, May 27, 2003 at 12:35:38PM -0400, John Stoffel wrote:
>> Sure, I understand that, but what I'm really complaining about is the
>> text of the prompt. When I do a 'make menuconfig' it's alot cleaner
>> and more understandable what's happening here.
>> Part of the problem is the specification in arch/i386/Kconfig, which I
>> think needs to be re-worked.
>> In my case, I specified that the max number of CPUS is 2, since I only
>> have a dual CPU box. So it's not a BIGCPU box. Not sure how to make
>> this change... I'll have to find some time and play with this.

William> CONFIG_NR_CPUS should appear under the processor type and
William> features menu.

I must not have been clear enough in my rant, so let me rephrase it.

Because I had already configured NR_CPUS=2, I'm not sure that I should
have even gotten the choice of X86_BIGSMP at all, since it's obviously
not valid in this case.

I'm really asking for the configuration specifications and
dependencies to be cleaned up, and maybe I'll try to do it myself and
send in the patch. Right now I'm going to be trying 2.5.70-mm1 with a
patch for my ISA Cyclades board first.

So the real thrust of my posts before was:

The language and description used when running 'make oldconfig' and
trying to set the "X86_GENERICARCH" option is ugly and hard to
understand and doesn't match how it's shown in the 'make menuconfig'
settings.

Sure, I realize that oldconfig is more a helper than a real
interface, but it still has warts that I'd like to fix or have
someone else fix if I can't do it myself.

Maybe the entire issue is really how do you do specify and constrain
inputs properly in this setup?

John

2003-05-27 17:44:44

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

"William" == William Lee Irwin <[email protected]> writes:
William> CONFIG_NR_CPUS should appear under the processor type and
William> features menu.

On Tue, May 27, 2003 at 01:50:37PM -0400, John Stoffel wrote:
> I must not have been clear enough in my rant, so let me rephrase it.
> Because I had already configured NR_CPUS=2, I'm not sure that I should
> have even gotten the choice of X86_BIGSMP at all, since it's obviously
> not valid in this case.
> I'm really asking for the configuration specifications and
> dependencies to be cleaned up, and maybe I'll try to do it myself and
> send in the patch. Right now I'm going to be trying 2.5.70-mm1 with a
> patch for my ISA Cyclades board first.

They're meant to specify system types, in particular APIC configurations.

On Tue, May 27, 2003 at 01:50:37PM -0400, John Stoffel wrote:
> So the real thrust of my posts before was:
> The language and description used when running 'make oldconfig' and
> trying to set the "X86_GENERICARCH" option is ugly and hard to
> understand and doesn't match how it's shown in the 'make menuconfig'
> settings.
> Sure, I realize that oldconfig is more a helper than a real
> interface, but it still has warts that I'd like to fix or have
> someone else fix if I can't do it myself.
> Maybe the entire issue is really how do you do specify and constrain
> inputs properly in this setup?

No idea. Ask Roman Zippel.

My expectation is that we aren't going to make kernel configuration
safe for Aunt Tillie anytime in the near future.

-- wli

2003-05-27 17:42:22

by Linus Torvalds

[permalink] [raw]

Subject: Re: Linux 2.5.70

On 27 May 2003, Alan Cox wrote:
>
> Architectures are also normally just a sync up job and its again easier
> to do once the core has stoppee changing.

Indeed. I think its more the rule than the exception that non-x86
architectures "get with the program" sometime during the stable release
rather than before. There's just not a lot of incentive for the odd-ball
architectures to care before the fact.

Would I prefer to have everything fixed by 2.6.0 (or even the pre-2.6
kernels)? Sure, everybody would. But it's just a fact of life that we
won't see people who care about the issues before that happens.

In fact, judging by past performance, a lot of things won't get fixed
before the actual vendors have made _releases_ that use 2.6.x (and the
first ones inevitably will have 2.4.x as a fall-back: that's only prudent
and sane).

This is not just a core kernel issue - we've seen this with subsystems
like ext3 and ReiserFS: they were "finished' and "stable", but what made
them _really_ stable was a release or two on vendor kernels, and thousands
of users.

Linus

2003-05-27 18:00:38

by Ricky Beam

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 27 May 2003, Linus Torvalds wrote:
>On Tue, 27 May 2003, Ricky Beam wrote:
>>
>> Count up the number of drivers that haven't been updated to the current
>> PCI, hotplug, and modules interfaces.
>
>Tough. If people don't use them, they don't get supported. It's that easy.
...

Allow me to clarify... I don't mind drivers not working. I *do* mind
drivers emitting hundreds of warnings and errors because dozens of things
were changed and no one cared to update everything they broke. In some
cases, fixing things may be simple (eg. someone removed or renamed a field
in a struct somewhere) and in others years of work my be required (eg.
the new module interface.)

In my opinion (as it was in the long long ago), everything in a "stable"
release should at least compile cleanly -- "working" comes later after
users have been conned into using it.

--Ricky

2003-05-27 18:09:12

by Roman Zippel

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

Hi,

On Tue, 27 May 2003, John Stoffel wrote:

> *
> * Processor type and features
> *
> Subarchitecture Type (PC-compatible, Voyager (NCR), NUMAQ (IBM/Sequent), Summit/EXA (IBM x440), Support for other sub-arch SMP systems with more than 8 CPUs, SGI 320/540 (Visual Workstation), Generic architecture (Summit, bigsmp, default)) [PC-compatible] (NEW)
>
>
> What the hell am I supposed to enter here? This is just friggin ugly
> and un-readable. It should be cleaned up.

I agree and I already fixed this here, so with the next update this will
look like this:

Subarchitecture Type
> 1. PC-compatible (X86_PC)
2. Voyager (NCR) (X86_VOYAGER)
3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
4. Summit/EXA (IBM x440) (X86_SUMMIT)
5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
6. SGI 320/540 (Visual Workstation) (X86_VISWS)
7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
choice[1-7]:

This has other advantages too, one can see now which options were newly
added and the individual help texts are accessible.

bye, Roman

2003-05-27 18:11:32

by Jeff Garzik

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, May 27, 2003 at 02:09:43PM -0400, Ricky Beam wrote:
> On Tue, 27 May 2003, Linus Torvalds wrote:
> >On Tue, 27 May 2003, Ricky Beam wrote:
> >>
> >> Count up the number of drivers that haven't been updated to the current
> >> PCI, hotplug, and modules interfaces.
> >
> >Tough. If people don't use them, they don't get supported. It's that easy.
> ...
>
> Allow me to clarify... I don't mind drivers not working. I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke. In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)
>
> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

No. Doing this hides bugs.

We use the compiler to make bugs and needing-work areas blindingly
obviously. Your suggesting we make them less so.

Jeff

2003-05-27 18:19:17

by Robert Love

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 2003-05-27 at 11:09, Ricky Beam wrote:

> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

A lot of this will happen in 2.6-pre, prior to 2.6.0, do not worry.

A final stable release is still a few months off, although as Linus and
Alan have said even that does not mean perfection. But before 2.6.0 hits
the streets, 2.6-pre will mature a lot. This is how things work.

Robert Love

2003-05-27 18:28:11

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 08:19:39PM +0200, Roman Zippel wrote:

> > What the hell am I supposed to enter here? This is just friggin ugly
> > and un-readable. It should be cleaned up.
> I agree and I already fixed this here, so with the next update this will
> look like this:
>
> Subarchitecture Type
> > 1. PC-compatible (X86_PC)
> 2. Voyager (NCR) (X86_VOYAGER)
> 3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
> 4. Summit/EXA (IBM x440) (X86_SUMMIT)
> 5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
> 6. SGI 320/540 (Visual Workstation) (X86_VISWS)
> 7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
> choice[1-7]:
>
> This has other advantages too, one can see now which options were newly
> added and the individual help texts are accessible.

Given that 99% of users will be choosing option 1, it might be a
good thing to have the remaining options only shown if a
CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

Dave

2003-05-27 18:37:57

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 08:19:39PM +0200, Roman Zippel wrote:
>> This has other advantages too, one can see now which options were newly
>> added and the individual help texts are accessible.

On Tue, May 27, 2003 at 07:40:16PM +0100, Dave Jones wrote:
> Given that 99% of users will be choosing option 1, it might be a
> good thing to have the remaining options only shown if a
> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

I'll see about this once I get to looking at making CONFIG_X86_NUMAQ
harder to accidentally trip over (unless someone else does it first).

-- wli

2003-05-27 19:05:12

by Adrian Bunk

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, May 27, 2003 at 02:09:43PM -0400, Ricky Beam wrote:
>
> Allow me to clarify... I don't mind drivers not working. I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke. In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)

Many warnings are for problems that were already present in 2.4 or for
using deprecated (IOW: working) functions. It might be a thought to
probably disable deprecated warnings for stable kernel releases (read
2.6.0, 2.6.1,...) but it's not always a measurement for how far away we
are from 2.6. And besides, a full build of 2.4.20 with gcc 2.95 gives
you 103 warnings.

> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

IMHO compiling and non-working (or worse: working but data-corrupting)
is worse than non-compiling. It might be a good idea to let broken
drivers depend on an (undefined) CONFIG_BROKEN, but this is only a minor
detail with no influence on the 2.6 schedule.

> --Ricky

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

2003-05-27 19:34:07

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

Roman> I agree and I already fixed this here, so with the next update
Roman> this will look like this:

Thanks Roman! This will look alot better and be more easily
understood, by Aunt Tillie or even an aware kernel hacker. wli not
withstanding, making it readable doesn't imply we're wasting time.

Roman> Subarchitecture Type
>> 1. PC-compatible (X86_PC)
Roman> 2. Voyager (NCR) (X86_VOYAGER)
Roman> 3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
Roman> 4. Summit/EXA (IBM x440) (X86_SUMMIT)
Roman> 5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
Roman> 6. SGI 320/540 (Visual Workstation) (X86_VISWS)
Roman> 7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
Roman> choice[1-7]:

Roman> This has other advantages too, one can see now which options
Roman> were newly added and the individual help texts are accessible.

Very nice, this will be great to have.

John

2003-05-27 20:29:53

by John Cherry

[permalink] [raw]

Subject: Re: Linux 2.5.70

ompile statistics: 2.5.70
Compiler: gcc 3.2.2
Script: http://www.osdl.org/archive/cherry/stability/compregress.sh

bzImage bzImage modules
(defconfig) (allmodconfig) (allmodconfig)

2.5.70 7 warnings 10 warnings 1366 warnings
0 errors 0 errors 57 errors

2.5.69 7 warnings 11 warnings 1366 warnings
0 errors 0 errors 57 errors

2.5.68 7 warnings 11 warnings 1975 warnings
0 errors 6 errors 60 errors

2.5.67 8 warnings 12 warnings 2136 warnings
0 errors 6 errors 89 errros

Compile statistics have been for kernel releases from 2.5.46 to 2.5.70
at: http://www.osdl.org/archive/cherry/stability

Failure summary:

drivers/block: 2 warnings, 1 errors
drivers/char: 237 warnings, 4 errors
drivers/isdn: 237 warnings, 8 errors
drivers/media: 102 warnings, 5 errors
drivers/mtd: 31 warnings, 1 errors
drivers/net: 336 warnings, 6 errors
drivers/scsi/aic7xxx: 0 warnings, 1 errors
drivers/video/i810: 3 warnings, 4 errors
drivers/video/matrox: 3 warnings, 10 errors
drivers/video: 81 warnings, 17 errors
sound/oss: 49 warnings, 3 errors
sound: 5 warnings, 3 errors

Warning summary:

drivers/atm: 36 warnings, 0 errors
drivers/cdrom: 25 warnings, 0 errors
drivers/hotplug: 1 warnings, 0 errors
drivers/i2c: 3 warnings, 0 errors
drivers/ide: 32 warnings, 0 errors
drivers/md: 2 warnings, 0 errors
drivers/message: 1 warnings, 0 errors
drivers/pcmcia: 3 warnings, 0 errors
drivers/scsi/aacraid: 1 warnings, 0 errors
drivers/scsi/pcmcia: 4 warnings, 0 errors
drivers/scsi/sym53c8xx_2: 1 warnings, 0 errors
drivers/serial: 1 warnings, 0 errors
drivers/telephony: 10 warnings, 0 errors
drivers/usb: 13 warnings, 0 errors
drivers/video/aty: 4 warnings, 0 errors
drivers/video/sis: 3 warnings, 0 errors
fs/afs: 1 warnings, 0 errors
fs/cifs: 1 warnings, 0 errors
fs/intermezzo: 1 warnings, 0 errors
fs/lockd: 4 warnings, 0 errors
fs/nfsd: 2 warnings, 0 errors
fs/smbfs: 2 warnings, 0 errors
net: 30 warnings, 0 errors
security: 2 warnings, 0 errors
sound/isa: 3 warnings, 0 errors
sound/pci: 1 warnings, 0 errors
sound/usb: 2 warnings, 0 errors

Other stability-related links:
OSDL Stability page:
http://osdl.org/projects/26lnxstblztn/results/
Nightly linux-2.5 bk build:
http://www.osdl.org/archive/cherry/stability/linus-tree/running.txt
2.5 porting items:
http://www.osdl.org/archive/cherry/stability/linus-tree/port_items.txt
2.5 porting items history:
http://www.osdl.org/archive/cherry/stability/linus-tree/port_history.txt

John

2003-05-27 20:54:02

by Andreas Boman

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 2003-05-27 at 12:58, Ricky Beam wrote:
<SNIP>
> Take a look at the number of arch's that haven't seen much testing (and
> in many respects are thus broken)... does anyone have a functional 2.5.70
> sparc64 kernel? I've built several but they're all too big to be booted
> (i.e. over 3.5M, and yes, I've turned off everything possible.)
> --Ricky
>

aboman@griffin:~> uname -a
Linux griffin 2.5.70 #1 Tue May 27 16:53:08 EDT 2003 sparc64 unknown unknown GNU/Linux

aboman@griffin:~> ls -lh /boot/vmlinux-2.5.70
-rwxrwxr-x 1 root root 2.6M May 27 16:57 /boot/vmlinux-2.5.70

regards,
Andreas

2003-05-27 21:03:52

by Hans Reiser

[permalink] [raw]

Subject: Re: Linux 2.5.70

Linus Torvalds wrote:

>
>This is not just a core kernel issue - we've seen this with subsystems
>like ext3 and ReiserFS: they were "finished' and "stable", but what made
>them _really_ stable was a release or two on vendor kernels, and thousands
>of users.
>
>
>
I wish this wasn't true, but it was. When I say something is stable, I
mean that we have fixed every reported bug.

I have this hypothesis of software engineering which is that every order
of magnitude increase in the number of users finds as many bugs as the
previous order of magnitude increase.

With ReiserFS, I several times publicly said that it was stable, and for
that order of magnitude of users it was, and then the order of magnitude
changed and it wasn't....

With V4 we are going to benefit from an accumulation of testing scripts
(and more experience at what we do plus less hurried code), and that
will put us a few orders of magnitude farther ahead.

It will be a bit ironic that V4 is architected for greater data security
with its atomic filesystem operations, and yet V3 will for quite some
time offer greater data security in reality.

(V4 is currently being tuned for CPU consumption, and its VM
interaction. We have some fond hope of releasing in July.)

--
Hans

2003-05-27 21:13:58

by Pete Zaitcev

[permalink] [raw]

Subject: Re: Linux 2.5.70

>[...]
> Take a look at the number of arch's that haven't seen much testing (and
> in many respects are thus broken)... does anyone have a functional 2.5.70
> sparc64 kernel? I've built several but they're all too big to be booted
> (i.e. over 3.5M, and yes, I've turned off everything possible.)

The topic of architectures being behind was discussed in the
context of AKPM's must-fix list, before Hanna's #lse call.
The decision is to go ahead with first tier architectures only.
Please deal with it.

-- Pete

2003-05-27 21:44:05

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> The language and description used when running 'make oldconfig' and
> trying to set the "X86_GENERICARCH" option is ugly and hard to
> understand and doesn't match how it's shown in the 'make menuconfig'
> settings.

Generic arch will take over half of the other arches when it's a bit
better tested. Generic PC is, I believe, the default - if that's not
working, let us know. Otherwise, don't mess with the defaults if you
don't understand the question ;-)

M.

2003-05-27 21:47:03

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> > > What the hell am I supposed to enter here? This is just friggin ugly
> > > and un-readable. It should be cleaned up.
> > I agree and I already fixed this here, so with the next update this will
> > look like this:
> >
> > Subarchitecture Type
> > > 1. PC-compatible (X86_PC)
> > 2. Voyager (NCR) (X86_VOYAGER)
> > 3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
> > 4. Summit/EXA (IBM x440) (X86_SUMMIT)
> > 5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
> > 6. SGI 320/540 (Visual Workstation) (X86_VISWS)
> > 7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
> > choice[1-7]:
> >
> > This has other advantages too, one can see now which options were newly
> > added and the individual help texts are accessible.
>
> Given that 99% of users will be choosing option 1, it might be a
> good thing to have the remaining options only shown if a
> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

Please, not more layered config options! That just makes people who
want to enable the x440 or other alternative platform require fair
amounts of psychic power (maybe this can be fixed with a big fat help
message, but so can the current method).

If you're going hide the other options away so much, then the default
should be the generic arch, IMHO.

M.

2003-05-27 23:26:10

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:

> > Given that 99% of users will be choosing option 1, it might be a
> > good thing to have the remaining options only shown if a
> > CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
>
> Please, not more layered config options! That just makes people who
> want to enable the x440 or other alternative platform require fair
> amounts of psychic power (maybe this can be fixed with a big fat help
> message, but so can the current method).

With all due respect, 'screw x440 et al'. The fact remains that a
majority of users won't even know what an x440 _is_, let alone
need to configure for one. If someone has actually ended up with
one of those, I'd like to think they at least have enough clue to
know what it is they've just spent their megabucks on.

> If you're going hide the other options away so much, then the default
> should be the generic arch, IMHO.

That's precisely what I was saying. I think we're in agreement,
in a roundabout 'same but different' sort of way. I think.

Dave

2003-05-28 02:17:10

by Daniel Phillips

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tuesday 27 May 2003 18:58, Ricky Beam wrote:
> On Mon, 26 May 2003, Linus Torvalds wrote:
> >... to start the "pre-2.6" series ...
>
> You're kidding, right? 2.5 is no where near ready to be called anything
> like "2.6".

Don't freak out too much - remember how long the -test series lasted last time
(most of a year). Hopefully it will be faster this time, but even twice as
fast will still give people time to beat on their favorite features and
drivers.

Regards,

Daniel

2003-05-28 03:08:03

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> > Please, not more layered config options! That just makes people who
> > want to enable the x440 or other alternative platform require fair
> > amounts of psychic power (maybe this can be fixed with a big fat help
> > message, but so can the current method).
>
> With all due respect, 'screw x440 et al'. The fact remains that a
> majority of users won't even know what an x440 _is_, let alone
> need to configure for one. If someone has actually ended up with
> one of those, I'd like to think they at least have enough clue to
> know what it is they've just spent their megabucks on.

;-)

> > If you're going hide the other options away so much, then the default
> > should be the generic arch, IMHO.
>
> That's precisely what I was saying. I think we're in agreement,
> in a roundabout 'same but different' sort of way. I think.

OK, I think so ... I just think making the generic arch the default is
sufficient, without hiding things away under another menu where it's
harder to find ... if people don't understand the question, they should
just take the default. Frigging with the wording might help a bit ...
I think there's some way to force a hint to appear automatically like
"if you don't know, use XXX".

M.

2003-05-28 03:22:00

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

At some point in the past, Dave Jones' attribution was stripped from:
>> Given that 99% of users will be choosing option 1, it might be a
>> good thing to have the remaining options only shown if a
>> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.

On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:
> Please, not more layered config options! That just makes people who
> want to enable the x440 or other alternative platform require fair
> amounts of psychic power (maybe this can be fixed with a big fat help
> message, but so can the current method).
> If you're going hide the other options away so much, then the default
> should be the generic arch, IMHO.

Or better yet, remove all the #ifdefs, finish generalizing the APIC
code, and have nothing to configure at all. For 2.7 ...

-- wli

2003-05-28 05:58:30

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> At some point in the past, Dave Jones' attribution was stripped from:
>>> Given that 99% of users will be choosing option 1, it might be a
>>> good thing to have the remaining options only shown if a
>>> CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
>
> On Tue, May 27, 2003 at 02:59:23PM -0700, Martin J. Bligh wrote:
>> Please, not more layered config options! That just makes people who
>> want to enable the x440 or other alternative platform require fair
>> amounts of psychic power (maybe this can be fixed with a big fat help
>> message, but so can the current method).
>> If you're going hide the other options away so much, then the default
>> should be the generic arch, IMHO.
>
> Or better yet, remove all the #ifdefs, finish generalizing the APIC
> code, and have nothing to configure at all. For 2.7 ...

For the "commerical" options like Summit and bigsmp, I think this is an
option for 2.5 even, given some more testing. And then the wierdo arches
can be better hidden ;-)

M.

2003-05-28 06:37:27

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, May 27, 2003 at 08:34:59PM -0700, William Lee Irwin III wrote:

> Or better yet, remove all the #ifdefs, finish generalizing the APIC
> code, and have nothing to configure at all. For 2.7 ...

Yes, even better. Especially for distros. Andi did some work in
this area, but there is still work to be done there.

Dave

2003-05-28 07:30:37

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

At some point in the past, my attribution was stripped from:
>> Or better yet, remove all the #ifdefs, finish generalizing the APIC
>> code, and have nothing to configure at all. For 2.7 ...

On Tue, May 27, 2003 at 11:11:20PM -0700, Martin J. Bligh wrote:
> For the "commerical" options like Summit and bigsmp, I think this is an
> option for 2.5 even, given some more testing. And then the wierdo arches
> can be better hidden ;-)

The delimiter between weirdo and non-weirdo arches is wrong IMHO; so
long as the only differences are APIC handling (and that in fact holds
for NUMA-Q and a couple of others that were left out of the generic
bits) a "proper" APIC abstraction should handle it just fine.

One might argue that NUMA-Q is a corner case not worth handling by a
generic APIC layer; it is a corner case, however it far more clearly
shows where generality is needed, in particular because it mixes
clustered hierarchical DFR and logical IPI's with physical DESTMOD in
IO-APIC RTE's. At the moment the general confusions, mis-declarations,
and what appear to be either latent or actual bugs going around
include/asm-i386/mach-*/mach_apic.h point to a need for a consolidated
library of APIC macros and functions accurately conforming to the Intel
specifications. AFAICT there are four and only four or five parameters
that really make a difference:

(1) APIC vs. xAPIC
(2) clustered hierarchical DFR vs. flat DFR
(3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
(4) wakeup via INIT or via NMI
(5) physical IPI's or logical IPI's

So one could easily form destinations by:

physical_destination_t cpumask_to_physical_destination(cpumask_t cpumask)
{
int cpu, ncpus = cpus_weight(cpumask);

if (!ncpus) {
WARN_ON(1);
if (xapic)
return XAPIC_PHYSICAL_BROADCAST;
else
return SAPIC_PHYSICAL_BROADCAST;
}

WARN_ON(ncpus > 1);
cpu = first_cpu(cpumask);
if (!xapic && cpu >= 16) {
WARN_ON(1);
return SAPIC_PHYSICAL_BROADCAST;
}

return (physical_destination_t) { 1UL << cpu };
}

logical_destination_t cpumask_to_logical_destination(cpumask_t cpumask)
{
unsigned long k, raw_dest = 0UL;

if (apic_dfr_flat) {
cpumask_t invalid_mask = cpus_promote(0xFFUL);
cpus_complement(invalid_mask);
cpus_and(invalid_mask, invalid_mask, cpumask);
WARN_ON(!cpus_empty(invalid_mask));
return (logical_destination_t){ cpus_coerce(cpumask) & 0xFFUL };
}

for (k = 0; k < NR_CPUS; ++k) {
if (!cpu_isset(k, cpumask))
continue;
if (raw_dest) {
unsigned long old_cluster, new_cluster;
old_cluster = raw_dest >> 4;
new_cluster = k >> 4;
if (old_cluster != new_cluster) {
WARN_ON(1);
continue;
}
}
raw_dest |= (k & ~0xFUL) | (1UL << (k & 0xf));
}
if (!raw_dest) {
WARN_ON(1);
return APIC_LOGICAL_BROADCAST;
}
return (logical_destination_t) { raw_dest };
}

Destination formation is done in two contexts:
(1) IPI's
(2) IO-APIC RTE's

The higher level of abstraction could easily insulate subarches with:

ipi_destination_t cpumask_to_ipi_destination(cpumask_t cpumask)
{
switch (APIC_IPI_MODE) {
case APIC_IPI_MODE_PHYSICAL:
return cpumask_to_physical_destination(cpumask);
break;
case APIC_IPI_MODE_LOGICAL:
return cpumask_to_logical_destination(cpumask);
break;
default:
BUG();
return (ipi_destination_t) { 0 };
}
}

and

rte_destination_t cpumask_to_ipi_destination(cpumask_t cpumask)
{
switch (IOAPIC_RTE_DESTMOD) {
case IOAPIC_RTE_DESTMOD_PHYSICAL:
return cpumask_to_physical_destination(cpumask);
break;
case IOAPIC_RTE_DESTMOD_LOGICAL:
return cpumask_to_logical_destination(cpumask);
break;
default:
BUG();
return (rte_destination_t) { 0 };
}
}

with ipi_destination_t typedef'd to physical_destination_t or
logical_destination_t according to the subarch.

CPU wakeup would proceed similarly; just check an operational variable
and either NMI with a logical destination or INIT with a physical
destination, with tabulated BIOS IDT addresses to edit.

And the infamous setup_ioapic_ids_from_mpc() needs a notion of APIC
buses to which IO-APIC's and cpus are connected. It should be look like:

static void __init setup_ioapic_ids_from_mpc(void)
{
int apic_bus;

for (apic_bus = 0; apic_bus < MAX_APIC_BUSES; ++apic_bus) {
unsigned long local_physid_map[BITS_TO_LONGS(XAPIC_PHYSICAL_BROADCAST+1)] = { [0...XAPIC_PHYSICAL_BROADCAST] = 0UL };
int ioapic, cpu;

if (!apic_bus_present(apic_bus))
continue;

for (cpu = 0; cpu < NR_CPUS; ++cpu) {
if (!cpu_present(cpu))
continue;
if (apic_bus_of_cpu(cpu) != apic_bus)
continue;

set_bit(cpu, local_physid_map);
}

for (ioapic = 0; ioapic < nr_ioapics; ++ioapic) {
int ioapic_physid, entry;

if (apic_bus_of_ioapic(ioapic) != apic_bus)
continue;

if (MP_APICID_PHYSICAL)
ioapic_physid = mp_ioapics[ioapic].mpc_apicid;
else {
for (entry = 0; entry < MAX_MPC_ENTRY; ++entry)
if (!translation_table[entry])
continue;
if (translation_table[entry]->mpc_apicid != mp_ioapics[ioapic].mpc_apicid)
continue;
if (translation_table[entry]->trans_type == MP_IOAPIC)
break;

if (entry >= MAX_MPC_ENTRY)
panic("IO-APIC %d not listed in"
" translation table\n", ioapic);
ioapic_physid = translation_table[entry]->trans_local;
}

if (test_bit(ioapic_physid, local_physid_map)) {
unsigned long free_physids[BITS_TO_LONGS(XAPIC_PHYSICAL_BROADCAST+1)];
int j, new_physid;
unsigned long flags;
struct IO_APIC_reg_00 reg_00;

for (j = 0; j < ARRAY_SIZE(free_physids); ++j)
free_physids[j] = ~local_physid_map[j];

new_physid = find_first_bit(free_physids,
XAPIC_PHYSICAL_BROADCAST + 1);
if (!xapic && new_physid >= SAPIC_PHYSICAL_BROADCAST)
panic("physical APIC ID clash not "
"resolvable due to physical "
"APIC ID space exhaustion on "
"APIC bus %d\n", apic_bus);
printk("renumbering IO-APIC %d to physical"
"APIC ID %d from %d\n",
ioapic, new_physid, ioapic_physid);
spin_lock_irqsave(&ioapic_lock, flags);
*(int *)&reg_00 = io_apic_read(ioapic, 0);
reg_00.ID = new_physid;
io_apic_write(ioapic, 0, *(int *)&reg_00);
spin_unlock_irqsave(&ioapic_lock, flags);
set_bit(new_physid, local_physid_map);
if (MP_APICID_PHYSICAL)
mp_ioapics[ioapic].mpc_apicid =
new_physid;
else
translation_table[entry]->trans_local =
new_physid;
}
set_bit(ioapic_physid, local_physid_map);
}
}
}

Afterward, APIC-based subarches would just declare their preferences
and the APIC library would dispatch on the operational variables they
declare in mach_apic.h. Shoving the entire thing in a header with
inlines kills off so-called runtime overhead, and the generic subarch
bits would be largely unaltered, and provide a machine vector largely
identical to what it does today. Then, since APIC support is complete,
the detection phases would retarget the APIC driver to the proper
machine vector for the detected machine configuration and work across
a broader variety of systems than it does today.

This is not a pointless exercise: the bogosities I pointed out in the
userspace irqbalancing thread are very real. In particular the APIC vs.
xAPIC oddities for mach-default, though they're not exercised in any
obvious way, are very troubling, and it's unclear whether bigsmp is
peroperly functional as it stands in 2.5.70, since target_cpus()
disallows RTE's targeting clusters > 0 and NO_BALANCE_IRQ is 1. It
vaguely looks like bigsmp cut and paste NUMA-Q APIC code and did the
wrong thing for xAPIC as a result.

Following the spec with respect to destination formation is just not
that far out, people. The above code is just "example code" or whatever
and the BUG() checks are probably overly strict, but the general
notions are basically the rest of what's needed for true APIC genericity.

-- wli

2003-05-28 14:47:11

by Paweł Gołaszewski

[permalink] [raw]

Subject: Re: Linux 2.5.70

Finally - I've started to worry if this kernel will be ever released :)

When building framebuffer driver for my new Matrox G400 I get this error:

scripts/fixdep drivers/video/logo/.logo_linux_clut224.o.d drivers/video/logo/logo_linux_clut224.o 'gcc -Wp,-MD,drivers/video/logo/.logo_linux_clut224.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include -DKBUILD_BASENAME=logo_linux_clut224 -DKBUILD_MODNAME=logo_linux_clut224 -c -o drivers/video/logo/.tmp_logo_linux_clut224.o drivers/video/logo/logo_linux_clut224.c' > drivers/video/logo/.logo_linux_clut224.o.tmp; rm -f drivers/video/logo/.logo_linux_clut224.o.d; mv -f drivers/video/logo/.logo_linux_clut224.o.tmp drivers/video/logo/.logo_linux_clut224.o.cmd
LD drivers/video/logo/built-in.o
CC drivers/video/matrox/matroxfb_base.o
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:53: video/fbcon-cfb4.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:54: video/fbcon-cfb8.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:55: video/fbcon-cfb16.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:56: video/fbcon-cfb24.h: No such file or directory
drivers/video/matrox/matroxfb_base.h:57: video/fbcon-cfb32.h: No such file or directory
In file included from drivers/video/matrox/matroxfb_base.c:105:
drivers/video/matrox/matroxfb_base.h:341: warning: `struct display' declared inside parameter list
drivers/video/matrox/matroxfb_base.h:341: warning: its scope is only this definition or declaration, which is probably not what you want.
drivers/video/matrox/matroxfb_base.h:342: warning: `struct display' declared inside parameter list
drivers/video/matrox/matroxfb_base.h:558: field `dispsw' has incomplete type
drivers/video/matrox/matroxfb_base.h: In function `mxinfo':
drivers/video/matrox/matroxfb_base.h:633: dereferencing pointer to incomplete
typedrivers/video/matrox/matroxfb_base.c: At top level:
drivers/video/matrox/matroxfb_base.c:148: warning: braces around scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c:148: warning: excess elements in scalar initializer
drivers/video/matrox/matroxfb_base.c:148: warning: (near initialization for `vesafb_defined.rotate')
drivers/video/matrox/matroxfb_base.c: In function `my_install_cmap':
drivers/video/matrox/matroxfb_base.c:158: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matrox_pan_var':
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of function `fontheight'
drivers/video/matrox/matroxfb_base.c:186: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:186: warning: implicit declaration of function `fontwidth'
drivers/video/matrox/matroxfb_base.c:169: warning: `pos' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_remove':
drivers/video/matrox/matroxfb_base.c:238: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_pan_display':
drivers/video/matrox/matroxfb_base.c:279: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:279: (Each undeclared identifier is reported only once
drivers/video/matrox/matroxfb_base.c:279: for each function it appears in.)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_updatevar':
drivers/video/matrox/matroxfb_base.c:303: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_var':
drivers/video/matrox/matroxfb_base.c:688: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:690: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:700: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:701: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:702: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:703: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:704: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:705: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:706: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:707: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:711: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:721: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:725: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:728: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:729: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:735: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:736: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:802: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:678: warning: `display' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c:738: warning: `pos' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_get_cmap':
drivers/video/matrox/matroxfb_base.c:866: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:867: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:876: warning: implicit declaration of function `fb_get_cmap'
drivers/video/matrox/matroxfb_base.c:877: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:878: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:880: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_set_cmap':
drivers/video/matrox/matroxfb_base.c:890: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:890: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:899: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:900: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:903: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:910: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_ioctl':
drivers/video/matrox/matroxfb_base.c:1009: structure has no member named `switch_con'
drivers/video/matrox/matroxfb_base.c: At top level:
drivers/video/matrox/matroxfb_base.c:1188: unknown field `fb_set_var' specified in initializer
drivers/video/matrox/matroxfb_base.c:1188: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1189: unknown field `fb_get_cmap' specified in initializer
drivers/video/matrox/matroxfb_base.c:1189: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1190: unknown field `fb_set_cmap' specified in initializer
drivers/video/matrox/matroxfb_base.c:1190: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1192: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c:1194: warning: initialization from incompatible pointer type
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_switch':
drivers/video/matrox/matroxfb_base.c:1207: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1222: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:1224: `fb_display' undeclared (first use in this function)
drivers/video/matrox/matroxfb_base.c:1226: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1235: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:1200: warning: `cmap' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c:1201: warning: `p' might be used uninitialized in this function
drivers/video/matrox/matroxfb_base.c: In function `initMatrox2':
drivers/video/matrox/matroxfb_base.c:1741: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:1742: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:1753: structure has no member named `modename'
drivers/video/matrox/matroxfb_base.c:1754: structure has no member named `changevar'
drivers/video/matrox/matroxfb_base.c:1756: structure has no member named `disp'
drivers/video/matrox/matroxfb_base.c:1757: structure has no member named `switch_con'
drivers/video/matrox/matroxfb_base.c:1758: structure has no member named `updatevar'
drivers/video/matrox/matroxfb_base.c:1874: structure has no member named `modename'
drivers/video/matrox/matroxfb_base.c: In function `matroxfb_probe':
drivers/video/matrox/matroxfb_base.c:2015: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2027: dereferencing pointer to incomplete type
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
drivers/video/matrox/matroxfb_base.c:2034: structure has no member named `fontname'
make[3]: *** [drivers/video/matrox/matroxfb_base.o] Error 1
make[2]: *** [drivers/video/matrox] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
Command exited with non-zero status 2

--
pozdr. Pawe? Go?aszewski
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...

2003-05-28 14:55:40

by Petr Vandrovec

[permalink] [raw]

Subject: Re: Linux 2.5.70

On 28 May 03 at 16:59, Pawe? Go?aszewski wrote:
> Finally - I've started to worry if this kernel will be ever released :)
>
> When building framebuffer driver for my new Matrox G400 I get this error:
>
> scripts/fixdep drivers/video/logo/.logo_linux_clut224.o.d drivers/video/logo/logo_linux_clut224.o 'gcc -Wp,-MD,drivers/video/logo/.logo_linux_clut224.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-protot

> LD drivers/video/logo/built-in.o
> CC drivers/video/matrox/matroxfb_base.o
> In file included from drivers/video/matrox/matroxfb_base.c:105:
> drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or directory

I just sent email there yesterday with URL of matroxfb patch I sent to
Linus for inclusion.

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz

Petr Vandrovec

2003-05-28 15:15:19

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> (1) APIC vs. xAPIC
> (2) clustered hierarchical DFR vs. flat DFR
> (3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
> (4) wakeup via INIT or via NMI
> (5) physical IPI's or logical IPI's
>
> So one could easily form destinations by:

Yes. It's fixable, and I think that's a good project for 2.7, but I really
don't think that level of change is justified at the moment. Testing this
stuff is a pain in the ass, it's a lot of work to do properly and carefully.
And what does that change buy us in reality? Not a lot.

I agree it would be nice to do ... just not the focus during a 2.6
stabilisation effort, when we have so many other more important things to
work on, that would have real impact.

M.

2003-05-28 15:42:56

by Paweł Gołaszewski

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Wed, 28 May 2003, Petr Vandrovec wrote:
> > Finally - I've started to worry if this kernel will be ever released
> > When building framebuffer driver for my new Matrox G400 I get this
> > error:
> >
> > scripts/fixdep drivers/video/logo/.logo_linux_clut224.o.d drivers/video/logo/logo_linux_clut224.o 'gcc -Wp,-MD,drivers/video/logo/.logo_linux_clut224.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-protot
> > LD drivers/video/logo/built-in.o
> > CC drivers/video/matrox/matroxfb_base.o
> > In file included from drivers/video/matrox/matroxfb_base.c:105:
> > drivers/video/matrox/matroxfb_base.h:52: video/fbcon.h: No such file or directory
> I just sent email there yesterday with URL of matroxfb patch I sent to
> Linus for inclusion.

sorry - I haven't seen it...

> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/mga-stripdown-2.5.70.gz

Tnx - it builds fine now. After I'll be back home I'll check if it works
:)

There is second problem - some unresolved symbols while make
modules_install:

if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.5.70; fi
WARNING: /lib/modules/2.5.70/kernel/arch/i386/kernel/cpu/cpufreq/powernow-k7.ko needs unknown symbol dmi_broken
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/radeon.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/r128.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/mga.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/i830.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/i810.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/drm/gamma.ko needs unknown symbol mmu_cr4_features
WARNING: /lib/modules/2.5.70/kernel/drivers/char/agp/nvidia-agp.ko needs unknown symbol agp_memory_reserved

My kernel config:
http://piorun.ds.pg.gda.pl/~blues/config-2.5.70.txt

--
pozdr. Pawe? Go?aszewski
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...

2003-05-28 15:51:40

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 27 May 2003, Linus Torvalds wrote:

>
> On Tue, 27 May 2003, Ricky Beam wrote:
> >
> > Count up the number of drivers that haven't been updated to the current
> > PCI, hotplug, and modules interfaces.
>
> Tough. If people don't use them, they don't get supported. It's that easy.

Just the other day you posted strong opposition to breaking existing
binaries, how does that map with breaking existing hardware?
>
> The thing is, these things won't change before 2.6 (or at least a
> pre-2.6). When 2.6.0 comes out, and somebody notices that they haven't
> bothered to try the 2.5.x series, _then_ maybe some of those odd-ball
> drivers get fixed.
>
> Or not. Some of them may be literally due for retirement, with users just
> running an old kernel on old hardware.
>
> Btw, this is nothing new. It has _always_ been the case that a lot of
> people didn't use the latest stable kernel until it was released, and then
> they complained because the drivers they used weren't up to spec.
>
> Linus

That's clearly true, but part of the reason is that some drivers just
don't compile, so people assume it's a work in progress. And when problems
are reported they sometimes don't get fixed even when there is a
maintainer listed for a driver. Hopefully vendors will pick up the slack
for things like that and the power management issues.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-28 16:00:47

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Tue, 27 May 2003, Ricky Beam wrote:

> On Tue, 27 May 2003, Linus Torvalds wrote:
> >On Tue, 27 May 2003, Ricky Beam wrote:
> >>
> >> Count up the number of drivers that haven't been updated to the current
> >> PCI, hotplug, and modules interfaces.
> >
> >Tough. If people don't use them, they don't get supported. It's that easy.
> ...
>
> Allow me to clarify... I don't mind drivers not working. I *do* mind
> drivers emitting hundreds of warnings and errors because dozens of things
> were changed and no one cared to update everything they broke. In some
> cases, fixing things may be simple (eg. someone removed or renamed a field
> in a struct somewhere) and in others years of work my be required (eg.
> the new module interface.)
>
> In my opinion (as it was in the long long ago), everything in a "stable"
> release should at least compile cleanly -- "working" comes later after
> users have been conned into using it.

See the stats posted to lkml from time to time on errors and warnings. The
2.4 stable kernels don't compile cleanly, with some combinations of config
options they may not compile at all. The ones which compile and work, even
with all manner of warnings, are a good place to start doing some
housekeeping and sending it back to the maintainer.

Maintainers vary on their desire to push cosmetic fixes into working
code, even when they are correct.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-28 16:14:43

by Linus Torvalds

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Wed, 28 May 2003, Bill Davidsen wrote:
>
> Just the other day you posted strong opposition to breaking existing
> binaries, how does that map with breaking existing hardware?

One fundamental difference is that I cannot fix it without people who
_have_ the hardware caring. So if they don't care, I don't care. It's that
easy. If you want to have your hardware supported, you need to help
support it.

Another difference is that it's better to not work at all, than to work
incorrectly. So if your kernel doesn't boot or can't use your random piece
of hardware, you just use an old kernel. But if everything looks normal,
but some binary breaks in strange ways, that's _bad_.

The latter reason is, btw, why we don't paper over the build failures like
some people suggested. If it hasn't been updated to the new interfaces, it
should preferably not even build: which is a big reason why we try to
rename interfaces when they change, exactly so that you don't get a subtly
broken build.

Linus

2003-05-28 16:42:10

by John Cherry

[permalink] [raw]

Subject: Re: Linux 2.5.70

Sorry. There was a translation error in the last batch of numbers I
sent out. We actually went from 1567 warnings in a full allmodconfig
build to 1366 warning (down 201 warnings!).

bzImage bzImage modules
(defconfig) (allmodconfig) (allmodconfig)

2.5.70 7 warnings 10 warnings 1366 warnings
0 errors 0 errors 57 errors

2.5.69 7 warnings 11 warnings 1567 warnings
0 errors 0 errors 57 errors

2.5.68 7 warnings 11 warnings 1975 warnings
0 errors 6 errors 60 errors

2.5.67 8 warnings 12 warnings 2136 warnings
0 errors 6 errors 89 errros

John

On Tue, 2003-05-27 at 14:42, John Cherry wrote:
> ompile statistics: 2.5.70
> Compiler: gcc 3.2.2
> Script: http://www.osdl.org/archive/cherry/stability/compregress.sh
>
> bzImage bzImage modules
> (defconfig) (allmodconfig) (allmodconfig)
>
> 2.5.70 7 warnings 10 warnings 1366 warnings
> 0 errors 0 errors 57 errors
>
> 2.5.69 7 warnings 11 warnings 1366 warnings
> 0 errors 0 errors 57 errors
>
> 2.5.68 7 warnings 11 warnings 1975 warnings
> 0 errors 6 errors 60 errors
>
> 2.5.67 8 warnings 12 warnings 2136 warnings
> 0 errors 6 errors 89 errros
>
>
> Compile statistics have been for kernel releases from 2.5.46 to 2.5.70
> at: http://www.osdl.org/archive/cherry/stability
>
> Failure summary:
>
> drivers/block: 2 warnings, 1 errors
> drivers/char: 237 warnings, 4 errors
> drivers/isdn: 237 warnings, 8 errors
> drivers/media: 102 warnings, 5 errors
> drivers/mtd: 31 warnings, 1 errors
> drivers/net: 336 warnings, 6 errors
> drivers/scsi/aic7xxx: 0 warnings, 1 errors
> drivers/video/i810: 3 warnings, 4 errors
> drivers/video/matrox: 3 warnings, 10 errors
> drivers/video: 81 warnings, 17 errors
> sound/oss: 49 warnings, 3 errors
> sound: 5 warnings, 3 errors
>
>
> Warning summary:
>
>
> drivers/atm: 36 warnings, 0 errors
> drivers/cdrom: 25 warnings, 0 errors
> drivers/hotplug: 1 warnings, 0 errors
> drivers/i2c: 3 warnings, 0 errors
> drivers/ide: 32 warnings, 0 errors
> drivers/md: 2 warnings, 0 errors
> drivers/message: 1 warnings, 0 errors
> drivers/pcmcia: 3 warnings, 0 errors
> drivers/scsi/aacraid: 1 warnings, 0 errors
> drivers/scsi/pcmcia: 4 warnings, 0 errors
> drivers/scsi/sym53c8xx_2: 1 warnings, 0 errors
> drivers/serial: 1 warnings, 0 errors
> drivers/telephony: 10 warnings, 0 errors
> drivers/usb: 13 warnings, 0 errors
> drivers/video/aty: 4 warnings, 0 errors
> drivers/video/sis: 3 warnings, 0 errors
> fs/afs: 1 warnings, 0 errors
> fs/cifs: 1 warnings, 0 errors
> fs/intermezzo: 1 warnings, 0 errors
> fs/lockd: 4 warnings, 0 errors
> fs/nfsd: 2 warnings, 0 errors
> fs/smbfs: 2 warnings, 0 errors
> net: 30 warnings, 0 errors
> security: 2 warnings, 0 errors
> sound/isa: 3 warnings, 0 errors
> sound/pci: 1 warnings, 0 errors
> sound/usb: 2 warnings, 0 errors
>
>
>
> Other stability-related links:
> OSDL Stability page:
> http://osdl.org/projects/26lnxstblztn/results/
> Nightly linux-2.5 bk build:
> http://www.osdl.org/archive/cherry/stability/linus-tree/running.txt
> 2.5 porting items:
> http://www.osdl.org/archive/cherry/stability/linus-tree/port_items.txt
> 2.5 porting items history:
> http://www.osdl.org/archive/cherry/stability/linus-tree/port_history.txt
>
> John
>
>
>
> -
> 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/

2003-05-28 19:15:06

by ismail donmez

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Wednesday 28 May 2003 19:14, Linus Torvalds wrote:
> On Wed, 28 May 2003, Bill Davidsen wrote:
> > Just the other day you posted strong opposition to breaking existing
> > binaries, how does that map with breaking existing hardware?
>
> One fundamental difference is that I cannot fix it without people who
> _have_ the hardware caring. So if they don't care, I don't care. It's that
> easy. If you want to have your hardware supported, you need to help
> support it.

Quite true. But there are bugs at kernel bugzilla which

1- People care about it being fixed
2- Tests beta kernels to see if its fixed
3- Reports success/failures

But still these bugs are unresolved. I do not say/mean kernel hackers do not
care them or something like that but it would be better to get these kind of
bugs ( with user base who tests them ) fixed before pre-2.6 releases.

Regards,
/ismail

2003-05-28 22:01:10

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

On Tue, 27 May 2003, Martin J. Bligh wrote:

> > > > What the hell am I supposed to enter here? This is just friggin ugly
> > > > and un-readable. It should be cleaned up.
> > > I agree and I already fixed this here, so with the next update this will
> > > look like this:
> > >
> > > Subarchitecture Type
> > > > 1. PC-compatible (X86_PC)
> > > 2. Voyager (NCR) (X86_VOYAGER)
> > > 3. NUMAQ (IBM/Sequent) (X86_NUMAQ)
> > > 4. Summit/EXA (IBM x440) (X86_SUMMIT)
> > > 5. Support for other sub-arch SMP systems with more than 8 CPUs (X86_BIGSMP)
> > > 6. SGI 320/540 (Visual Workstation) (X86_VISWS)
> > > 7. Generic architecture (Summit, bigsmp, default) (X86_GENERICARCH) (NEW)
> > > choice[1-7]:
> > >
> > > This has other advantages too, one can see now which options were newly
> > > added and the individual help texts are accessible.
> >
> > Given that 99% of users will be choosing option 1, it might be a
> > good thing to have the remaining options only shown if a
> > CONFIG_X86_SUBARCHS=y and have things default to option 1 if =n.
>
> Please, not more layered config options! That just makes people who
> want to enable the x440 or other alternative platform require fair
> amounts of psychic power (maybe this can be fixed with a big fat help
> message, but so can the current method).

You have one good idea here, leaving the output unreadable is not it. I
was going to suggest a readable menu but someone beat me to it, it's the
obvious choice for this much stuuf, rather than one (usually folded) line.
>
> If you're going hide the other options away so much, then the default
> should be the generic arch, IMHO.

Not *that* is the good idea! A nice multiple choice menu with a note to
leave alone unless you have a clue is the right way to do it, but the
default should be what's most likely to work.

You will not get people to leave it alone by making it unreadable, you
will just confust the shit out of them by letting them see such detail if
they don't go looking for it. IMHO of course.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-28 22:33:34

[permalink] [raw]

Subject: Re: Linux 2.5.70

On Wed, 28 May 2003, Linus Torvalds wrote:

>
> On Wed, 28 May 2003, Bill Davidsen wrote:
> >
> > Just the other day you posted strong opposition to breaking existing
> > binaries, how does that map with breaking existing hardware?
>
> One fundamental difference is that I cannot fix it without people who
> _have_ the hardware caring. So if they don't care, I don't care. It's that
> easy. If you want to have your hardware supported, you need to help
> support it.

That's the case now, isn't it? unless the person with the non-working
hardware is willing and able to become the maintainer a lot of drivers
don't seem to get fixed. Unfortunately that the people with the old
hardware usually aren't developers.
>
> Another difference is that it's better to not work at all, than to work
> incorrectly. So if your kernel doesn't boot or can't use your random piece
> of hardware, you just use an old kernel. But if everything looks normal,
> but some binary breaks in strange ways, that's _bad_.

Totally agree.
>
> The latter reason is, btw, why we don't paper over the build failures like
> some people suggested. If it hasn't been updated to the new interfaces, it
> should preferably not even build: which is a big reason why we try to
> rename interfaces when they change, exactly so that you don't get a subtly
> broken build.

I don't think anyone suggested that, but there are a fair number of
drivers which could be fixed in minutes by someone who understands the new
interface. Replacing cli is easy, knowing what you replace it with is
something else again. There are new locks, per-cpu stuff added, lockless
methods... to do this right you have to do it often, and few users can do
more than give an error report which allows the problem to be reproduced.

--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-29 00:26:18

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

> You will not get people to leave it alone by making it unreadable, you
> will just confust the shit out of them by letting them see such detail if
> they don't go looking for it. IMHO of course.

Oh, I wasn't disputing that should be fixed. I always use menuconfig,
or pipe something to oldconfig, so I don't see it personally ... but
that seemed to be under no debate - Roman already said he'd fix that;
it's obviously a bug.

M.

2003-05-29 01:02:24

[permalink] [raw]

Subject: Re: Linux 2.5.70 compile error

At some point in the past, my attribution was stripped from:
>> (1) APIC vs. xAPIC
>> (2) clustered hierarchical DFR vs. flat DFR
>> (3) physical DESTMOD vs. logical DESTMOD in IO-APIC RTE's
>> (4) wakeup via INIT or via NMI
>> (5) physical IPI's or logical IPI's
>> So one could easily form destinations by:

On Wed, May 28, 2003 at 08:28:09AM -0700, Martin J. Bligh wrote:
> Yes. It's fixable, and I think that's a good project for 2.7, but I really
> don't think that level of change is justified at the moment. Testing this
> stuff is a pain in the ass, it's a lot of work to do properly and carefully.
> And what does that change buy us in reality? Not a lot.
> I agree it would be nice to do ... just not the focus during a 2.6
> stabilisation effort, when we have so many other more important things to
> work on, that would have real impact.

Yes, it's 2.7 material.

-- wli

2003-05-29 10:59:12