Re: Porting FreeBSD's/OpenBSD's User-level ppp(8) to the Hurd
Replying to my own mail. Sorry...
> 1. Has someone written a translator for gnumach's com driver, that can
> be directly attached to /dev/ttySn? If such a translator exists,
> will it provide full/partial support to ioctl()'s that set baud rate,
> parity, rts/cts etc.? Will glibc interact directly with it? Will
> this translator be thread-safe? Will it even support multiple threads?
I must have run out of coffee whilst looking at the sources. Of course,
<hurd>/term is exactly what I'm looking for! Sorry for the confusion.
> 2. If there is no such translator, is there an officially approved or
> preferred way to access native gnumach drivers? Of course, there is
> always the possibility to get the master device port from the PROC
> server (like in e.g. <glibc>/sysdeps/mach/hurd/settimeofday.c) and
> look for the com driver directly, then try to interact with it in
> a way shown in <gnumach>/i386/i386at/com.{h,c}. I'm however more than
> reluctant to start work on this kind of stuff right now, since serial
> drivers can be really tricky to implement/interface with correctly.
> Of course, threading will also be an involved issue here (I think),
> not even to mention exception ports and all this.
Here again, the code in <hurd>/term/devio.c is all I need.
Only two remaining questions:
a.) How to I settrans the term translator to a /dev/ttyS* on one side
and have it use gnumach's com driver on the other side?
b.) Only baud rates up to 38400 are defined/used in switch statements.
Does this mean, that 57600 and higher are not possible with term
and/or gnumach's com driver?
-Farid.
--
Farid Hajji -- Unix Systems and Network Administrator | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Fermat: ...I've found a remarkable proof for this: Let x,y @#$!@$!2@ NO CARRIER
Reply to: