Re: PPP for Hurd requirements
The basic shape of the better plan is well understood. There needs to be
some kind of interface to attach to pfinet and provide it with new
interfaces via ports. Then daemons a la pppd can be written in similar
fashion as using the tun device on BSD.
I have some complex ideas on how to do this in a clean and flexible way for
the long term, but I have not had the time to have discussion of the
details. (My basic notion is a "channel" abstraction parallel to the
"store" abstraction and with similar support in libraries and protocols a
la file_get_storage_info and libstore. This is a general way towards
efficiently dealing with things like keyboard devices and printers, etc.)
But it would be pretty straightforward without a whole lot of thought to
add a simple RPC interface to pfinet for adding tun style interfaces. I
guess the quickest WRONG hack would be for pfinet's command-line handling
to grok pseudo-devices specified by a file name it would look up. Then you
could add one of those with fsysopts as well as at translator startup.
>From the hurd server hacking I've seen you doing lately, I think you know
enough to whip that hack out, Marcus. You know, actually an even easier
and still egregious and WRONG hack might be to have pfinet know how to
create some new weirdo flavor of socket that then would act as an packet
source/sink. Then a pppd could just open one of these sockets, set its
interface addresses via bind/connect/setsockopt or something nutty like
that, and start shoving packets. Muwahaha. We will eventually rip out any
hack like this, I guarantee you, but until we have time to work out a
pretty solution, what the hell.
Reply to: