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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 26 Feb 2012 16:53:58 -0800 (PST)
From:	david@...g.hm
To:	Henrik Rydberg <rydberg@...omail.se>
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?

On Mon, 27 Feb 2012, Henrik Rydberg wrote:

> 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].

What you are hearing from the long-time kernel developers is that they 
expect the interfaces to change over time.

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.

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.

David Lang
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