public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Christer Weinigel <wingel@acolyte.hack.org>
Cc: davej@suse.de, gone@us.ibm.com, linux-kernel@vger.kernel.org,
	lse-tech@lists.sourceforge.net
Subject: Re: [RFC] modularization of i386 setup_arch and mem_init in 2.4.18
Date: 10 Mar 2002 00:27:14 -0700	[thread overview]
Message-ID: <m14rjo288d.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200203082108.g28L8I504672@w-gaughen.des.beaverton.ibm.com> <20020308223330.A15106@suse.de> <20020308234811.3F003F5B@acolyte.hack.org>
In-Reply-To: <20020308234811.3F003F5B@acolyte.hack.org>

Christer Weinigel <wingel@acolyte.hack.org> writes:

> Dave Jones <davej@suse.de> wrote:
> >  As a sidenote (sort of related topic) :
> >  An idea being kicked around a little right now is x86 subarch
> >  support for 2.5. With so many of the niche x86 spin-offs appearing
> >  lately, all fighting for their own piece of various files in
> >  arch/i386/kernel/, it may be time to do the same as the ARM folks did,
> >  and have..
> > 
> >   arch/i386/generic/
> >   arch/i386/numaq/
> >   arch/i386/visws
> >   arch/i386/voyager/
> >   etc..
> 
> Yes please.  I've been working with at least 4 different National
> Semiconductor Geode based designs so far, and they will get more and
> more common I belive.  It'd be nice not having to crap in the rest of
> the i386 tree just because one system has its own bootloader or
> special motherboard.
> 
> I just got my SC2200 based board booting with LinuxBIOS, so I'll
> probably have to do a special kernel initialization that does some
> board-specific setup since there is no BIOS to do that.

O.k. On the LinuxBIOS front it will take a little more work but we should
be able to have the LinuxBIOS table report the presence of the devices
that need to be configured, and possibly some motherboard specific configuration
for those devices (Think of irq routing).   All of which should reduce
strange motherboard configuration to the general device driver problem.

> >  The downsides to this:
> >  - Code duplication.
> >    Some routines will likely be very similar if not identical.
> >  - Bug propagation.
> >    If something is fixed in one subarch, theres a high possibility
> >    it needs fixing in other subarchs
> 
> Couldn't this be done with a common subroutine library, such as
> arch/i386/common that contains code to set up the interrupt controller
> and such.  The PC platform code just includes everything, other
> platforms could be a bit more choosy, have its own bootloader and
> memory detection code and just skip the BIOS calls.

I have just posted a patch that does the heavy lifting needed to make
using a 32bit entry point possible.  It allows skipping of the 16bit
bios calls.  With that patch in place it becomes trivial to query
the data from LinuxBIOS instead of the PCBIOS.

Eric


  parent reply	other threads:[~2002-03-10  7:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-08 21:08 [RFC] modularization of i386 setup_arch and mem_init in 2.4.18 Patricia Gaughen
2002-03-08 21:33 ` Dave Jones
2002-03-08 21:34   ` Greg KH
2002-03-08 21:59   ` [Lse-tech] " Martin J. Bligh
2002-03-08 22:16     ` Dave Jones
2002-03-09  0:00       ` H. Peter Anvin
2002-03-08 23:48   ` Christer Weinigel
2002-03-09  1:15     ` Josh Fryman
2002-03-09  1:21       ` Dave Jones
2002-03-09  1:22       ` Christer Weinigel
2002-03-10  7:27     ` Eric W. Biederman [this message]
2002-03-09  7:22   ` [Lse-tech] " Christoph Hellwig
2002-03-10  7:42   ` Eric W. Biederman
2002-03-10 13:08     ` Alan Cox
2002-03-11  3:17       ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2002-03-08 22:54 James Bottomley
2002-03-11 16:51 James Bottomley
2002-03-12  3:43 ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m14rjo288d.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=davej@suse.de \
    --cc=gone@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=wingel@acolyte.hack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox