Subject: Re: CVS [email-masked]: linux

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 21 Jul 2003 12:49:55 +0200 (MET DST)

On Mon, 21 Jul 2003 [email-masked] wrote:

> Modified files:
> 	arch/mips      : Makefile 
> 	arch/mips/mm   : Makefile 
> 	arch/mips64    : Makefile 
> Added files:
> 	arch/mips/mm   : tlb-andes.c 
> 	arch/mips/mm-32: Makefile c-sb1.c c-tx39.c cex-gen.S fault.c 
> 	                 init.c pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips/mm-64: .cvsignore Makefile c-sb1.c fault.c init.c 
> 	                 pg-r4k.c pg-sb1.c tlb-dbg-r4k.c tlb-glue-r4k.S 
> 	                 tlb-glue-sb1.S tlb-r4k.c tlb-sb1.c tlbex-r4k.S 
> Removed files:
> 	arch/mips/mm   : c-sb1.c c-tx39.c cex-gen.S fault.c init.c 
> 	                 pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips64/mm : .cvsignore Makefile c-r4k.c c-sb1.c cache.c 
> 	                 cerr-sb1.c cex-sb1.S extable.c fault.c init.c 
> 	                 loadmmu.c pg-r4k.c pg-sb1.c pgtable.c sc-ip22.c 
> 	                 sc-r5k.c sc-rm7k.c tlb-andes.c tlb-dbg-r4k.c 
> 	                 tlb-glue-r4k.S tlb-glue-sb1.S tlb-r4k.c 
> 	                 tlb-sb1.c tlbex-r4k.S 
> 
> Log message:
> 	Coarsly sort out 32-bit-only, 64-bit-only and ``portable'' MIPS memory
> 	managment code.  Another few thousand lines of code bite the dust and
> 	it could be even more ...

 Any justifiable reason for getting rid of arch/mips64?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Mon, 21 Jul 2003 14:12:07 +0200

>  Any justifiable reason for getting rid of arch/mips64?

In my opinion, it should never have existed.  The vast majority
of MIPS-specific kernel code can be identical for 32-bit and 64-bit
versions of the architecture.  Creating arch/mips64 (as opposed
to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
of modules that then needed to be maintained in parallel - but which 
often were not.

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 21 Jul 2003 16:42:14 +0200

>  Any justifiable reason for getting rid of arch/mips64?

Code duplication.  Thousands of lines.  I'm fedup of maintaining several
copies of a large number of files.  And stupid patches that keep forcing
things out of sync.  Multiply that pain with 2 for 2.4 and 2.6.  Not fun.

Btw, s390 also merged their two 32-bit and 64-bit architecture flavors
again; similar for parisc; it has been considered for x86-64 also.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 21 Jul 2003 16:44:50 +0200

> of modules that then needed to be maintained in parallel - but which 

In retroperspective it was a good think to start with and allowed us to
do some of the really intrusive change necessary without disturbing
the 32-bit stuff.  Now that things are settling down it's time to cleanup.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 21 Jul 2003 17:50:08 +0200 (MET DST)

> of modules that then needed to be maintained in parallel - but which 

 Well, duplication is certainly undesireable, but is it the result of
separate arch/mips and arch/mips64 trees or is it a side effect only? 
These separate trees have an advantage of a clear distinction between
these architectures.  And arch/sparc vs arch/sparc64 were the first case
of such a split and they seem to feel quite well. 

 I'd rather keep arch/mips/{lib,mm} and arch/mips64/{lib,mm} where they
used to be and add, say, arch/mips/{lib,mm}-generic for common stuff.

---

From: Keith M Wesolowski <[email-masked]>
Date: Mon, 21 Jul 2003 11:20:02 -0700

> of such a split and they seem to feel quite well. 

sparc32 and sparc64 processors and systems are significantly
different.  For example, the SRMMU present in v8 CPUs is 100% replaced
with a totally different MMU (indeed, totally different instructions,
access methods, etc) in v9.  Accordingly there is very little code in
common between the two ports, and most of that is in device handling;
code that is in drivers/sbus and thus shared anyway.

Something that made sense for sparc might not make sense for mips.

-- 
Keith M Wesolowski <[email-masked]> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 21 Jul 2003 23:14:02 +0200

> used to be and add, say, arch/mips/{lib,mm}-generic for common stuff. 

Technically these are probably equivalent.  I just felt having mm-32 and
mm-64 makes it more explicit that something can't be shared but really,
that's just directory names and I don't feel strong about them.
I even have some hope that with continuing cleanup mm-32 and mm-64, which
are supposed to contain only things that due to conflicts can't live in
mm, will finally become empty.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 22 Jul 2003 21:39:40 +0200 (MET DST)

> code that is in drivers/sbus and thus shared anyway.

 Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
completely different from the one in later ones, too.  I suspect this is
true for the R6k as well.  The exception handlers differ a bit as well,
especially considering the XTLB refill one.  That probably counts as
nitpicking, though... 

> Something that made sense for sparc might not make sense for mips.

 Certainly it needs to be analysed on a case by case basis, avoiding
blanket assumptions.  Anyway, I still see two reasons for having at least
a separate top-level directory:

1. A better separation of the more straightforward 32-bit Makefile and the
more complicated 64-bit one.

2. A better visual existence of the 64-bit port; not really a technical
advantage, but more a psychological one.  It stops any newcomer wondering
whether we support 64-bit systems natively or not. 

 There is also no point in having headers in asm-mips consisting of a
single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
versions should be present in asm-mips and asm-mips64, respectively.  It's
easier to make a diff between such separate implementations to verify
everything's OK. 

  Maciej

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 22 Jul 2003 21:40:47 +0200 (MET DST)

> mm, will finally become empty.

 If that's going to happen, a removal of arch/mips64/mm does make sense,
indeed.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 22 Jul 2003 23:21:17 +0200

> especially considering the XTLB refill one.  That probably counts as

It's also a question of taste - and that one can be discussed forever.
How far do you want to factor our common code, as little as possible
which was our previous approach or extremly aggressive, glibc-like.

And yes, the R6000 is different.  With that in mind R2000 and R4000 look
like enzygotic twins ...

> whether we support 64-bit systems natively or not. 

I was thinking about that also.  arch/mips64 and include/asm-mips64 will
go away but on the other side there will be an option to configure a
64-bit kernel in the menus - which will hopefully be more visible than
just two subdirectories.

> easier to make a diff between such separate implementations to verify

Like 80% of the headers could be identical between both files without
lots of trickery.  The current approach is have two physical copies of
these identical files.

Btw, an old experience repeats - some of the code was identical except
inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
I rewrote that stuff to use C for this arithmetic.  The result - less
inline assembler, more readable code and a file that's identical for
both 32-bit and 64-bit.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 22 Jul 2003 23:37:44 +0200 (MET DST)

> And yes, the R6000 is different.  With that in mind R2000 and R4000 look

 ;-)

