All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: James Crosby <jc4.james@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Ideal Architecture for Linux
Date: Tue, 19 Feb 2008 09:37:49 -0800	[thread overview]
Message-ID: <47BB13ED.90705@zytor.com> (raw)
In-Reply-To: <146444620802190601t63ac667cpd41d834cc98d10df@mail.gmail.com>

James Crosby wrote:
> A stack based architecture is best, it makes nested interrupts, and general
> interruptibility very easy.

If you mean stack-based register file, then that's *not* desirable; 
Linux depends on gcc which prefers a flat register file.  16 registers 
minimum.

> Two hardware stack pointers, one for kernel stack and one for user mode
> stack of each task, but maybe a third, interrupt stack.

Don't necessarily have to be hardware registers, although it speed 
things up.  Interrupt stacks are good.

> At least two corresponding processor modes, a user mode with access only
> to 'safe' instructions, and a privileged one that can do anything. But would
> additional modes for interrupt handlers and system call handlers be
> beneficial?

Not in Linux.

> I would also consider it a significant security problem if when a task enters
> the kernel, kernel data is stored on the task's user-mode stack, since the
> task could fish around beyond the end of its stack and sniff private data. (This
> is, if I understand correctly, the reason ARM system mode is unused.)
> 
> But on the other hand, if each task didn't need a separate kernel stack, then
> there could be 4k or 8k less memory use per thread.

No, it would just be in a different place.  Linux will *NOT* accommodate 
this model.

> Is it necessarily the case that the more similar to x86, the better Linux 'fits'
> the architecture?

No, the x86 is lacking quite a few key features.

Linux would prefer to have address space numbers, instructions for 
user-space memory access in kernel mode, and a larger page size (4K is 
really too small for modern multi-gigabyte machines.)

The design of the I/O infrastructure is another matter, too.

	-hpa

      reply	other threads:[~2008-02-19 17:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19 14:01 Ideal Architecture for Linux James Crosby
2008-02-19 17:37 ` H. Peter Anvin [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=47BB13ED.90705@zytor.com \
    --to=hpa@zytor.com \
    --cc=jc4.james@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.