linux-kernel - Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

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: <20101106064813.GC11535@count0.beaverton.ibm.com>
Date:	Fri, 5 Nov 2010 23:48:13 -0700
From:	Matt Helsley <matthltc@...ibm.com>
To:	Nathan Lynch <ntl@...ox.com>
Cc:	Tejun Heo <tj@...nel.org>, Christoph Hellwig <hch@....de>,
	Oren Laadan <orenl@...columbia.edu>,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, kapil@....neu.edu, gene@....neu.edu
Subject: Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

On Thu, Nov 04, 2010 at 03:45:37PM -0500, Nathan Lynch wrote:
> On Thu, 2010-11-04 at 08:36 +0100, Tejun Heo wrote:
> > Hello,
> > 
> > On 11/04/2010 02:47 AM, Nathan Lynch wrote:
> > >>   In this case whitelisting the allowed
> > >> state by requiring special APIs for all I/O (or even just standard
> > >> APIs as long as they are supposed by the C/R lib you're linked against)
> > >> is the more pragmatic, and I think faithful aproach.
> > > 
> > > I don't think users will go for it.  They'll continue to use dodgy
> > > out-of-tree kernel modules and/or LD_PRELOAD hacks instead of porting
> > > their applications to a new library.  I think a C/R library is an
> > > "ideal" solution, but it's one that nobody would use - especially in
> > > HPC, unless the library somehow provides better performance.
> > 
> > I hear that there are plans to integrate one of the userland
> > snapshotting implementations with HPC workload manager.  ISTR the
> > combination to be condor + dmtcp but not sure.  I think things like
> > that make a lot of sense.
> 
> If you look at the C/R implementations of those two projects you'll see
> that they don't implement what I take to be hch's suggestion - a library
> or platform with special-purpose APIs to which applications are ported
> in order to gain C/R ability.  For all their good points, the projects

And even if they did, I don't think asking application developers to use
such a broad API -- one that requires special APIs for all I/O -- is
practical for many of the purposes outlined at kernel summit.
I think DMTCP is better off for not attempting to mandate such APIs.

How rare is it for an application or library to change the underlying
APIs it uses? How many applications have been ported say from Gnome to
KDE (or vice-versa) over the lifetime of the project? Relative to all
the other applications? I would hazard a guess that most were rewritten
rather than ported and that those that were ported are an utterly
insignificant fraction of what's out there.

It's much better to offer tools that, as much as possible, don't care
which APIs the applications use.

Cheers,
	-Matt Helsley
--
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/