Re: Porting FreeBSD's/OpenBSD's User-level ppp(8) to the Hurd
Porting User-level PPP (or by the way any kind of ppp) to the Hurd
requires access to gnumach's serial drivers (com) as well as to the
IP-Layer (a.k.a. pfinet). [I explained this in a previous mail to
this list]. Unfortunately, I didn't find a canonical/official way
to do both things in the Hurd, even after reading the (glibc, gnumach
and hurd) sources.
The questions I'm having here are precisely as follows:
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?
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.
3. Assuming there is a way to access the serial driver in a Unix-oid way,
it is still necessary to interface to pfinet to inject incoming IP
packets into the network interface and conversly get notified when
the network interface needs to send an outgoing IP packet. How is
such an interface supposed to be? Or, asked more specifically,
is <hurd>/hurd/pfinet.defs still valid for the linux-based new pfinet
code? I'm not sure if this interface would help as a substitute for
the tunnel interface needed by user-level ppp, but it seems like a
good guess. Will pfinet.defs remain stable even for the new pfinet?
4. Instead of using MiG on pfinet.defs to access pfinet directly
from modified ppp(8) sources, I'd prefer to use some kind of libpfinet
as an abstraction barrier. I'd actually hate to incorporate MiG code
into user-level ppp, if simple calls to a pfinet API were enough.
Unfortunately, I'm missing such a library. Are there plans to write
such a library in the future?
The questions here are general enough even for other implementations of
ppp besides user-level ppp. It would be good to document such things in
<hurd>/doc/hurd.texi one day... ;-)
Besides, it would be probably wise to avoid kernel-level pppd implementations
(like Linux' or FreeBSD's) completely and concentrate on that user-level
ppp. The reasons for this are not only philosophical (like: do everything
in user-level space in servers that are as small as possible) but also
practical: It is IMHO not a good idea to bloat pfinet with ppp functionality.
It will get even harder to debug and may get even still more unstable as
more code needs to be maintained (and actualized!).
Thank you for your help.
-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: