[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] RE: Documentation ??
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 ??
(I hope the stuff below has any resemblance to how the Axis stack actually
works because it was a while since I looked at the tty part)
When you use a tty-device you always need a line discipline - even if
it does not do very much. I think the N_TTY line discipline is the
default. It will pass the receive_buf() data upwards into the tty and then
to the user, cooked or not according to TTY settings. So if you insert a
discipline like the Bluetooth driver, you still need to talk to the old
discipline because there will always be one.
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
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org