ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@gentwo.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Redesign Memory Management layer and more core subsystem
Date: Mon, 16 Jun 2014 09:04:53 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1406160901480.9480@gentwo.org> (raw)
In-Reply-To: <539BA32A.8090104@lougher.demon.co.uk>

On Sat, 14 Jun 2014, Phillip Lougher wrote:

> Embedded systems have long had the need to carve out (mainly heterogenous)
> processors from Linux.  Media systems have VLIW media processors (i.e.
> Philips Trimedia), and mobile phones typically have separate baseband
> processors.  This is done without any core support necessary from the kernel.
> Just write a device driver that presents a programming & I/O channel
> to the carved out hardware.

Well but this is bad because kernel services may be needed by these carved
out processors. If the kernel would support this then life would be much
easier for you.

> Additionally, where Linux kernel has been too heavy weight with its
> slow real-time response, and/or expensive paged multi-address spaces, the
> solution is often to use a nano-kernel like ADEOS or RTLinux,
> running Linux as a separate OS, leaving scope to run lighter weight
> real-time single address operating systems in parallel.

Having hardware and software that is handled by two differnt OSes is
pretty complex. Shoving something like that into the Linux kernel should
be pretty easy because most of the infrastructure is already there.

> My point about the hardware engineer is people can't have their cake
> and eat it.  Unix/Linux has been successful partly because of its
> strong protection/paged model.  It is difficult to be both secure
> and efficient.  If you want to both then you need to design
> it into the operating system from the outset.  Linux isn't a good
> place to start.

I think we can if we allow cores to run with simplified support and
reduced overhead.

      reply	other threads:[~2014-06-16 14:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11 19:03 Christoph Lameter
2014-06-11 19:26 ` Daniel Phillips
2014-06-11 19:45 ` Greg KH
2014-06-12 13:35   ` John W. Linville
2014-06-13 16:57     ` Christoph Lameter
2014-06-13 17:31       ` Greg KH
2014-06-13 17:59         ` Christoph Lameter
2014-06-13 19:18           ` Stephen Hemminger
2014-06-13 22:30             ` Christoph Lameter
2014-06-13 16:56   ` Christoph Lameter
2014-06-13 17:30     ` Greg KH
2014-06-13 17:55       ` James Bottomley
2014-06-13 18:41         ` Christoph Lameter
2014-06-16 11:39           ` Thomas Petazzoni
2014-06-16 14:05             ` Christoph Lameter
2014-06-16 14:09               ` Thomas Petazzoni
2014-06-16 14:28                 ` Christoph Lameter
2014-06-13 18:01       ` Christoph Lameter
2014-06-13 18:25         ` Greg KH
2014-06-13 18:54           ` Christoph Lameter
2014-06-11 20:08 ` josh
2014-06-11 20:15 ` Andy Lutomirski
2014-06-11 20:52 ` Dave Hansen
2014-06-12  6:59 ` Phillip Lougher
2014-06-13 17:02   ` Christoph Lameter
2014-06-13 21:36     ` Benjamin Herrenschmidt
2014-06-13 22:23       ` Rik van Riel
2014-06-13 23:04       ` Christoph Lameter
2014-06-14  1:19     ` Phillip Lougher
2014-06-16 14:04       ` Christoph Lameter [this message]

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=alpine.DEB.2.11.1406160901480.9480@gentwo.org \
    --to=cl@gentwo.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=phillip@lougher.demon.co.uk \
    /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