Very Computer

Hi,

I would appreciate it if someone could help me on this.  I'm fairly new in
Linux but have quite a few years programming experience on Windows
programming.

I have a module running in kernel space, and a lib in user space.  Data
exchanges are required between the module and the lib.  How can I do it?
Detailed info would be helpful.  Code snip or web site where I can find
sample code are even better.

Thank you in advance.

Ls.

Hi,

Creating system calls, for example? There should be lots of examples on the
kernel source.

Quote:> Hi,

> I would appreciate it if someone could help me on this.  I'm fairly new
in
> Linux but have quite a few years programming experience on Windows
> programming.

> I have a module running in kernel space, and a lib in user space.  Data
> exchanges are required between the module and the lib.  How can I do it?
> Detailed info would be helpful.  Code snip or web site where I can find
> sample code are even better.

    man        ioctl

see any good tutorial on device driver programming.  If you're serious
about it, buy Rubini's book, Programming Linux Device Drivers (O'Reilly),
2nd edition.

        Norm

You'd probably be better off using existing system calls (e.g.
ioctl).  Or, you could use the /proc filesystem.  

Take a look at source code for existing modules that are
similar to what you're doing and take a look at Rubini's book
_Linux_Device_Drivers_.  Make sure you get the 2nd edition.

--
Grant Edwards                   grante             Yow!  I like the way ONLY
                                  at               their mouths move... They
                               visi.com            look like DYING OYSTERS

You're looking for

  put_user
  get_user

See kernel/modules.c and/or kernel/printk.c for examples

--
It is financially more expensive to go to prison than to attend Harvard.

The short answer is: create a character-special device file
(/dev/mydevice) using mknod, open() it from the library, then do read()s,
write()s, or ioctl()s on the file descriptor returned by open().  You
driver will need to call register_chrdev() from its module initialization
function to associate itself with that device file.  Your driver will
have to implement the read(), write(), or ioctle() system calls that the
library makes.

The long answer (in terms of your time) is: buy "Linux Device Drivers"
(2nd Edition):

  http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0596000081

It has lots of sample code and good advice.
--
Francis Litterio

Hi Francis,

Thank you very much for the info.  It helps a lot!

I have a few questions on this.  I would appreciate it
if you could give me some hints.  I'm new in Linux, so
please forgive me for asking silly questions.

Q1:
The module is a firmware that keeps running all the
time in kernel.  It needs to get data from userland
application, or send data to userland application to
get processing result back from the userland
application (i.e. it is module, not userland
application, that starts the data exchanges every
time).  The question is how to keep userland
application listening the requests from module all the
time?  Using an infinite loop in userland application
just wastes too much processor time.  Is daemon a
solution, and how?

Q2:
The kernel module is a firmware that gets loaded
everytime after reboot the hardware device.  Is it
possible to get /dev/mydevice "installed" automatically
without using mknod manually?

Q3:
What is the difference between letting module create a
device like /dev/mydevice, and a file like
/proc/myfile?  Can I go either way to create an
interface with userland, and let module send requests
to a userland application and get response back?

Q4:
I guess kernel modules can not invoke functions
defined in a userland lib, right?  Since I guess it's
not possible for a kernel module to load a userland
share lib (*.so).  Am I right, or do I miss something?

Thank you.

Ls

