Subject: Re: new patch (fwd)

From: Philip Blundell <[email-masked]>
Date: Thu, 25 Dec 1997 14:04:35 -0500 (EST)

> No Phil.  Your patch does the following:
> 
> *	Changes the help descriptions for the ethernet cards.

That's true.  I hadn't particularly intended for that to leak into the
patch.

> * Moves the kernel link address back to 0x1800000, which is where it was
> originally. 

Yes, on your advice.

> * Changes a few #definitions to to with processor and machine type with
> no overall
> 	effect, especially the processor definitions.
> 	Do you really understand the meaning of the __arm2__ __arm3__
> etc *compiler*
> 	definitions? 

Yes.  gcc 2.8 doesn't define __arm2__ or __arm3__ if you give it the
-mapcs= and -mcpu= options, so with the old #ifdefs you ended up getting
support for no CPUs at all.  You do still get __arm3__ defined with -m3,
but you also get complaints about this being an obsolete option.

> * Removes *all* support for the binutils currently supplied with the ARM
> Linux
> 	distribution.

Since the support was 50% gone already, this strikes me as little
hardship.  The binutils with this problem fixed has been available for
months.
 
> *	Removes the floppy code's ARM architecture dependence.

Why, exactly, do you feel this is bad?  I'm slightly confused as to which
patch you're talking about here.  The one I had last week removed the
architecture dependence, and your reaction to that was "good".
Unfortunately I goofed slightly and the result wouldn't compile
properly (and I left out some debug stuff).  This newer patch remedies
that; I don't understand your objection.

> * Slightly optimises the __xchg() function in terms of memory data
> space. 

... and, more importantly, allows you to compile armksyms.c on a5k
machines.

> * Unnecessarily changes the decompressor code. 
> 	If your compiler can't hack that, then throw it away - it's not ANSI
> 	conformant, and must be broken.

It's gcc, and I don't know of any alternative.

> *	Various spelling corrections.

I can't see that they do any harm either, though I agree that the world
won't end without them.

> In effect, what Phil is trying to do is to remove as many changes as
> possible to the driver code that has moved from the drivers directories
> to the arch/arm/drivers heirarchy. 

That's true, and last time I posted a patch to do this you were all in
favour. 

> What is the point in reversing some of the changes made to *improve* the
> performance of the 2.0 kernels when we're moving towards the 2.1
> kernels? 

Because the fewer gratuitous changes we have, the less work there is to do
with the merge.  If you want to fix 8390.c to go faster, then since it's
not an ARM specific change there's no need to make another copy of the
file.

> There have been *no* bug fixes in this patch whatsoever, in fact, there

If that's your opinion, fine.  Merry Christmas, by the way.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Thu, 25 Dec 1997 21:23:41 +0000 (GMT)

> but you also get complaints about this being an obsolete option.

It may be a good idea to make these CONFIG_ARM2 CONFIG_ARM3 CONFIG_ARMx
as thats one way to be sure the compiler isnt going to bite you again
in the future.

> not an ARM specific change there's no need to make another copy of the

Also pass the changes to 8390.c on to its maintainer (Paul Gortmaker)
and to me. I've no idea if your 8390 changes are go faster items or
not but the original 8390 and some of the clones are incredibly touchy
about how they are prodded which is one reason the linux driver isnt
absoutely optimised.

There should be nothing now other than the Apple Mac which can't use
the generic 8390.c (and the fixes for that will get merged soon).

Alan

---

From: Philip Blundell <[email-masked]>
Date: Thu, 25 Dec 1997 18:16:02 -0500 (EST)

> as thats one way to be sure the compiler isnt going to bite you again

That's true.  In fact we already have a config option for CPU family, and
the precise CPU is detected at boot time, so I suspect these conditionals
are superfluous.

> not but the original 8390 and some of the clones are incredibly touchy

Actually, the change in question that Russell made was just replacing the
irq2dev_map[] with the dev_id parameter passed to irq handlers, and I
think this got done in 2.1 some time ago.  There may be something else I
missed though, going on his cryptic comment about `a bug' - I'll look more
closely later,

p.