• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 467 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Building Syslink apps: kernel module versus user-side app?

Lee Holeva
Genius 4615 points

In examining the Syslink Install Doc I see that the samples may be built either as kernel modules or as user-side apps.  Are there situations when one mode is preferred over the other?  If so, why?

 

Lee Holeva

 

  • 0
    TI__Prodigy 720 points

    The syslink modules API can be used from the kernel space (a kernel driver)  or user space (an application). So we have provided two sets of sample showing the these two use cases. For example, a notify event can be registered and used from kernel space or from the user space. So two samples are provided for notify.

     

    Murali

  • 0 in reply to MDK35233
    Genius 4615 points

    Yes, but why would you prefer to do one versus the other?

    Lee Holeva

     

  • 0 in reply to Lee Holeva
    Guru 26430 points

    This reference has a bit of discusson of kernel vs. user. Like the rest of the book, it's a bit confusing at times.

    http://lwn.net/Kernel/LDD3/
    Linux Device Drivers, Third Edition
    CHAPTER 2 Building and Running Modules
    Kernel Modules Versus Applications

    Points that I can think of. I'm sure there are others.

    kernel daemon
    - Small stack.
    - No floating point
    - No "standard" or conventional libriaries, eg stdio.h
    - Direct access to hardware and memory. More efficient than user space application.
    - Coding errors can bring the entire kernel down.
    - Very foreign to those with a high level application programming background. Different skillset.
    - More complicated compilation process. Must rebuild entire kernel or build loadable module against a built kernel.
    - Not a good idea to busy wait or block in kernel code. Can hang the kernel.

    user application
    - Large stack possible.
    - Floating point possible
    - Has "standard" or conventional libriaries, eg stdio.h. Open source libraries will usually live in user space.
    - Indirect access to hardware and memory. Data must be double buffered between user and kernel space.
    - Coding errors can brings only application down. Usually.
    - More familiar to those with a high level application programming background.
    - Straight forward compilation process. Does not absolutely require a built kernel.
    - Okay to busy wait or block. Only hangs your application.