[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070819025758.GR21089@ftp.linux.org.uk>
Date: Sun, 19 Aug 2007 03:57:58 +0100
From: Al Viro <viro@....linux.org.uk>
To: david@...g.hm
Cc: Alan <alan@...eserver.org>, Kyle Moffett <mrmacman_g4@....com>,
Marc Perkel <mperkel@...oo.com>, Valdis.Kletnieks@...edu,
Michael Tharp <gxti@...tiallystapled.com>,
LKML Kernel <linux-kernel@...r.kernel.org>,
Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems
On Sat, Aug 18, 2007 at 07:03:06PM -0700, david@...g.hm wrote:
> >>I suspect you will find it somewhat hard to convince *anybody* on
> >>this list to put either a regex engine or a Perl interpreter into the
> >>kernel. I doubt you could even get a simple shell-style pattern
> >>matcher in. First of all, both of the former chew up enormous gobs
> >>of stack space *AND* they're NP-complete.
Eh? regex via NFA is O(expression size * string length) time and
O(expression size) space. If you can show that regex matching is
NP-complete, you've got a good shot at Nevanlinna Prize...
Not that it made regex in kernel a good idea, but fair is fair -
unless you can show any mentioning of backrefs upthread...[1]
> You just can't do such
> >>matching even in polynomial time, let alone something that scales
> >>appropriately for an OS kernel like, say, O(log(n)).
> >
> >Already been done. Take a look at "AppArmor" aka "Immunix".
>
> don't forget the ACPI interpreter.
YAProof that bogons follow Boze statistics...
-
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