On Thu, Jun 01, 2006 at 12:06:07AM +0200, Kenneth ?stby wrote:
> I've always had a thing for networks, and I saw you needed some work on the
> pfinet part, so if it's still needed I could play around with it. I need
> some
> startup time, but I got the entire summer :)
That's cool! If you have questions, just ask: either here or on the
#hurd IRC channel on irc.freenode.net.
To do this networking rework properly, we should probably first take the
time to design and implement the ``legendary'' libchannel. I attached
`libchannel.mbox' to this email: the few bits of libchannel related
emails which I could gather from the mailing list archives I have access
to.
Everyone, feel free to parse through those emails and post your thoughts.
Relevant Savannah tasks:
- http://savannah.gnu.org/task/?func=detailitem&item_id=1619 -- libchannel
- http://savannah.gnu.org/task/?func=detailitem&item_id=5469 -- pfinet
- http://savannah.gnu.org/task/?func=detailitem&item_id=5470 -- pfinet6
Regards,
Thomas
>From [EMAIL PROTECTED] Tue Aug 1 21:58:28 2000
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 2 (Debian))
id 13JiBI-0004RS-00; Tue, 01 Aug 2000 14:58:28 -0500
Received: (qmail 25955 invoked by uid 38); 1 Aug 2000 19:58:21 -0000
Resent-Date: 1 Aug 2000 19:58:21 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 25887 invoked from network); 1 Aug 2000 19:58:18 -0000
Received: from hefeweizen.cv.linnaean.org (HELO hefeweizen.linnaean.org)
(209.58.179.123)
by murphy.debian.org with SMTP; 1 Aug 2000 19:58:18 -0000
Received: from neuralgia.linnaean.org (neuralgia.linnaean.org [198.49.250.5])
by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.6)
with ESMTP id PAA07075;
Tue, 1 Aug 2000 15:58:14 -0400 (EDT)
Received: (from [EMAIL PROTECTED])
by neuralgia.linnaean.org (8.10.2/8.9.3/AI2.12/linnaean.client:2.1) id
e71JwD519912;
Tue, 1 Aug 2000 15:58:13 -0400 (EDT)
Date: Tue, 1 Aug 2000 15:58:13 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
From: Roland McGrath <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Marcus Brinkmann <[EMAIL PROTECTED]>
Cc: Eric Gibson <[EMAIL PROTECTED]>, debian-hurd@lists.debian.org
Subject: Re: PPP for Hurd requirements
In-Reply-To: Marcus Brinkmann's message of Tue, 1 August 2000 21:41:10 +0200
<[EMAIL PROTECTED]>
Emacs: well, why *shouldn't* you pay property taxes on your editor?
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/4957
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 1670
Lines: 27
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.
>From [EMAIL PROTECTED] Sun Aug 6 12:17:53 2000
Received: from localhost
([127.0.0.1] helo=mailhost.rz.ruhr-uni-bochum.de ident=root)
by localhost with esmtp (Exim 3.12 #1 (Debian))
for [EMAIL PROTECTED]
id 13LNVB-00005P-00; Sun, 06 Aug 2000 12:17:53 +0200
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 27708 invoked by alias); 6 Aug 2000 09:01:24 -0000
Received: (qmail 27695 invoked from network); 6 Aug 2000 09:01:24 -0000
Received: from mescaline.gnu.org (158.121.106.21)
by mi-1.rz.ruhr-uni-bochum.de with SMTP; 6 Aug 2000 09:01:24 -0000
Received: (from [EMAIL PROTECTED])
by mescaline.gnu.org (8.9.1a/8.9.1) id EAA06521;
Sun, 6 Aug 2000 04:51:37 -0400
Resent-Date: Sun, 6 Aug 2000 04:51:37 -0400
Received: from PC486.Niemitalo.local ([EMAIL PROTECTED] [212.38.245.238])
by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id EAA06481
for <bug-hurd@gnu.org>; Sun, 6 Aug 2000 04:50:49 -0400
Received: from kalle by PC486.Niemitalo.local with local (Exim 3.12 #1 (Debian))
id 13LJPi-0002rL-00; Sun, 06 Aug 2000 08:55:58 +0300
To: bug-hurd@gnu.org
Subject: Re: PPP for Hurd requirements
References: <[EMAIL PROTECTED]>
X-Accept-Language: fi;q=1.0, en;q=0.9, sv;q=0.5, de;q=0.1
X-URL: http://stekt.oulu.fi/~tosi/
X-Anagram: look vanilla, aim elite
In-Reply-To: Roland McGrath's message of "Tue, 1 Aug 2000 15:58:13 -0400 (EDT)"
Message-ID: <[EMAIL PROTECTED]>
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: 06 Aug 2000 08:55:52 +0300
Resent-Message-ID: <"Tfdu73.0.bb1.nRIZv"@mescaline.gnu.org>
Resent-From: bug-hurd@gnu.org
X-Mailing-List: <bug-hurd@gnu.org> archive/latest/2098
X-Loop: bug-hurd@gnu.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
X-UIDL: 8263ee8cc28bcb3cf86aa4fd973ce304
Resent-Bcc:
Status: O
Content-Length: 1849
Lines: 51
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.
>From [EMAIL PROTECTED] Sun Aug 6 22:47:47 2000
Received: from localhost
([127.0.0.1] helo=mailhost.rz.ruhr-uni-bochum.de ident=root)
by localhost with esmtp (Exim 3.12 #1 (Debian))
for [EMAIL PROTECTED]
id 13LXKl-0000Fz-00; Sun, 06 Aug 2000 22:47:47 +0200
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 8626 invoked by alias); 6 Aug 2000 20:43:59 -0000
Received: (qmail 8613 invoked from network); 6 Aug 2000 20:43:58 -0000
Received: from mescaline.gnu.org (158.121.106.21)
by mi-1.rz.ruhr-uni-bochum.de with SMTP; 6 Aug 2000 20:43:58 -0000
Received: (from [EMAIL PROTECTED])
by mescaline.gnu.org (8.9.1a/8.9.1) id QAA26211;
Sun, 6 Aug 2000 16:43:25 -0400
Resent-Date: Sun, 6 Aug 2000 16:43:25 -0400
Received: from hefeweizen.linnaean.org (hefeweizen.cv.linnaean.org
[209.58.179.123])
by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id QAA26182
for <bug-hurd@gnu.org>; Sun, 6 Aug 2000 16:42:46 -0400
Received: from neuralgia.linnaean.org (neuralgia.linnaean.org [198.49.250.5])
by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.6)
with ESMTP id QAA04895;
Sun, 6 Aug 2000 16:42:44 -0400 (EDT)
Received: (from [EMAIL PROTECTED])
by neuralgia.linnaean.org (8.10.2/8.9.3/AI2.12/linnaean.client:2.1) id
e76Kgit12568;
Sun, 6 Aug 2000 16:42:44 -0400 (EDT)
Date: Sun, 6 Aug 2000 16:42:44 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <[EMAIL PROTECTED]>
To: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Cc: bug-hurd@gnu.org
Subject: Re: PPP for Hurd requirements
In-Reply-To: Kalle Olavi Niemitalo's message of , 6 August 2000 08:55:52 +0300
<[EMAIL PROTECTED]>
X-Windows: it could happen to you.
Resent-Message-ID: <"SGjCS1.0.GP6.AtSZv"@mescaline.gnu.org>
Resent-From: bug-hurd@gnu.org
X-Mailing-List: <bug-hurd@gnu.org> archive/latest/2099
X-Loop: bug-hurd@gnu.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
X-UIDL: b355ed05fd3021cb6a85e4515f597198
Resent-Bcc:
Status: O
Content-Length: 3161
Lines: 69
> 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.
>From [EMAIL PROTECTED] Mon Aug 7 01:12:19 2000
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 2 (Debian))
id 13LZad-0000Jq-00; Sun, 06 Aug 2000 18:12:19 -0500
Received: (qmail 32301 invoked by uid 38); 6 Aug 2000 23:12:03 -0000
Resent-Date: 6 Aug 2000 23:12:03 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 32276 invoked from network); 6 Aug 2000 23:12:01 -0000
Received: from cr922373-a.slnt1.on.wave.home.com (HELO corum.multiverse.qc.ca)
([EMAIL PROTECTED])
by murphy.debian.org with SMTP; 6 Aug 2000 23:12:01 -0000
Received: from igor by corum.multiverse.qc.ca with local (Exim 3.12 #1 (Debian))
id 13LZY0-00022s-00; Sun, 06 Aug 2000 19:09:36 -0400
Date: Sun, 6 Aug 2000 19:09:36 -0400
From: Igor Khavkine <[EMAIL PROTECTED]>
To: Roland McGrath <[EMAIL PROTECTED]>
Cc: debian-hurd@lists.debian.org
Subject: Re: PPP for Hurd requirements
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sun, Aug 06, 2000
at 04:42:44PM -0400
Sender: <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/5046
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 2022
Lines: 46
On Sun, Aug 06, 2000 at 04:42:44PM -0400, Roland McGrath wrote:
> > 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.)
Why not unify all the different kind of link level devices with a "tun"
interface as suggested before. That way pfinet need know nothing about what
kind of device it's receiving frames from. And there should be a translator
that sits on top of the eth and ppp intefaces translating the incoming frames
into tun frames. Then once pfinet is fixed and stabilised there is no need to
update the code in order to support other protocols.
Igor
>From [EMAIL PROTECTED] Mon Aug 7 02:10:37 2000
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 2 (Debian))
id 13LaV3-000673-00; Sun, 06 Aug 2000 19:10:37 -0500
Received: (qmail 14919 invoked by uid 38); 7 Aug 2000 00:10:37 -0000
Resent-Date: 7 Aug 2000 00:10:37 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 14895 invoked from network); 7 Aug 2000 00:10:36 -0000
Received: from hefeweizen.cv.linnaean.org (HELO hefeweizen.linnaean.org)
(209.58.179.123)
by murphy.debian.org with SMTP; 7 Aug 2000 00:10:36 -0000
Received: from neuralgia.linnaean.org (neuralgia.linnaean.org [198.49.250.5])
by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.6)
with ESMTP id UAA06025;
Sun, 6 Aug 2000 20:10:29 -0400 (EDT)
Received: (from [EMAIL PROTECTED])
by neuralgia.linnaean.org (8.10.2/8.9.3/AI2.12/linnaean.client:2.1) id
e770ASI13029;
Sun, 6 Aug 2000 20:10:28 -0400 (EDT)
Date: Sun, 6 Aug 2000 20:10:28 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
From: Roland McGrath <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Igor Khavkine <[EMAIL PROTECTED]>
Cc: debian-hurd@lists.debian.org
Subject: Re: PPP for Hurd requirements
In-Reply-To: Igor Khavkine's message of Sun, 6 August 2000 19:09:36 -0400
<[EMAIL PROTECTED]>
X-Zippy-Says: A dwarf is passing out somewhere in Detroit!
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/5047
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 759
Lines: 13
> Why not unify all the different kind of link level devices with a "tun"
> interface as suggested before. That way pfinet need know nothing about
> what kind of device it's receiving frames from. And there should be a
> translator that sits on top of the eth and ppp intefaces translating the
> incoming frames into tun frames. Then once pfinet is fixed and stabilised
> there is no need to update the code in order to support other protocols.
You are missing the fundamental point of the design. The very purpose is
to have the clean and flexible layering you describe without necessarily
requiring the overhead of passing data through multiple translator
processes. If you are not clear on the analog to libstore, please take a
look at how that works.
>From [EMAIL PROTECTED] Mon Aug 7 06:03:13 2000
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 2 (Debian))
id 13Le89-0000Ki-00; Sun, 06 Aug 2000 23:03:13 -0500
Received: (qmail 2682 invoked by uid 38); 7 Aug 2000 04:03:12 -0000
Resent-Date: 7 Aug 2000 04:03:12 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 2648 invoked from network); 7 Aug 2000 04:03:12 -0000
Received: from cr922373-a.slnt1.on.wave.home.com (HELO corum.multiverse.qc.ca)
([EMAIL PROTECTED])
by murphy.debian.org with SMTP; 7 Aug 2000 04:03:12 -0000
Received: from igor by corum.multiverse.qc.ca with local (Exim 3.12 #1 (Debian))
id 13Le6U-0002BN-00; Mon, 07 Aug 2000 00:01:30 -0400
Date: Mon, 7 Aug 2000 00:01:29 -0400
From: Igor Khavkine <[EMAIL PROTECTED]>
To: Roland McGrath <[EMAIL PROTECTED]>
Cc: debian-hurd@lists.debian.org
Subject: Re: PPP for Hurd requirements
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sun, Aug 06, 2000
at 08:10:28PM -0400
Sender: <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/5048
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 1876
Lines: 35
On Sun, Aug 06, 2000 at 08:10:28PM -0400, Roland McGrath wrote:
> > Why not unify all the different kind of link level devices with a "tun"
> > interface as suggested before. That way pfinet need know nothing about
> > what kind of device it's receiving frames from. And there should be a
> > translator that sits on top of the eth and ppp intefaces translating the
> > incoming frames into tun frames. Then once pfinet is fixed and stabilised
> > there is no need to update the code in order to support other protocols.
>
> You are missing the fundamental point of the design. The very purpose is
> to have the clean and flexible layering you describe without necessarily
> requiring the overhead of passing data through multiple translator
> processes. If you are not clear on the analog to libstore, please take a
> look at how that works.
I understand the analogy to libstore, i.e. creating an common API for eth,
ppp and others that pfinet could use transparently. I also think that's a
good idea. However in a previous message you also suggested that pfinet
would have to be aware of the format of ppp and ethernet frames and be able
to distinguish between then. This however seems the wrong way to go about
things.
My main idea was that pfinet should treat all network interfaces the same. The
question of whether this normalization of ppp and ethernet frames should be
done by a translator or a common API is a detail of implementation. If a
translator involves too much overhead then it might not be a good idea. You
must forgive that slip on my part, afterall, like Marcus says "everything
is a translator." :-)
I must admit I don't know much about link level communication protocols so
I'm not really sure what ethernet and ppp frames look like and how they
could both be passed in the same form to pfinet. But that again is an
implementation detail.
Igor
>From [EMAIL PROTECTED] Mon Aug 7 06:13:06 2000
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 2 (Debian))
id 13LeHi-0000TB-00; Sun, 06 Aug 2000 23:13:06 -0500
Received: (qmail 5796 invoked by uid 38); 7 Aug 2000 04:13:06 -0000
Resent-Date: 7 Aug 2000 04:13:06 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 5771 invoked from network); 7 Aug 2000 04:13:05 -0000
Received: from hefeweizen.cv.linnaean.org (HELO hefeweizen.linnaean.org)
(209.58.179.123)
by murphy.debian.org with SMTP; 7 Aug 2000 04:13:05 -0000
Received: from neuralgia.linnaean.org (neuralgia.linnaean.org [198.49.250.5])
by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.6)
with ESMTP id AAA07203;
Mon, 7 Aug 2000 00:13:03 -0400 (EDT)
Received: (from [EMAIL PROTECTED])
by neuralgia.linnaean.org (8.10.2/8.9.3/AI2.12/linnaean.client:2.1) id
e774D3813752;
Mon, 7 Aug 2000 00:13:03 -0400 (EDT)
Date: Mon, 7 Aug 2000 00:13:03 -0400 (EDT)
Message-Id: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <[EMAIL PROTECTED]>
To: Igor Khavkine <[EMAIL PROTECTED]>
Cc: debian-hurd@lists.debian.org
Subject: Re: PPP for Hurd requirements
In-Reply-To: Igor Khavkine's message of Mon, 7 August 2000 00:01:29 -0400
<[EMAIL PROTECTED]>
Emacs: the Swiss Army of Editors.
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/5049
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 488
Lines: 10
> I understand the analogy to libstore, i.e. creating an common API for eth,
> ppp and others that pfinet could use transparently. I also think that's a
> good idea. However in a previous message you also suggested that pfinet
> would have to be aware of the format of ppp and ethernet frames and be able
> to distinguish between then. This however seems the wrong way to go about
> things.
You just misunderstood my earlier message. I don't think there is anything
to disagree about.
>From [EMAIL PROTECTED] Wed Aug 9 13:59:46 2000
Received: from localhost
([127.0.0.1] helo=mailhost.rz.ruhr-uni-bochum.de ident=root)
by localhost with esmtp (Exim 3.12 #1 (Debian))
for [EMAIL PROTECTED]
id 13MUWQ-00005A-00; Wed, 09 Aug 2000 13:59:46 +0200
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 17639 invoked by alias); 9 Aug 2000 08:29:49 -0000
Received: (qmail 17615 invoked from network); 9 Aug 2000 08:29:47 -0000
Received: from mescaline.gnu.org (158.121.106.21)
by mi-1.rz.ruhr-uni-bochum.de with SMTP; 9 Aug 2000 08:29:47 -0000
Received: (from [EMAIL PROTECTED])
by mescaline.gnu.org (8.9.1a/8.9.1) id EAA02447;
Wed, 9 Aug 2000 04:29:14 -0400
Resent-Date: Wed, 9 Aug 2000 04:29:14 -0400
Received: from PC486.Niemitalo.local ([EMAIL PROTECTED] [212.38.245.174])
by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id EAA02412
for <bug-hurd@gnu.org>; Wed, 9 Aug 2000 04:28:23 -0400
Received: from kalle by PC486.Niemitalo.local with local (Exim 3.12 #1 (Debian))
id 13LqG5-0000UB-00; Mon, 07 Aug 2000 20:00:13 +0300
To: bug-hurd@gnu.org
Subject: Re: PPP for Hurd requirements
References: <[EMAIL PROTECTED]>
X-Accept-Language: fi;q=1.0, en;q=0.9, sv;q=0.5, de;q=0.1
X-URL: http://stekt.oulu.fi/~tosi/
X-Anagram: look vanilla, aim elite
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: 07 Aug 2000 20:00:11 +0300
In-Reply-To: Roland McGrath's message of "Sun, 6 Aug 2000 16:42:44 -0400 (EDT)"
Message-ID: <[EMAIL PROTECTED]>
X-Mailer: Gnus v5.7/Emacs 20.6
Resent-Message-ID: <"Hz9xV1.0.zb.qOHav"@mescaline.gnu.org>
Resent-From: bug-hurd@gnu.org
X-Mailing-List: <bug-hurd@gnu.org> archive/latest/2109
X-Loop: bug-hurd@gnu.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
X-UIDL: 54918785a3d6b1cbd0ecdd59f5f8acdc
Resent-Bcc:
Status: O
Content-Length: 1067
Lines: 23
Roland McGrath <[EMAIL PROTECTED]> writes:
> (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.
Well actually I thought they would deliver datagrams tagged with
some kind of type words. I'm not familiar with PPP frames (yet).
> All it needs is an interface to the channelio
> devices to receive copies of packets going elsewhere.
The pfinet process will be talking directly to the Mach device.
Would such snooping be done in Mach or in libchannel? In the
latter case, file_get_channel_info could take an extra port
parameter which says where to send snoop requests. Libchannel
would set up such a port and listen to it. This would allow a
treacherous program to circumvent snooping and send frames
directly to the device, but file_get_channel_info shouldn't give
device send rights to untrusted processes anyway.
If I were to run pfinet and pfipx at the same time, how would
incoming frames be delivered to the right place?
>From [EMAIL PROTECTED] Sun Aug 12 14:38:38 2001
Received: from porta.u64.de ([194.77.88.106])
by fencepost.gnu.org with smtp (Exim 3.22 #1 (Debian))
id 15VuVq-0000ls-00
for <help-hurd@gnu.org>; Sun, 12 Aug 2001 08:38:38 -0400
Received: from (localhost) [212.23.136.22] (mail)
by porta.u64.de with asmtp (Exim 3.12 #1 (Debian))
id 15Vv2v-0007H6-00; Sun, 12 Aug 2001 15:12:50 +0200
Received: from marcus by localhost with local (Exim 3.31 #1 (Debian))
id 15VuVj-0000a1-00; Sun, 12 Aug 2001 14:38:31 +0200
Date: Sun, 12 Aug 2001 14:38:31 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Niels =?iso-8859-1?Q?M=F6ller?= <[EMAIL PROTECTED]>
Cc: Johan Rydberg <[EMAIL PROTECTED]>, help-hurd@gnu.org
Subject: Re: Where can I find /hurd/mouse ?
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.3.20i
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: help-hurd@gnu.org
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:help-hurd@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-hurd>,
<mailto:[EMAIL PROTECTED]>
List-Id: Users list for the GNU Hurd <help-hurd.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-hurd>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://mail.gnu.org/pipermail/help-hurd/>
Status: O
Content-Length: 1024
Lines: 24
On Sat, Aug 11, 2001 at 01:29:52PM +0200, Niels M?ller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > In the long term we want to have mouse and kbd integrated in
> > streamio/libchannel)
>
> What is streamio/libchannel? IIRC it doesn't exist yet. Is there any
> design of it? Simply a list of what kinds of operations (rpc:s) it
> should offer would be a good thing to have, I think.
streamio exists. libchannel should be to character streams what libstore is
to block oriented data media. The idea was to have loadable modules to
provide the necessary ioctls etc for a device (as character devices usually
live and die not with their basic function of reading and writing data, but
the additional interface that controls the behvaiour and data stream).
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
>From [EMAIL PROTECTED] Fri Aug 31 20:08:42 2001
Received: from green.nl.gxn.net ([62.100.30.36])
by fencepost.gnu.org with esmtp (Exim 3.22 #1 (Debian))
id 15csig-0006Nr-00
for <help-hurd@gnu.org>; Fri, 31 Aug 2001 14:08:42 -0400
Received: from prof.vaag(asd-tel-ap01-d07-115.dial.freesurf.nl[62.100.6.115])
(1667 bytes) by green.nl.gxn.net
via sendmail with P:esmtp/R:inet_hosts/T:smtp
(sender: <[EMAIL PROTECTED]>)
id <[EMAIL PROTECTED]>
for <help-hurd@gnu.org>; Fri, 31 Aug 2001 20:08:39 +0200 (MET DST)
(Smail-3.2.0.106-3 1999-Mar-31 #11 built DST-Sep-7)
Received: from gerhardm by prof.vaag with local (Exim 3.22 #1 (Debian))
id 15cctK-0000yR-00
for <help-hurd@gnu.org>; Fri, 31 Aug 2001 03:14:38 +0200
Date: Fri, 31 Aug 2001 03:14:38 +0200
To: help-hurd@gnu.org
Subject: Re: Where can I find /hurd/mouse ?
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.3.18i
From: Gerhard Muntingh <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: help-hurd@gnu.org
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:help-hurd@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-hurd>,
<mailto:[EMAIL PROTECTED]>
List-Id: Users list for the GNU Hurd <help-hurd.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-hurd>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://mail.gnu.org/pipermail/help-hurd/>
Status: O
Content-Length: 840
Lines: 20
> > > In the long term we want to have mouse and kbd integrated in
> > > streamio/libchannel)
> >
> > What is streamio/libchannel? IIRC it doesn't exist yet. Is there any
> > design of it? Simply a list of what kinds of operations (rpc:s) it
> > should offer would be a good thing to have, I think.
>
> streamio exists. libchannel should be to character streams what libstore is
> to block oriented data media. The idea was to have loadable modules to
> provide the necessary ioctls etc for a device (as character devices usually
> live and die not with their basic function of reading and writing data, but
> the additional interface that controls the behvaiour and data stream).
>
The loadable modules approach seems great, we might one day want audio/video
over such a channel. User interface isn't limited to kbd/mouse.
smunt
>From [EMAIL PROTECTED] Wed Jan 30 18:40:48 2002
Return-path: <[EMAIL PROTECTED]>
Received: from murphy.debian.org [216.234.231.6]
by master.debian.org with smtp (Exim 3.12 1 (Debian))
id 16Vyj2-0006mb-00; Wed, 30 Jan 2002 11:40:48 -0600
Received: (qmail 26355 invoked by uid 38); 30 Jan 2002 17:40:48 -0000
Resent-Date: 30 Jan 2002 17:40:48 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Received: (qmail 26322 invoked from network); 30 Jan 2002 17:40:46 -0000
Received: from porta.u64.de (194.77.88.106)
by murphy.debian.org with SMTP; 30 Jan 2002 17:40:46 -0000
Received: from (localhost) [212.23.136.22]
by porta.u64.de with asmtp (Exim 3.12 #1 (Debian))
id 16Vz5z-00086b-00; Wed, 30 Jan 2002 19:04:32 +0100
Received: from marcus by localhost with local (Exim 3.34 #1 (Debian))
id 16Vyik-0000NG-00; Wed, 30 Jan 2002 18:40:30 +0100
Date: Wed, 30 Jan 2002 18:40:30 +0100
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Derek L Davies <[EMAIL PROTECTED]>
Cc: Neal H Walfield <[EMAIL PROTECTED]>, debian-hurd@lists.debian.org
Subject: Re: Not enough entropy in RNG
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.3.27i
Sender: Marcus Brinkmann <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-hurd@lists.debian.org
X-Mailing-List: <debian-hurd@lists.debian.org> archive/latest/10602
X-Loop: debian-hurd@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Status: O
Content-Length: 1617
Lines: 37
On Wed, Jan 30, 2002 at 12:14:29PM -0500, Derek L Davies wrote:
> Has anyone sketched out an API for libchannel?
No, you have first go. Dust off your drawing board ;)
> put /dev/random in an oskit driver and use libchannel to do
> I/O with it. And this way the need for user space egd goes away.
Indeed. Well, you can support it anyway by writing a special channel class
for it (or by just using some generic socket channel or whatever)
> The spirts seem to want me to work on libchannel ;-) So I'll give it
> a try. I'll search the archives for libchannel discussions, but if
> people have info that would help that isn't in the archvies please
> forward it to me.
Roland posted a bit about it, but it all boils down that it is to character
streams what libstore is to block data.
The one thing we need in libchannel we haven't equivalently in libstore is
some way for extending the API on a per-channel-class basis. For example,
for a channel to a sound card raw audio device, you need some way to set the
sample bit rate. For a mouse device you might want to set/clear dtr. For a
keyboard you might want to set/clear raw mode. Etc. Some of this can be
done in the channel class, opaque to the user, but some things can not. I
think the idea was to have dynamically loadable plugins that add this
functionality. But you can probably leave this for later.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
