From: "Henrik Rydberg" <rydberg@euromail.se>
To: david@lang.hm
Cc: Bobby Powers <bobbypowers@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
Greg KH <gregkh@linuxfoundation.org>,
Guenter Roeck <guenter.roeck@ericsson.com>,
Jidong Xiao <jidong.xiao@gmail.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Can we move device drivers into user-space?
Date: Mon, 27 Feb 2012 01:01:29 +0100 [thread overview]
Message-ID: <20120227000129.GA2265@polaris.bitmath.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1202261503320.4108@asgard.lang.hm>
Hi David,
> the point that you seem to be missing is that the interfaces between
> the different areas of the kernel are not stable, they change over
> time.
The argument was based on the idea that they would stabilize over
time. However, I realize this may not be true, which was also touched
upon in a later reply. The heavy-tailed nature of large changes in
open-source projects seems to put some hard numbers behind that claim [1].
> When both sides of the interface are in the kernel, this is
> not a problem, both sides get changed, but if one side was out of
> the kernel, then you either can't make the change, or have a flag
> day change where both sides need to change in lock-step (and
> downgrading is hard as both sides need to change again)
Assuming the interfaces changes, this follows naturally, of course.
> This is completely ignoring the performance and security aspects of
> userspace components vs kernel components.
Indeed.
> Ted is explaining the performance aspects well, but let's look at
> the security aspects as well.
>
> It's not just a case of "if something in userspace crashes, it
> doesn't crash the kerenl", it's also a case that "if you have a
> userspace component, then the kernel must sanity check the userspace
> interface to defend against rogue userspace". Doing these checks is
> not cheap (adding to performance overhead), and may not even be
> possible (how do you know if the command being sent to the SCSI bus
> is safe or not?)
No doubt, an open-ended system has its own set of problems. At any
given system size, the question is how this balances against a closed
system. The assumption I made was that as the system grows, the
balance would shift in favor of an open-ended system. This may not be
the case at all, as you are saying. It would be nice to be able to see
this in a quantitative manner if possible.
Thanks for taking the time to respond.
Henrik
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.91.7114
next prev parent reply other threads:[~2012-02-27 0:01 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 4:56 Can we move device drivers into user-space? Jidong Xiao
2012-02-23 15:57 ` Cong Wang
2012-02-23 16:34 ` Jidong Xiao
2012-02-23 20:48 ` david
2012-02-23 21:01 ` Jidong Xiao
2012-02-24 18:21 ` Mauro Carvalho Chehab
2012-02-25 15:10 ` Eduard - Gabriel Munteanu
2012-02-26 0:06 ` Mauro Carvalho Chehab
2012-02-26 0:29 ` Richard Yao
2012-02-27 11:31 ` Mauro Carvalho Chehab
2012-02-26 1:58 ` Dr. David Alan Gilbert
2012-02-26 3:34 ` arts zhao
2012-02-27 11:29 ` Mauro Carvalho Chehab
2012-02-25 15:31 ` Richard Yao
2012-02-23 21:18 ` Roland Dreier
2012-02-24 15:19 ` Jidong Xiao
2012-02-24 15:38 ` Greg KH
2012-02-24 16:38 ` Jidong Xiao
2012-02-24 16:54 ` Greg KH
2012-02-24 17:06 ` Jidong Xiao
2012-02-24 17:13 ` Greg KH
2012-02-24 17:21 ` Jidong Xiao
2012-02-24 17:31 ` Greg KH
2012-02-25 2:33 ` Richard Yao
2012-02-25 4:28 ` Jidong Xiao
2012-02-24 17:10 ` Al Viro
2012-02-25 19:23 ` Jidong Xiao
2012-02-25 20:55 ` Greg KH
2012-02-25 23:43 ` Jidong Xiao
2012-02-26 17:40 ` Greg KH
2012-02-26 22:46 ` Greg KH
2012-02-27 11:17 ` Bernd Petrovitsch
2012-02-24 17:07 ` Guenter Roeck
2012-02-24 17:17 ` Greg KH
2012-02-24 17:47 ` Guenter Roeck
2012-02-24 18:34 ` Greg KH
2012-02-24 19:15 ` Henrik Rydberg
2012-02-24 19:26 ` Greg KH
2012-02-24 20:10 ` Henrik Rydberg
2012-02-24 20:16 ` Greg KH
2012-02-24 20:37 ` Henrik Rydberg
2012-02-24 20:56 ` Greg KH
2012-02-24 21:22 ` Henrik Rydberg
2012-02-24 21:30 ` Ted Ts'o
2012-02-24 22:14 ` Henrik Rydberg
2012-02-24 22:20 ` Greg KH
2012-02-24 22:49 ` Henrik Rydberg
2012-02-24 22:54 ` Greg KH
2012-02-24 23:14 ` Henrik Rydberg
2012-02-25 12:15 ` Theodore Tso
2012-02-26 9:54 ` Henrik Rydberg
2012-02-26 4:56 ` Bobby Powers
2012-02-26 10:47 ` Henrik Rydberg
2012-02-26 12:26 ` Richard Yao
2012-02-26 14:23 ` Bernd Petrovitsch
2012-02-26 15:29 ` Henrik Rydberg
[not found] ` <365b85cee33d4f1aadc31336663de21c@HUBCAS2.cs.stonybrook.edu>
2012-02-26 15:05 ` Richard Yao
2012-02-26 20:30 ` Ted Ts'o
[not found] ` <09a5cca9cffb4300843f682be529e8ca@HUBCAS2.cs.stonybrook.edu>
2012-02-26 21:25 ` Richard Yao
2012-02-26 21:35 ` Theodore Tso
[not found] ` <10de0ef9fb5d44c08669191e12343a97@HUBCAS2.cs.stonybrook.edu>
2012-02-26 22:03 ` Richard Yao
2012-02-27 11:17 ` Bernd Petrovitsch
2012-02-26 23:08 ` david
2012-02-27 0:01 ` Henrik Rydberg [this message]
2012-02-27 0:53 ` david
2012-02-27 9:07 ` Henrik Rydberg
2012-03-01 9:54 ` Thomas Gleixner
2012-02-24 15:58 ` Valdis.Kletnieks
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=20120227000129.GA2265@polaris.bitmath.org \
--to=rydberg@euromail.se \
--cc=bobbypowers@gmail.com \
--cc=david@lang.hm \
--cc=gregkh@linuxfoundation.org \
--cc=guenter.roeck@ericsson.com \
--cc=jidong.xiao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).