lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 26 Feb 2012 15:23:42 +0100
From:	Bernd Petrovitsch <bernd@...rovitsch.priv.at>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Richard Yao <ryao@...stonybrook.edu>,
	Bobby Powers <bobbypowers@...il.com>,
	"Ted Ts'o" <tytso@....edu>, Greg KH <gregkh@...uxfoundation.org>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Jidong Xiao <jidong.xiao@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Can we move device drivers into user-space?

On Son, 2012-02-26 at 07:26 -0500, Richard Yao wrote:
> On Sun, Feb 26, 2012 at 5:47 AM, Henrik Rydberg <rydberg@...omail.se> wrote:
[...]
> > changed, is unimportant. Maybe code, like so many other things,
> > arranges itself in a scale-free critical fashion, which would forever

"Code arranges" not itself, but people arrange code the best they see
fit.

> > warrant a monolithic approach. Maybe it would even make sense to have

And the Linux kernel is BTW not really that monolitic in the spirit of
the definition of Tanenbaums book. It's just the category that sucks the
least there.

> > userspace join the same tree as well. There is however a frofoundly
> > political aspect here, which cannot be expressed in terms of
> > code. Also, in practise, breaking things down into manageable chunks
> > is usually a good idea in the end.

Yes, everybody learns that in the first lecture on programming. Please
sent patches to make actually things better and not just talk. Thank
you.

> I do not see what prevents an in-kernel context switch into a ring 3
> context with a different process address space. Is it necessary to
> remove the code from the kernel tree before someone can do this?

No, and that's the real problem here: Everybody who might think it's a
good idea may please implement - and thus propose - something concrete,
try it out and comeback with experience and performance numbers - and
not just try to come up with some theory and other misleading points
(what political aspect?!) and ideas what others should do and why it
might be better.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@...rovitsch.priv.at
                     LUGA : http://www.luga.at

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists