[Top] [All Lists]

Re: NAPS now integrated to DECStation code... issues!

Subject: Re: NAPS now integrated to DECStation code... issues!
From: Systemkennung Linux <>
Date: Mon, 6 May 1996 16:13:08 +0200 (MET DST)
In-reply-to: <> from "Paul Antoine" at May 6, 96 10:14:32 pm
Hi all,

> > Hmm,  I've fixed a whole bunch of bugs in my newest kernels so I really
> > suggest to use them.  The kernel code has been reorganised compared with
> > 1.3.62 and this might - at least to a certain degree - make your life
> > easier though adding your patches into my kernel will be slightly more
> > work.  Head.S is still not really reorganized, but we really should do
> > this with your machine and the SGI stuff to come in mind.
> This needs doing, but I also found other issues as I tried to integrate
> the new bitags stuff into the DECStation code...

Well, so I herewith declare the discussion about the directory structure
to be opened.  How about organizing the tree as follows:

   arch/mips/kernel             generic part of the kernel.
   arch/mips/mips1              ISA dependent code
   arch/mips/decstation/mips1   machine and cpu specific code
   arch/mips/magnum/mips1       special magnum & cpu specific code

As you see there are two levels of directories with CPU specific code.  We
might search them via VPATH in Makefiles;  code in the machine & model
specific dirs will be found first and therefore has higher precedence than
the generic code.


>       Some bitags functions (for reading tags) are included in setup.c
>       and should probably be in a separate file as this is a little
>       clearer if nothing else...

>       A lot of code still assumes gross amounts of pc-ism.  The time.c
>       file is one of them... the DEC RTC is PC-compatible, but is
>       addressed as a flat set of registers... we need to modify the
>       functions in the feature structure to allow reading and writing
>       via functions instead of the half-baked macro/function approach
>       currently used in CMOS macros.

I'd like to burry the feature structure.  The structure is already almost
one screen page of code and it will get at least three or four times as
big; there will also be aditional CPU dependencies and submodel dependencies.
We should go back to plain and boring variables pointing to function or so.
Given a reasonable organisation this will be better managable than that
stoneage time 68k-ism struct feature.

>       The tags for machine hierarchy still need some work.  I propose
>       the following:

Ok, I can live with that.

> Now one thing I've noticed is that lots of these issues ought to have
> been covered in the SPARC port... but the current OS releases seem to
> be incomplete with regard to SPARC code.  Is the SPARC source tree 
> currently separate from the main Linux tree?? Should I get it to see 
> what they've done??

At least a large part of the Sparc kernel is now in Linus' tree and
therefore also in the MIPS tree.

> It also needs to be able to:
>       Get default command line from boot prom environment variable
>       Get default boot device from boot prom environment variable
>       Get default console device from boot prom environment variable
>       Lots of model-specific configuration...
> ...and to store them in DEC-specific tags.  This is pretty easy though,
> as the new config code is now in C rather than assembler. <yay!>

Yes, we're getting ol'...

> All I need to do now is integrate all this into a 1.3.97 kernel and
> release it all!


<Prev in Thread] Current Thread [Next in Thread>