public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: wingel@t1.ctrl-c.liu.se, hpa@zytor.com, robert@schwebel.de,
	linux-kernel@vger.kernel.org, jason@mugwump.taiga.com,
	anders@alarsen.net, rkaiser@sysgo.de
Subject: Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch
Date: 05 Jan 2002 05:23:58 -0700	[thread overview]
Message-ID: <m1sn9lt28x.fsf@frodo.biederman.org> (raw)
In-Reply-To: <E16Lh1Z-0003Go-00@the-village.bc.nu>
In-Reply-To: <E16Lh1Z-0003Go-00@the-village.bc.nu>

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > There is the basic Cx5530 chipset, which could have support in the
> > Linux kernel (IDE, graphics and sound).
> 
> It already does. Has done for ages. The non SB emulation mode of the audio
> is not supported but that I don't think matters.
> 
> > for all chips, some are specific for a variant, such as the video
> > input port and graphics overlay/genlock.
> 
> X11
> 
> In general if we want to support lots of weird crap then the ARM folks have
> a very nice model and a lot of weird crap to have developed their ideas
> against. Personal preference
> 
> 	Type of system	(PC, Embedded)
> 
> then for PC leave as is, for embedded
> 	
> 	Board type (blah, blah , blah)
> 	Firmware (PC BIOS, LinuxBIOS, RedBoot)

A couple of thoughts on this. 

With LinuxBIOS it is one of my design goals that you not need to know
the board type.  Plus I frequently run kernels that allow me to boot
with either LinuxBIOS or a PC BIOS, as that makes reverse engineering
easier.

Further in cases where we actually control the firmware (LinuxBIOS,
RedBoot?) it makes sense to have the firmware pass us configuration
values for places where it deviates from the norm.  This doesn't incur
any extra firmware overhead as firmware is already board specific, and
with flash chips it is easy enough to update.  The linux kernel then
would just need to handle a new configuration option.

For the truly weird, horrible or expedient cases we probably want to
have the choice be 
       Type of system (PC, Dedicated).  
I believe dedicated describes the category better.  Embedded refers to
computers in small hidden places.  Where dedicated just means a
computer setup that doesn't need to handle the general case.  That
plus I have trouble seeing a SGI workstation, or a 512 node cluster
running LinuxBIOS as an embedded system :)

Having Board type under dedicated/embedded sounds quite reasonable.
And for weird things like LinuxBIOS it probably makes sense to at
least develop their support under something like dedicated.  And only
if it becomes more general purpose move it out of there.

I'm thinking this through carefully as I'm getting close to doing
figuring out what I need to do to get LinuxBIOS support into the
kernel.  The structure is finally starting to look good enough that
this is reasonable. 

Eric

  parent reply	other threads:[~2002-01-05 12:27 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-21 21:26 AMD SC410 boot problems with recent kernels Robert Schwebel
2001-12-21 22:09 ` H. Peter Anvin
2001-12-22 16:13   ` Robert Schwebel
2001-12-23  1:44     ` H. Peter Anvin
2001-12-23  9:45       ` Robert Schwebel
2001-12-23 10:19         ` H. Peter Anvin
2001-12-23 13:16         ` Christer Weinigel
2001-12-23 20:02           ` H. Peter Anvin
2001-12-30 22:02             ` Robert Schwebel
2001-12-30 23:15               ` H. Peter Anvin
2002-01-01 12:30 ` [PATCH][RFC] AMD Elan patch Robert Schwebel
2002-01-01 21:49   ` H. Peter Anvin
2002-01-01 23:27     ` Robert Schwebel
2002-01-01 23:38       ` H. Peter Anvin
2002-01-02  0:05         ` Dave Jones
2002-01-02  0:45           ` H. Peter Anvin
2002-01-02 13:49           ` Robert Schwebel
2002-01-02 14:03             ` Dave Jones
2002-01-02 16:10               ` Alan Cox
2002-01-02 22:40                 ` H. Peter Anvin
2002-01-02 23:10                   ` Alan Cox
2002-01-02 23:02                     ` H. Peter Anvin
2002-01-02 23:50                       ` Alan Cox
2002-01-03  9:04                       ` Robert Schwebel
2002-01-02 23:56                     ` Robert Kaiser
2002-01-03  0:10                       ` Alan Cox
2002-01-03  8:52                   ` Robert Schwebel
2002-01-02 16:06             ` Alan Cox
2002-01-02 16:56               ` Robert Schwebel
2002-01-02 17:26                 ` Robert Schwebel
2002-01-02 23:06                   ` Peter Wächtler
2002-01-02 23:21                     ` H. Peter Anvin
2002-01-02  1:07         ` [RFC] Embedded X86 systems Was: " Christer Weinigel
2002-01-02  8:45           ` Alan Cox
2002-01-02  9:05             ` Christer Weinigel
2002-01-02  9:18               ` Alan Cox
2002-01-05 12:23             ` Eric W. Biederman [this message]
2002-01-02  0:06     ` Christer Weinigel
2002-01-02  0:48       ` H. Peter Anvin
2002-01-02  1:10         ` Christer Weinigel
2002-01-02 13:58           ` Robert Schwebel
2002-01-02 20:47             ` Christer Weinigel
2002-01-02 13:55       ` Robert Schwebel
2002-01-02 15:54   ` Robert Schwebel
2002-01-11  9:38   ` [PATCH] " Robert Schwebel
2002-01-21  7:28     ` New version of " Robert Schwebel
2002-01-21 20:44       ` Marcelo Tosatti
2002-01-24  8:09       ` Robert Schwebel
2002-01-24  8:39         ` Robert Schwebel
2002-01-23 10:28     ` [PATCH] " Robert Schwebel
2002-01-23 21:30       ` Marcelo Tosatti
2002-01-22 14:47   ` [PATCH][RFC] " Robert Schwebel
2002-01-22 18:01     ` Dave Jones
2002-01-22 22:55   ` New version of AMD Elan patch available Robert Schwebel
2002-02-01 22:01     ` Robert Schwebel

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=m1sn9lt28x.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anders@alarsen.net \
    --cc=hpa@zytor.com \
    --cc=jason@mugwump.taiga.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rkaiser@sysgo.de \
    --cc=robert@schwebel.de \
    --cc=wingel@t1.ctrl-c.liu.se \
    /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