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: <20090326122003.5f6f608c.akpm@linux-foundation.org>
Date:	Thu, 26 Mar 2009 12:20:03 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Frans Pop <elendil@...net.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>, mingo@...e.hu,
	tytso@....edu, jack@...e.cz, alan@...rguk.ukuu.org.uk,
	arjan@...radead.org, a.p.zijlstra@...llo.nl, npiggin@...e.de,
	jens.axboe@...cle.com, drees76@...il.com, jesper@...gh.cc,
	linux-kernel@...r.kernel.org, oleg@...hat.com, roland@...hat.com
Subject: Re: relatime: update once per day patches (was: ext3 IO latency
 measurements)

On Thu, 26 Mar 2009 18:49:00 +0000 Matthew Garrett <mjg@...hat.com> wrote:

> On Thu, Mar 26, 2009 at 10:48:43AM -0700, Andrew Morton wrote:
> 
> > Oh, the feature itself is desirable.  But the interface isn't.
> > 
> > - It's a magic number.  Maybe someone runs tmpwatch twice per day, or
> >   weekly, or...
> 
> There has to be a default. 24 hours is a sensible one.

"default" implies that it can be altered by some means.

> When did we adopt a mindset that led to code having to satisfy every 
> single user requirement before being accepted, rather than being happy 
> with code that provides an incremental improvement over what exists 
> already?

Shortcomings have been identified.  Weaselly verbiage is not a suitable
way of addressing shortcomings!

Yes, we could (and do) merge things as a halfway step.  But when the
features are visible to userspace we just can't do that - we have to
get the interface right on day one, because interfaces are for ever.

(Bear in mind that kernel-does-X-once-per-day _is_ an interface)

> If there are actually users who want to be able to tune this 
> per filesystem then I'm sure someone (possibly even me) will write code 
> to support them, but right now it just sounds like features for the sake 
> of some sense of aesthetic correctness.

A hard-wired global 24-hours constant is in no way superior to a
per-mount tunable.  If we're going to do this we should do it in the
best way we know, and we certainly should not lock ourselves into the
inferior implementation for all time by exposing it to userspace.
--
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