public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joseph Pingenot <trelane@digitasaru.net>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Nigel Cunningham <ncunningham@linuxmail.org>,
	Chris Friesen <cfriesen@nortelnetworks.com>,
	Jurriaan <thunder7@xs4all.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: What does tainting actually mean?
Date: Wed, 28 Apr 2004 10:56:46 -0500	[thread overview]
Message-ID: <20040428155643.GC26041@digitasaru.net> (raw)
In-Reply-To: <20040428121009.GA2844@thunk.org>

>From Theodore Ts'o on Wednesday, 28 April, 2004:
[mucho mas snipping]
>The thing we could do kernel-side is to implement full VM protections.
>This is the microkernel approach; the problem though is the
>performance overhead of having to go through protection boundaries,
>setting up kernel-module-specific VM page tables, etc., etc.  At some
>level, if people could implement these propeitary code bases in
>userspace, then there would be no need to risk corrupting internal
>data structures, and no need to "taint" the kernel.  But usually there
>are performance reasons why the driver authors choose not to go down
>that path.

Would it be possible to, instead of implementing a full vm system inside
  the kernel for device drivers, to provide a way to have the binary
  drivers be a userland process?
I'd love to be able to keep binary drivers out of my kernel, and I
  know many people harp on how hard it is to maintain binary drivers in
  the Linux kernel due to the rapid evolution of Linux (namely, how fast
  interfaces and structures change).  If there were a way to put these
  binary drivers in userspace, we could potentially solve both problems
  in one swipe, no?

-Joseph
-- 
trelane@digitasaru.net--------------------------------------------------
"We continue to live in a world where all our know-how is locked into
 binary files in an unknown format. If our documents are our corporate
 memory, Microsoft still has us all condemned to Alzheimer's."
    --Simon Phipps, http://theregister.com/content/4/30410.html

  parent reply	other threads:[~2004-04-28 15:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-28  4:00 What does tainting actually mean? Nigel Cunningham
2004-04-28  4:27 ` Jurriaan
2004-04-28  4:30   ` Nigel Cunningham
2004-04-28  5:19     ` Chris Friesen
2004-04-28  5:18       ` Nigel Cunningham
2004-04-28 12:10         ` Theodore Ts'o
2004-04-28 12:48           ` Måns Rullgård
2004-04-28 13:04             ` Muli Ben-Yehuda
2004-04-28 13:27               ` Måns Rullgård
2004-04-28 14:22                 ` Muli Ben-Yehuda
2004-04-28 15:56           ` Joseph Pingenot [this message]
2004-04-28 16:01         ` Valdis.Kletnieks
2004-05-03 12:45     ` Pavel Machek
2004-05-03 18:50       ` Stefan Smietanowski
2004-04-28  5:51 ` Karim Yaghmour
2004-04-28  6:51   ` Keith Duthie
2004-04-28 10:26   ` Ville Herva
2004-05-06 15:25 ` Anthony de Boer
     [not found] <04Apr28.020259edt.41801@gpu.utcc.utoronto.ca>
2004-04-28  6:18 ` Nigel Cunningham
2004-04-28 10:37   ` Bartlomiej Zolnierkiewicz

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=20040428155643.GC26041@digitasaru.net \
    --to=trelane@digitasaru.net \
    --cc=cfriesen@nortelnetworks.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ncunningham@linuxmail.org \
    --cc=thunder7@xs4all.nl \
    --cc=tytso@mit.edu \
    /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