On Mon, 2 Oct 2000, Timur Tabi wrote:
> ** Reply to message from Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com> on
> > 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.
I think you misunderstand... there are many ways for Linux drivers to
communicate between one another. There is no one standard way, because
no one standard way can cover all situations.
You must describe -what- is being communicated, -how much- data is being
communicated, and -how often- communication occurs before we can help
suggest a method of driver<->driver communication.
In other words, the method of driver communication is part of your
design, not a piece of existing kernel API.
Jeff
-
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/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:10 EST