Switching to the right list...
Roland McGrath <[EMAIL PROTECTED]> writes:
> 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.
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.
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.
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?
> This is a general way towards efficiently dealing with things
> like keyboard devices and printers, etc.
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.
