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

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.

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.
----------------------------------------

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