linux-kernel - Re: [PATCH] Delete obsolete RAW driver feature.

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]

Message-ID: <20070321231935.GC9092@redhat.com>
Date:	Wed, 21 Mar 2007 19:19:35 -0400
From:	Dave Jones <davej@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andi Kleen <andi@...stfloor.org>,
	"Robert P. J. Day" <rpjday@...dspring.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...sta.de>
Subject: Re: [PATCH] Delete obsolete RAW driver feature.

On Wed, Mar 21, 2007 at 03:19:52PM -0700, Andrew Morton wrote:

 > We've given people years of notice and _some_ applications have converted
 > over to open("/dev/sda1", O_DIRECT), as they should.
 > 
 > Sure, it's a small and simple driver (now), so the cost of maintaining it
 > is low.
 > 
 > But otoh, there's no reason for it to exist, except for userspace
 > sluggishness.
 > 
 > So we can either give up, or we can push on: put a rude printk in there
 > somewhere and who knows, maybe in five years time we can finally be rid of
 > the thing.

We've actually tried to deprecate this twice. First in RHEL4, and more
recently in RHEL5.  The conversations go something like this..

Customer: app xyz doesn't work.
Us: it's using a deprecated API, it needs to be updated to use O_DIRECT
Customer: vendor says "pay us $$$$$ to go to version N+1"

Then we find out the customer can't move to N+1 because they have
some other piece of infrastructure that relies on semantics in the
old version, and screaming and hairpulling ensues.

(And this is one of the more promising conversations. Others
 that have happened with certain db vendors are enough to
 make the pope curse).

Adding printk's on open() of it doesn't solve the problem either.
The people that see them are the customers who run this stuff,
not the people who have the ability to change the code.

If it gets dropped from kernel.org, it wouldn't be long before
it'd find its way back into enterprise vendor kernels.
Isn't it better that we all at least ship the same thing? [1]

	Dave

[1] Though admittedly the one in RHEL deviates from upstream
as it contains performance enhancements that were vetoed from
upstream acceptance due to it being "deprecated".

-- 
http://www.codemonkey.org.uk
-
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/