public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Ivan Godard" <igodard@pacbell.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel support for peer-to-peer protection models...
Date: Mon, 29 Mar 2004 01:14:16 +0200	[thread overview]
Message-ID: <20040329011416.591ad315.ak@suse.de> (raw)
In-Reply-To: <07b501c41502$48bd4d20$fc82c23f@pc21>

On Sun, 28 Mar 2004 12:21:36 -0800
"Ivan Godard" <igodard@pacbell.net> wrote:

> 
> > Maybe you can give each process an different address range, but AFAIK
> > the only people who have done this before are users of non MMU
> architectures.
> > It will probably require som changes in the portable part of the code.
> > Also porting glibc's ld.so to this will be likely no-fun.
> 
> Each process gets a different range because each process gets a different
> native space. Within that space processes can use the same offsets, and
> typically will so as to avoid pointless relocation.

fork() will be hard and/or inefficient this way.

> > Overall it sounds like your architecture is not very well suited to
> > run Linux.
> 
> We believe we can adopt the Linux protection model (i.e. the 386 protection
> model) with no more work than any other port to a new architectire (ahem).

Just FYI - Linux has been ported to several architectures with similar SASOS
capabilities in hardware (IA64 or ppc64 on iseries) and they have all opted to use 
an conventional protection model.

> So long as 1) a driver has a driver-load-time defined region of working data
> space; 2) has a defined code region; 3) gets its buffer addresses etc. as

Just (1) alone is a illusion - linux drivers generally work on the shared
page pool, just like all other subsystems. 

-Andi


  reply	other threads:[~2004-03-29  4:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <048e01c413b3$3c3cae60$fc82c23f@pc21.suse.lists.linux.kernel>
2004-03-27  6:29 ` Kernel support for peer-to-peer protection models Andi Kleen
2004-03-28 20:21   ` Ivan Godard
2004-03-28 23:14     ` Andi Kleen [this message]
2004-03-29  8:09       ` Ivan Godard
2004-03-29 15:36       ` Pavel Machek
2004-03-30 14:06         ` Andi Kleen
2004-03-30 15:09         ` Ivan Godard
     [not found] <048e01c413b3_3c3cae60_fc82c23f@pc21>
2004-03-27 10:34 ` Pavel Machek
2004-03-28  1:32   ` Ivan Godard
2004-03-28  6:24     ` Pavel Machek
2004-03-28  6:32       ` Ivan Godard
2004-03-28 18:54         ` Pavel Machek
2004-03-28 19:56           ` Ivan Godard
2004-03-28 20:35             ` Pavel Machek
2004-03-27  4:23 Ivan Godard
2004-03-29  0:17 ` Paul Mackerras
2004-03-29  3:18   ` Ivan Godard
2004-03-29  3:48     ` Davide Libenzi
2004-03-29  7:52       ` Ivan Godard
2004-03-29 18:45         ` Davide Libenzi
2004-03-29 20:53           ` Ivan Godard

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=20040329011416.591ad315.ak@suse.de \
    --to=ak@suse.de \
    --cc=igodard@pacbell.net \
    --cc=linux-kernel@vger.kernel.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