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.
