Re: [linuxsh-dev] Preparing for 2.5

[Stuart M. <Stu...@st...>]

On Oct 12, 10:50am, mr...@0x... wrote:
> Subject: Re: [linuxsh-dev] Preparing for 2.5
> * Greg Banks <gn...@al...> on Fri, Oct 12, 2001:
> 
> > 
> >   Personally I think the runtime part of the machvec is fairly pointless;
> > it could all be compiletime instead.
> > 
> 
> Good idea.

Yes and no :-)

There were two main objectives I had when writing the mach_vec stuff:

 - to better separate the board, chip and CPU specific details

   The source code was and is growing a large number of board, chip and
   CPU specific ifdefs, and given that there are few standards SH based
   systems need to follow, this is probably going to get worse.

   The mach_vec is a useful way of enforcing this separation, and should
   make it easier for someone who is not an experienced kernel hacker to
   get the kernel up and running on some new hardware.

   Hopefully most people would agree this is a 'good thing'.   
   
 - to allow a single kernel to be run on several boards. 

   Whether this is useful probably depends a lot on your viewpoint. I had
   two audiences in mind when I did it:

    * the kernel developer who has two or more boards, and wants to be able
      to easily swap between them without having to recompile.

    * the novice user who wants to download a binary kernel and run it, in
      the same way as the do for a 'PC', in particular people who want to
      run Linux on a WinCE/PocketPC Handheld PC PDA.

   I suspect the second catagory is now diminishingly small, as ARM and
   MIPS appear to dominate the HPC market, and most Linux/SH users
   are now working on embedded systems or a single very specific platform
   (Dreamcast and the PocketPenguin guys spring to mind). So this just
   leaves the kernel developers.

   Currently I have to support 2 SH4 variants on 5 different boards, so
   having a single kernel which would run on all of them would be great.
   As well as saving a lot of compilation time, it would make it much
   easier to see if a particular behaviour exhibits itself on different
   hardware, without the problem of using a different kernel binary which
   was built with different options, which may in itself affect the
   behaviour.

   Of course there are limitations with the current system, some soluable
   (where memory is) and some probably not (endianness). And there is a
   (very?) small performance penalty, so I would always want to keep the
   option of building a 'specific' rather than a generic kernel.

   So, are my needs so specific that I'm the only person who would use it,
   or would other people - assuming some of the current limitations could
   be fixed?

Personally I think we need to do another purge of the board specific
#ifdef's from C code (some of which I admit to being responsable for),
and if some other #ifdef's could be removed at the same time, so much the
better.

However whether this involves expanding the mach_vec, or just moving them
into header files and Makefiles probably depends on what we want to do about
the generic kernel support. Personally I like it (but then I would!), but it
does need fixing and maintaining, so if nobody is going to use it we should
probably move to a static system, more like ARM, rather then the current
dynamic scheme which is modelled on the Alpha code.

Sorry about the long ramble, I'll let someone else get their oar in now.

Stuart