Hi,
I'm using 3964(r) line discipline in one of the projects and I discovered
that it is not well suited for multithreaded programs, basically because:
n_r3964 relies on the pid of the process that initialised the line
discipline on the tty in question.
as a consequence of this, it is not possible to init this ldisc in one
thread and then read/write/etc in the other - fork() never gets to the
line discipline so it cannot know the child pid, and it happily denies
all access by any pid other than it knows (through open).
I'm still looking in the code and I must admit I don't have full
understanding of the reasons behind using the pid. So far I figured out
that this line discipline offers such an api to the programmer that
several processes could open the same tty (say serial port) initialise
3964(r) line discipline thereon and register different callbacks.
Thus one process would be a "writer" and another a "reader".
The callbacks available are transmission completed (whether successfully
or not) and frame received (allowing to read the content). The code can
also send a signal to the process(es) with these notifications.
Personally I'd much rather prefer an api that allows use by multithreaded
programs and a driver that doesn't know any pid's for any reason.
I'm sure I can hack it up in such a way that I can use it, no problem
here. Should I, on the other hand, be willing to make it "right", I would
like to know:
1. is there anyone who really know why n_r3964 is coded this way and how
it handles timeouts?
2. is there a realistic way of providing the current api through something
like FIOASYNC or some such?
3. is there someone out there but me who should be doing this?
Thanx,
dima
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:24 EST