A kernel module isn't really firmware.  It's normal C code running at a
raised privilege level on the CPU (some systems call this "supervisor
mode" or "kernel mode").
--
Francis Litterio

The userland app should call select(2) to wait until there is data to be
read from the device file.  Busy-waiting is not necessary.

Quote:> The kernel module is a firmware that gets loaded
> everytime after reboot the hardware device.  Is it
> possible to get /dev/mydevice "installed" automatically
> without using mknod manually?

You only have to run mknod once, then the device file remains until it is
deleted.  Something (an install script or a person) has to run the mknod
command once (as root).

Quote:> What is the difference between letting module create a
> device like /dev/mydevice, and a file like
> /proc/myfile?

You could do it either way without about the same amount of code.  I
think it's harder to write a driver that supports userland write()s to a
/proc file than to a /dev/file.  Examples of both /proc and /dev
interfaces are given in the book I mentioned in my previous posting.

Quote:> Can I go either way to create an
> interface with userland, and let module send requests
> to a userland application and get response back?

Yes.

Quote:> I guess kernel modules can not invoke functions
> defined in a userland lib, right?

Not directly.  There is a mechanism for kernel modules to run programs in
user space, but I don't think it's efficient.  The fundamental
relationship between a kernel module and userland code is an I/O
relationship, so the best way for the two to communicate is via read(),
write(), and ioctl().

Quote:> Since I guess it's
> not possible for a kernel module to load a userland
> share lib (*.so).  Am I right, or do I miss something?

You are right.  The kernel does not load shared libraries into a user
program's address spaces.  The application does it by calling mmap() to
map the .so file into its virtual address space.
--
Francis Litterio

Quote:> > The question is how to keep userland
> > application listening the requests from module all the
> > time?  Using an infinite loop in userland application
> > just wastes too much processor time.

> The userland app should call select(2) to wait until there is data to be
> read from the device file.  Busy-waiting is not necessary.

I hope I understand it right.  Sorry for asking silly questions.  I'm new in
Linux.  Based on my understanding:

(1) since kernel module always starts the process first (requests data from,
     or sends data to the userland application to get its processing result
     back), so kernel module works as a client; while userland app works
     as a server.

(2) userland application needs to do something like the following.
select( )
      will block the process before the status is changed at /dev/mydevice.
      This way, it's not busy-waiting anymore.

fd = open("/dev/mydevice");
while(1)
{
    select(fd...) //Block here until status is changed on /dev/mydevice
    if(status_change_on_dev-mydevice)
    {
        ch = read(fd); // Read in the request (a char) from module.
        switch(ch)       //Parse it and do things accordingly.
        {
            case 'r':      //Need to read more data from module.
                 while(ch = read(fd) != '\0')
                      strcat(str, ch);
                  break;

             case 'w':    //Need to write data to the module.
                 write(fd, outputData);
                 break;
          }
       }

Quote:} //End of while loop

(3) I don't know what module should do to yet.  I'll check.  Could you
     please give me a rough outline on what module should do?

     It seems the module should have read() and write() routines to
     interact with userland app's write() and read() functions, right?

     Also I guess module code has nothing to do with /dev/mydevice.
     mknod will create /dev/mydevice regardless what module I create.
     And once /dev/mydevice is created and linked with the module by
     mknod, all functions defined in the module can be used by an
     userland application after open( ) the fd to /dev/mydevice, right?

(4) One question is that over 512 byte of data needs to be transferred
      from/to module to/from the userland application everytime after
      module starts the request.  Is there any potential problem with this
      mechanism to transfer so many bytes between kernel and userland
      app?

Quote:> > The kernel module is a firmware that gets loaded
> > everytime after reboot the hardware device.  Is it
> > possible to get /dev/mydevice "installed" automatically
> > without using mknod manually?

> You only have to run mknod once, then the device file remains until it is
> deleted.  Something (an install script or a person) has to run the mknod
> command once (as root).

(5)  Do I need to run the mknod everytime after system reboot to create
      /dev/mydevice?  I guess this node will be lost after reboot.

Quote:> > Since I guess it's
> > not possible for a kernel module to load a userland
> > share lib (*.so).  Am I right, or do I miss something?

> You are right.  The kernel does not load shared libraries into a user
> program's address spaces.  The application does it by calling mmap() to
> map the .so file into its virtual address space.

(6)  Sounds like I need either link a static lib with the userland app, or
let
       userland app to load a shared lib on the fly.  Then module can get
       the services defined in the lib indirectly through the userland app,
right?

(7)  Can I use a daemon, instead of a regular userland application, to
interact
       with a kernel module?  What are the pros/cons if I use a daemon for
this
       case?

Many thanks for your help, and have a nice weekend!

Ls.

Any chance you could reduce the x-post?  I've set follow up to misc,
but that might be wrong?

--
Mark Kent
                                               Take out the ham to mail me.