> 64-bit kernel in the menus - which will hopefully be more visible than

 Well, as long as one get that far to run a configuration script (BTW,
what menus are you referring to? -- I haven't seen any).  Right now that's
easily visible straight in the archive which is now even browsable in the
Internet here and there -- Q: "What architectures are supported?" A: "See
the subdirectories of arch/." 

> inline assembler, more readable code and a file that's identical for

 Well, whatever is plain C code (or should be such) should be identical,
indeed, but macros will differ as will low-level assembly.  Then add
64-bit specific options and you get yet more complication. 

 I hope `uname -m' will continue to report the correct architecture and
that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
and "mips64" a 64-bit one) -- have you considered this?

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 22 Jul 2003 23:47:43 +0200 (MEST)

> what menus are you referring to? -- I haven't seen any).  Right now that's

It will flash up on your retina and stay there for a while, waiting for your
response, if you run `make oldconfig' :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 23 Jul 2003 00:51:37 +0200 (MET DST)

> response, if you run `make oldconfig' :-)

 Hmm, now I have to speed up my transition to 2.6 to have my curiosity
appeased...  Hopefully I won't get disappointed.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 30 Jul 2003 04:12:50 +0200

> appeased...  Hopefully I won't get disappointed.

Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
evolution than revolution ...

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 30 Jul 2003 05:16:31 +0200

> 64-bit specific options and you get yet more complication. 

You're right, we've got a good bit of assembler code that should just be
C.  So I rewrote some of the code to C.

> and "mips64" a 64-bit one) -- have you considered this?

Not intend to change the behaviour of uname.  It actually changed in CVS,
for now consider that a bug ...

We should consider changing the behaviour though.  A machine type of
mips64 broke lots of software.  Of course that was all 32-bit softare but
it raises the question if returning mips64 is really a good idea?

As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
be choosen like every other config option.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 30 Jul 2003 09:47:34 +0200 (MET DST)

> evolution than revolution ...

 I'm referring to that menus that will flash up on my retina (if I got the
meaning right). ;-)

 Anyway, it looks like some additional checks and possibly fixes will be
needed for 64-bit configurations (including changes to my pending
patches).  And last time I checked 2.5.x had showstopper problems for me
elsewhere (IDE -- I still use it here and there) -- I doubt they have been
fixed in the recent 2.6 -test releases.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 30 Jul 2003 09:55:26 +0200 (MET DST)

> for now consider that a bug ...

 OK, I will.

> it raises the question if returning mips64 is really a good idea?

 Yes it is.  It is the only way to check if the kernel is 32-bit or 64-bit
and config.guess needs it for guessing the canonical system name.  That,
plus checking the default ld emulation lets it (or will let, once written)
select what is the proper default native configuration: 
mips{,el}-unknown-linux-gnu, mips64{,el}-unknown-linux-gnu-abin32 or
mips64{,el}-unknown-linux-gnu-abi64. 

> be choosen like every other config option.

 Well, I liked the `make "ARCH=mips64"' way, but I suppose I'll have to
live with your change, sigh...

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 30 Jul 2003 16:05:54 +0200

> > for now consider that a bug ...

Fix is in CVS.

> live with your change, sigh... 

Well, that was one of the things that were handy at times.  Considering
the patch I sent to Linus yesterday to Linus did remove 41010 lines of code
that was a tiny price to pay.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 30 Jul 2003 16:07:48 +0200

On Wed, Jul 30, 2003 at 09:47:34AM +0200, Maciej W. Rozycki wrote:

> > > > It will flash up on your retina and stay there for a while, waiting
> > > > for your response, if you run `make oldconfig' :-)
> > > 

Oh :-)

> fixed in the recent 2.6 -test releases. 

True, 2.6 isn't yet a great stability experience ...

  Ralf