linux-kernel - Re: Can we move device drivers into user-space?

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120227090717.GA3516@polaris.bitmath.org>
Date:	Mon, 27 Feb 2012 10:07:17 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	david@...g.hm
Cc:	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?

> >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].
> 
> What you are hearing from the long-time kernel developers is that
> they expect the interfaces to change over time.

That is coming through clearly.  What I find interesting is that in
addition to the authorative voice of Linux experience, there is
physical evidence that the well-known phenomenon of self-organized
criticality governs open-source code development at large. The
collective stream of patches coming from individual decisions and
real-world adaption shows the same behavior as avalanches, solar
flares and earthquakes; there is always a bigger change around the
corner. This critical phenomenon manifests itself through heavy-tailed
distributions, as reported in reference [1].  To a physicist, this is
a big deal.

Coming back to interfaces, the conclusion is that a large code tree
which exhibits these qualities is susceptible to large changes, and
can therefore adapt better.  This puts extra weight behind the notion
that Linux is doing the Right Thing.

The measurement by Wu and Holt in 2006 [1] has probably been succeeded
many times over, perhaps someone else has pointers to more recent
studies.

> Remember, the linux kernel has been around for a long time, and as a
> result, the interfaces have gone through many iterations. There is
> no reason to believe that the current version is the final one, and
> the kernel developers now expect that the current interfaces are
> _not_ going to remain the same forever, they expect that new
> technology will drive changes in these interfaces. This is
> especially true for the types of things that device drivers need.

Theory, experiment and experience seems to say the same thing, so one
simply has to agree with this point.

> Take for example locking. That is an implicit part of the interface
> to the device drivers, and is are area with a fairly high rate of
> change today. Anyone who claims that the current locking is
> 'correct' and can be depended on by an out-of-tree driver for even a
> couple of kernel releases is going to be either laughed at or
> ignored as being too ignorant to matter.
> 
> Yes, you can look around and find interfaces in the kernel that have
> not changed for a long time, but I'll bet that for every example you
> find, someone else could find an example of an interface that had
> remained unchanged for just about as long, but has changed fairly
> recently.

Obviously there is no disagreement here anymore.  And I wouldn't bet
without first computing the probability of such a change. :-)

Thanks.
Henrik
--
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/