[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] RE: Documentation ??

Bjorn Wesen wrote:

> On Wed, 15 Nov 2000, Subhankar Saha wrote:
> > don't see anything for 'read' - so how am I supposed to give data (which
> > I received from bottom) to the User application (need not be a Line
> > Discipline like PPP) who has opened my device ? I hope you understand my
> > problem. In the Axis code I noticed the same has been achieved by
> > calling tty->ldisc.receive_buf() - but I guess this is true for Line
> > Disciplines .. but what if an User Application which just opens my
> > device and wants to do write/read buffers ??

When a tty gets some data, it pushes it to the upper layer by calling
tty->ldisc.receive_buf().  See bluetooth.c:bt_receive_top for an example.
Later, when an application calls read, it results in a call to

Look at drivers/char/tty_io.c and n_tty.c in your linux source tree for
another example.

Here's a detailed example. Let's image "/dev/ttyX" has a registered tty

The application calls open("/dev/ttyX", ...). The character device driver for
all tty's is implemented in tty_io.c, so the kernel ends up calling
tty_io.c:tty_open(tty). As part of first-time initialization, the tty is
assigned a line discipline. By default it gets the one implemented in n_tty.c
(see init_dev() & initialize_tty_struct() in tty_io.c).

Next, say the application calls read on the fd returned from open. Again, the
character driver for all tty's is implemented in tty_io.c. So the kernel calls
tty_io.c:tty_read(). This in turn calls tty->ldisc.read(). If the default tty
is used, this means it calls n_tty.c:read_chan(). There it copies data from
the tty's receive buffer to the caller's buffer.

Now, how did the data get from the hardware to a place where the ldisc can
find it? Typically a tty driver which controls hardware will have an interrupt
associated with receiving data. In the interrupt handler it will copy the data
into the tty buffers. Then it calls  ldisc->receive_buf() to infrom the ldisc
that data is available in those buffers.

Hope that helps. I learned everything I know by staring at tty_io.c, n_tty.c
and serial.c for long periods of time. So I could be off on some points. And I
can't point you to a better reference.

> In the Axis stack and PPP case, the N_TTY discipline is replaced by the
> PPP discipline but the Axis discipline has hooked in underneath the
> PPP. It is probably not very common to do this, I don't think that system
> was designed for layered disciplines :) But if you didn't have the PPP
> enabled, you'd talk with the user, but through N_TTY and the tty.
> If you just want a device for a user to read/write verbatim data from/to
> you want a stand-alone char-device driver, not something to do with the
> tty's. But the Axis bluetooth stack needs it because one of the most
> common Bluetooth applications (at least now in the beginning) is to
> simulate serial-ports.
> -Bjorn

If and only if (I think) you implement a tty interface then PPP can use you.
I'm not sure PPP will work over a plain character device interface. Can anyone


To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com