[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1001221614520.13231@localhost.localdomain>
Date: Fri, 22 Jan 2010 16:22:22 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Frank Ch. Eigler" <fche@...hat.com>
cc: Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Peter Zijlstra <peterz@...radead.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
utrace-devel@...hat.com, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree
On Fri, 22 Jan 2010, Linus Torvalds wrote:
>
> No. It's not about naming. It's about the downside of having amorphous
> interfaces that apparently don't even have rules, and are then used to
> implement random crap.
>
> Yes, the SNL skit about "It's a dessert topping _and_ a floor wax" was
> funny, but it was funny exactly because it was crazy.
Put yet another way: I'd _much_ rather have two totally separate pieces
that don't depend on each other, and do different things.
So to take a very practical example: I'd much rather have 'seccomp' and
'ptrace' that have _nothing_ what-so-ever to do with each other, than have
some intermediate layer that then needs to make both of those happy, and
that both have to interact with.
There are cases where we really _want_ to have common code. We want to
have a common VFS interface because we want to show _one_ interface to
user space across a gazillion different filesystems. We want to have a
common driver layer (as far as possible) because - again - we expose a
metric shitload of drivers, and we want to have one unified interface to
them.
But going the other way: trying to share code when the interfaces are
fundamentally _different_ is generally not at all such a great idea. It
ends up tying two conceptually totally separate things together, and
suddenly people who work on feature X aneed to modify infrastructure that
affects feature Y, and it turns ou that details A, B and C are all totally
different for the two features and the middle layer has two conflicting
things it needs to work with.
This is why when somebody brought up "you could do a seccomp-like thing on
top of utrace" that my reaction was and is just totally negative. It shows
all the wrong kinds of tying things together.
Linus
--
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