Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757151Ab2FWElL (ORCPT ); Sat, 23 Jun 2012 00:41:11 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:44265 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752837Ab2FWElJ (ORCPT ); Sat, 23 Jun 2012 00:41:09 -0400 Date: Fri, 22 Jun 2012 21:41:05 -0700 From: Greg KH To: Peiyong Feng Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Implement uhook(call kernel func from userspace) driver Message-ID: <20120623044105.GA32663@kroah.com> References: <20120623040633.GA16278@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1606 Lines: 41 On Sat, Jun 23, 2012 at 12:18:29PM +0800, Peiyong Feng wrote: > 2012/6/23 Greg KH : > > On Sat, Jun 23, 2012 at 11:20:35AM +0800, Peiyong Feng wrote: > >> Hi all, > >> > >> This patch implement the uhook kernel driver. Here are some ideals and > >> explanations: > >> > >> 1. What is uhook > >> > >> uhook(userspace kernel hook) means call kernel function from > >> userspace. That is to say, we can > >> > >> write a function in kernel space and call it in userspace while the > >> kernel Image is running. For example: > > > > That's, um, "interesting", but is of course, nothing we can accept into > > the main kernel tree, as I'm sure you can understand. ?Otherwise, you > > just created a few thousand undocumented system calls whose behavior > > changes every release which is not something we can accept. > > > > But it is a great hack, very nicely done. ?I'm sure that some people > > will like it for debugging, although I'm not quite sure you got all of > > Well, is there some other tree I can commit the patch? What do you mean by this? > > the user/kernel boundry conditions correct, and I know the 32/64bit > > issues aren't handled, which you might want to clean up sometime in the > > I am still working on it. The ultimate aim is that the uhook module can process > any funciton and any data type Good luck :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/