lkml.org 
[lkml]   [2000]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Inter-device-driver communication?
** Reply to message from Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> on
Mon, 2 Oct 2000 15:18:13 -0500 (CDT)


> You can certain have one driver load another via modprobe (grep for
> CONFIG_KMOD), but if both drivers will be required, module dependencies
> might simply pull in one of the drivers automatically.

Ok, thanks. I'll check it out.

> For driver<->driver communication, it is totally dependent on what you
> need to communicate. It could be something as simple as a small, shared
> module protected by a spinlock, or something more complex. Really task
> dependent..

The communication would be like an ioctl, but to me, ioctls are something that
processes send to drivers, not something that drivers send to other drivers. I
just wanted to know if sending an ioctl from one driver to another was common,
and if not, what the alternative is.

For example, under OS/2, drivers communicate amongst themselves by something
known as an IDC. There is a kernel API for getting the IDC entry point of
another driver, which is really nothing more than a pointer. The calling
driver just sets up his stack and/or registers, and just makes a call to the
IDC entry point as if it were a normal function. There is no kernel
involvement in this call, and so the calling convention, etc is completely
defined by the callee.





--
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.053 / U:22.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site