linux-mips
[Top] [All Lists]

Kill kspd?

To: linux-mips@linux-mips.org
Subject: Kill kspd?
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 9 Oct 2012 19:45:17 +0200
Cc: Chris Dearman <chris@mips.com>, "Steven J. Hill" <sjhill@realitydiluted.com>, John Crispin <blogic@openwrt.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
Kspd is executing syscalls from inside kernel space, something that is
fraud with all sorts of problems as identified by Al and anyway, executing
syscalls from kernel space has been something that's been frowned upon
if not deprecated for a long time.  Al may want to elaborate on the issues
but suffice to say it's not pretty.

So I'm wondering, is anybody still using kspd?  Much of kspd's knowledge
of the ABI on the client processor (which might not even be based on SDE!)
should vanish along with the use of syscalls.  If somebody wants to
reengineer kspd I think I'd favor a userspace daemon that just uses a
small kernel communication facility (think of a pipe or socket) for
communication unless somebody finds a good argument (performance?) against
that.  Or and I'd be perfectly fine with that, we could just nuke the
bloody thing.  I receive no feedback on it which makes me assume that
nobody's using it so I'm all in favor for the nuclear solution.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>
  • Kill kspd?, Ralf Baechle <=