Re: execute a user process in the kernel

From: Robert Watson (rwatson_at_freebsd.org)
Date: 09/24/04

  • Next message: Dag-Erling Smørgrav: "Re: execute a user process in the kernel"
    Date: Fri, 24 Sep 2004 14:11:19 -0400 (EDT)
    To: Dag-Erling Smørgrav <des@des.no>
    
    

    On Fri, 24 Sep 2004, Dag-Erling Smørgrav wrote:

    > execve(2) assumes you already have a process. You get a process by
    > forking another process. The only process we ever create from scratch
    > is init(8), and that takes a s**tload of work (see kern/init_main.c).
    > This is why we have stuff like nfsiod(8) which does nothing but provide
    > the kernel with a process context it can use for other stuff.
    >
    > You could, of course, write a kernel API for creating processes from
    > scratch. They'd still need a parent, but you can use init(8) (pid 1)
    > for that.

    Well, we have kproc/kthread APIs, but none of that is semantically
    compatible with the notion of execve(), which is a very user-centric
    concept ("replace the address space with a mapping of binary <x>"). You
    could fudge together a related notion, though, involving loadable kernel
    modules that have a main() routine run from a thread. That said, the
    notion of simply running user code in kernel (as has been pointed out) is
    fraught with peril, primarily because the kernel is basically one big
    program with many special requirements, and user applications are written
    with the assumption that they are the only program, not running in the
    context of another program.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Principal Research Scientist, McAfee Research

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: Dag-Erling Smørgrav: "Re: execute a user process in the kernel"

    Relevant Pages

    • Re: How to avoid data copies in a driver ?
      ... You cannot use a user-mode file-descriptor in the kernel. ... The kernel itself doesn't have a process context. ... Using memory mapping as previously advised, lets you DMA ...
      (Linux-Kernel)
    • Re: async i/o question
      ... Then you just misuderstood how the kernel works when processing read, ... Usually a driver has both things implemented. ... both communicating through command/data queues. ... In process context, your kernel driver has to ensure it does not use single ...
      (comp.os.linux.development.system)
    • Re: ERROR: scheduling while atomic in kernel module
      ... Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel ... Yes it's safe to call wake_up from interrupt context, ... necessarily see a coherent call stack trace. ... process context call hierarchy that may have left a number of kernel ...
      (comp.os.linux.development.system)
    • Re: determining process context
      ... I tried to get the Process context in dispatch routine using PsGetCurrentProcess and tried to supply this argument to my PsCreateSystemThread but when I do this, it DOESNT create Thread AT ALL. ... My application requirement is passing multiple buffers to the kernel so I cannot use buffered or direct method because it will be locked, we want to lock the buffers only when device requests it for DMA. ...
      (microsoft.public.development.device.drivers)
    • Re: ERROR: scheduling while atomic in kernel module
      ... Linux 2.6.14 kernel on MIPS architecture with this piece of my kernel ... Yes it's safe to call wake_up from interrupt context, ... necessarily see a coherent call stack trace. ... process context call hierarchy that may have left a number of kernel ...
      (comp.os.linux.development.system)