Using another driver's services - Linux

This is a discussion on Using another driver's services - Linux ; Dear all, Is there any way in which the one driver can access the services of another driver? The second driver whose services are to be accessed does not export any symbols as such. Is there any way to access ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Using another driver's services

  1. Using another driver's services

    Dear all,

    Is there any way in which the one driver can access the services of
    another driver? The second driver whose services are to be accessed does
    not export any symbols as such. Is there any way to access that driver
    from within the kernel mode as the user applications do?

    Actually, I am writing a virtual sound driver which needs to access
    the driver for the hardware which is actually present on the system.
    So that It can passthrough the audio signal to the actual sound card.
    As I want this access universally applicable, I don't want to make
    changes in any of the hardware driver source code. I am thinking
    of a way in which no changes need to be done anywhere except my code.

    Thanks

    Regards
    --Himanshu
    --
    ----------------------------------------
    Himanshu Chauhan

    "Education is what remains after one
    has forgotten everything he learned
    in school." -- A. Einstein.
    ----------------------------------------

  2. Re: Using another driver's services


    Himanshu Chauhan wrote:

    > Is there any way in which the one driver can access the services of
    > another driver? The second driver whose services are to be accessed does
    > not export any symbols as such. Is there any way to access that driver
    > from within the kernel mode as the user applications do?


    Look at what the kernel code the user applications invoke does, and do
    that. That user code just calls into kernel code.

    > Actually, I am writing a virtual sound driver which needs to access
    > the driver for the hardware which is actually present on the system.
    > So that It can passthrough the audio signal to the actual sound card.
    > As I want this access universally applicable, I don't want to make
    > changes in any of the hardware driver source code. I am thinking
    > of a way in which no changes need to be done anywhere except my code.


    I'm not that familiar with the sound system on Linux, but I'm pretty
    sure there's already a defined way to do that. The sound drivers are
    layered, and higher-level drivers (such as synthesizers) pass audio
    output to lower-level drivers (like raw wave output devices).

    DS


  3. Re: Using another driver's services

    Himanshu Chauhan wrote:
    > Dear all,
    >
    > Is there any way in which the one driver can access the services of
    > another driver?


    It simply refers to the exported symbols of that driver. A dependency
    is then established between the two modules, understood by the module
    utilities.

    >The second driver whose services are to be accessed does
    > not export any symbols as such.


    Then you're screwed as far as the above plan.

    > Is there any way to access that driver
    > from within the kernel mode as the user applications do?


    Of course. You can use the kernel functions that correspond to opening
    files, ioctl, and so on.

    There isn't an nice C library interface for doing most of that. You can
    use sys_open to open the device. You will get back a file descriptor
    number. That is useless to you in the kernel, since it's an index into
    a process-specific file table. You have to use file_get to convert the
    number into a "struct file *" pointer. You could retain that pointer in
    your own virtual driver's control structure, taking care that you do a
    file_put on it when cleaning up.

    To invoke the file operations on it, you have to call the virtual
    functions directly.

    struct file *file = mydriver->other_driver_file; /* for instance */
    int result = ENODEV;

    /* take care not to use any null pointers */
    if (file->f_op && file->f_op->read)
    result = file->f_op->read(file, ...);

    > Actually, I am writing a virtual sound driver which needs to access
    > the driver for the hardware which is actually present on the system.


    This is the job of the underlying sound driver already: to abstract the
    hardware and provide a virtual interface to it which is compatible with
    other drivers.

    If all that your wrapper does is pass calls to another device, then it
    has no value.

    > So that It can passthrough the audio signal to the actual sound card.
    > As I want this access universally applicable, I don't want to make
    > changes in any of the hardware driver source code. I am thinking
    > of a way in which no changes need to be done anywhere except my code.


    Maybe you want to create some kind of sound daemon in user space
    instead.


  4. Re: Using another driver's services

    Kaz Kylheku wrote:
    > Himanshu Chauhan wrote:
    >> Dear all,
    >>
    >> Is there any way in which the one driver can access the services of
    >> another driver?

    >
    > It simply refers to the exported symbols of that driver. A dependency
    > is then established between the two modules, understood by the module
    > utilities.
    >
    >> The second driver whose services are to be accessed does
    >> not export any symbols as such.

    >
    > Then you're screwed as far as the above plan.
    >
    >> Is there any way to access that driver
    >> from within the kernel mode as the user applications do?

    >
    > Of course. You can use the kernel functions that correspond to opening
    > files, ioctl, and so on.
    >
    > There isn't an nice C library interface for doing most of that. You can
    > use sys_open to open the device. You will get back a file descriptor
    > number. That is useless to you in the kernel, since it's an index into
    > a process-specific file table. You have to use file_get to convert the
    > number into a "struct file *" pointer. You could retain that pointer in
    > your own virtual driver's control structure, taking care that you do a
    > file_put on it when cleaning up.
    >
    > To invoke the file operations on it, you have to call the virtual
    > functions directly.
    >
    > struct file *file = mydriver->other_driver_file; /* for instance */
    > int result = ENODEV;
    >
    > /* take care not to use any null pointers */
    > if (file->f_op && file->f_op->read)
    > result = file->f_op->read(file, ...);
    >
    >> Actually, I am writing a virtual sound driver which needs to access
    >> the driver for the hardware which is actually present on the system.

    >
    > This is the job of the underlying sound driver already: to abstract the
    > hardware and provide a virtual interface to it which is compatible with
    > other drivers.
    >
    > If all that your wrapper does is pass calls to another device, then it
    > has no value.
    >
    >> So that It can passthrough the audio signal to the actual sound card.
    >> As I want this access universally applicable, I don't want to make MCA (Final Year)

    I.G. National Open University
    India

    Web: http://members.lycos.co.uk/hschauhan
    Email: hs.chauhan@gmail.com

    >> changes in any of the hardware driver source code. I am thinking
    >> of a way in which no changes need to be done anywhere except my code.

    >
    > Maybe you want to create some kind of sound daemon in user space
    > instead.
    >


    Thanks for the pointers. I will look deeply into it.
    My virtual sound driver functioning is like jack or
    vsound. The plan is to provide a loopback interface
    along with a playthru. Jack and VSound are both user
    land daemons. I wish to do this in kernel mode by
    abstracting a sound device.

    Regards
    --Himanshu


    --
    ----------------------------------------
    Himanshu Chauhan

    "Education is what remains after one
    has forgotten everything he learned
    in school." -- A. Einstein.
    ----------------------------------------

  5. Re: Using another driver's services

    Himanshu Chauhan wrote:

    > Dear all,
    >
    > Is there any way in which the one driver can access the services of
    > another driver? The second driver whose services are to be accessed does
    > not export any symbols as such. Is there any way to access that driver
    > from within the kernel mode as the user applications do?
    >
    > Actually, I am writing a virtual sound driver which needs to access
    > the driver for the hardware which is actually present on the system.
    > So that It can passthrough the audio signal to the actual sound card.
    > As I want this access universally applicable, I don't want to make
    > changes in any of the hardware driver source code. I am thinking
    > of a way in which no changes need to be done anywhere except my code.


    I'm not familiar with ALSA, but in general it
    works like any other kernel subsystem.

    That is, there is a core with which all other
    related drivers register. The individual drivers
    don't export symbols.

    You probably want to look at the snd_pcm driver,
    which is moving sound data between a chardriver
    interface (/dev/dsp*) and the sound core.

    You need to write a driver which talks to the
    sound core in the same way, but has a interface
    of your choice (even exported symbols) in the
    other direction.

    Kind regards,

    Iwo


+ Reply to Thread