> Could one set up a tree like this:
>
> pfinet
> +-- load balancing channel
> | +-- network device channel
> | +-- Mach eth0
> | +-- network device channel
> | +-- Mach eth1
> +-- PPP channel
> +-- serial port channel
> +-- Mach com0
>
> with commands like:
>
> settrans -c /dev/eth0 /hurd/channelio --channel-type=device eth0
> settrans -c /dev/eth1 /hurd/channelio --channel-type=device eth1
> settrans -c /dev/eth0+1 /hurd/channelio --balance /dev/eth0 /dev/eth1
> settrans -c /dev/com0 /hurd/channelio --channel-type=device com0
> settrans -c /dev/ppp0 /hurd/ppp /dev/com0
> settrans -c /servers/socket/2 /hurd/pfinet \
> /dev/com0ppp --address=10.0.0.1 \
> /dev/eth0+1 --address=172.16.0.1
>
> Then, when pfinet starts up, it would read all the channel
> information and feed it to libchannel, where PPP would be
> implemented. If a channel refused file_get_channel_info, then
> libchannel would access it as a file.
You have the basic idea. Any answer more detailed would be made up on the
spot, since I haven't thought through the implementation fully. (As your
example is written, it suggests that /dev/eth0 and /dev/ppp0 are devices
that deliver IP packets, while I would expect them to deliver Ethernet and
PPP frames respectively. pfinet would then need to understand PPP framing.
So that actual construction will probably be a little different when we
work out the details.)
> IIRC, there is a string syntax for nested stores... where is it
> documented? A similar thing might be good for channels, so that
> /dev/eth0+1 and /dev/ppp0 could be left out.
There is a sort of syntax for that in the arguments libstore parses, but
it's kind of quirky. Aside from booting off a funny composite store, there
isn't much call to use it. Just set a translator on a different file for
each layer of the store, and opening the "most-layered" store will get
file_get_storage_info percolating up from the bottom so that the libstore
in the actual user (i.e. a filesystem or the top-most storeio) does all the
actual work in one place to execute i/o.
> How would tcpdump work? It must attach to a network device after
> it has already been opened by pfinet or similar. Maybe pfinet
> itself should have hooks for tcpdump?
tcpdump in fact need not have anything to do with pfinet per se. All it
needs from pfinet is to know what interfaces are being used (if the user
didn't ask for a specific one). tcpdump would read raw ethernet packets
from /dev/eth0, raw PPP packets from /dev/ppp0, or whatever. Note that it
makes perfect sense to use tcpdump on a packet source that is not being
used by pfinet at the time. All it needs is an interface to the channelio
devices to receive copies of packets going elsewhere. This is the same as
a generic i/o spy interface that would also be useful on tty devices.
> I don't believe keyboard devices need be handled very
> efficiently. Even if the user keeps a function key held down and
> it repeats at 30 Hz, outputting 5 characters each time, that's
> still only 150 characters per second.
The main concern is handling them cleanly and easily.
