>From list@lists.debian.org Tue Aug 1 21:58:28 2000 Return-path: 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: roland@frob.com 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 roland@localhost) 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: <200008011958.e71JwD519912@neuralgia.linnaean.org> From: Roland McGrath MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Marcus Brinkmann Cc: Eric Gibson , 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 <20000801214110.G2814@ulysses.dhis.net> Emacs: well, why *shouldn't* you pay property taxes on your editor? Resent-Message-ID: Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/4957 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: maor-list-archive@debian.org 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 tosi@ees2.oulu.fi 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 marcus@localhost id 13LNVB-00005P-00; Sun, 06 Aug 2000 12:17:53 +0200 Delivered-To: Marcus.Brinkmann@ruhr-uni-bochum.de 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 slist@localhost) 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 (mail@4-365.dyn.sirkus.com [212.38.245.238]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id EAA06481 for ; 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: <200008011958.e71JwD519912@neuralgia.linnaean.org> 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: <87lmycnk38.fsf@PC486.Niemitalo.local> From: Kalle Olavi Niemitalo 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: archive/latest/2098 X-Loop: bug-hurd@gnu.org Precedence: list Resent-Sender: bug-hurd-request@gnu.org X-UIDL: 8263ee8cc28bcb3cf86aa4fd973ce304 Resent-Bcc: Status: O Content-Length: 1849 Lines: 51 Switching to the right list... Roland McGrath 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 roland@gnu.org 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 marcus@localhost id 13LXKl-0000Fz-00; Sun, 06 Aug 2000 22:47:47 +0200 Delivered-To: Marcus.Brinkmann@ruhr-uni-bochum.de 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 slist@localhost) 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 ; 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 roland@localhost) 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: <200008062042.e76Kgit12568@neuralgia.linnaean.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Kalle Olavi Niemitalo 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 <87lmycnk38.fsf@PC486.Niemitalo.local> 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: archive/latest/2099 X-Loop: bug-hurd@gnu.org Precedence: list Resent-Sender: bug-hurd-request@gnu.org 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 list@lists.debian.org Mon Aug 7 01:12:19 2000 Return-path: 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: igor@multiverse.dhs.org 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) (mail@24.42.213.92) 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 To: Roland McGrath Cc: debian-hurd@lists.debian.org Subject: Re: PPP for Hurd requirements Message-ID: <20000806190936.A7068@corum.multiverse.qc.ca> References: <87lmycnk38.fsf@PC486.Niemitalo.local> <200008062042.e76Kgit12568@neuralgia.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008062042.e76Kgit12568@neuralgia.linnaean.org>; from roland@gnu.org on Sun, Aug 06, 2000 at 04:42:44PM -0400 Sender: Resent-Message-ID: Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/5046 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: maor-list-archive@debian.org 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 list@lists.debian.org Mon Aug 7 02:10:37 2000 Return-path: 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: roland@frob.com 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 roland@localhost) 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: <200008070010.e770ASI13029@neuralgia.linnaean.org> From: Roland McGrath MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Igor Khavkine 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 <20000806190936.A7068@corum.multiverse.qc.ca> X-Zippy-Says: A dwarf is passing out somewhere in Detroit! Resent-Message-ID: Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/5047 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: maor-list-archive@debian.org 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 list@lists.debian.org Mon Aug 7 06:03:13 2000 Return-path: 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: igor@multiverse.dhs.org 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) (mail@24.42.213.92) 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 To: Roland McGrath Cc: debian-hurd@lists.debian.org Subject: Re: PPP for Hurd requirements Message-ID: <20000807000129.A8384@corum.multiverse.qc.ca> References: <20000806190936.A7068@corum.multiverse.qc.ca> <200008070010.e770ASI13029@neuralgia.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200008070010.e770ASI13029@neuralgia.linnaean.org>; from roland@frob.com on Sun, Aug 06, 2000 at 08:10:28PM -0400 Sender: Resent-Message-ID: <0opLND.A.zp.AUjj5@murphy> Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/5048 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: maor-list-archive@debian.org 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 list@lists.debian.org Mon Aug 7 06:13:06 2000 Return-path: 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: roland@frob.com 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 roland@localhost) 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: <200008070413.e774D3813752@neuralgia.linnaean.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Igor Khavkine 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 <20000807000129.A8384@corum.multiverse.qc.ca> Emacs: the Swiss Army of Editors. Resent-Message-ID: Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/5049 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: maor-list-archive@debian.org 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 tosi@ees2.oulu.fi 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 marcus@localhost id 13MUWQ-00005A-00; Wed, 09 Aug 2000 13:59:46 +0200 Delivered-To: Marcus.Brinkmann@ruhr-uni-bochum.de 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 slist@localhost) 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 (mail@4-301.dyn.sirkus.com [212.38.245.174]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id EAA02412 for ; 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: <200008062042.e76Kgit12568@neuralgia.linnaean.org> 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 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: <874s4x0zxg.fsf@PC486.Niemitalo.local> 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: archive/latest/2109 X-Loop: bug-hurd@gnu.org Precedence: list Resent-Sender: bug-hurd-request@gnu.org X-UIDL: 54918785a3d6b1cbd0ecdd59f5f8acdc Resent-Bcc: Status: O Content-Length: 1067 Lines: 23 Roland McGrath 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 help-hurd-admin@gnu.org 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 ; 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 To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Johan Rydberg , help-hurd@gnu.org Subject: Re: Where can I find /hurd/mouse ? Message-ID: <20010812143831.C903@212.23.136.22> References: <3B729591.882318DA@netinsight.se> <20010809170600.C186@212.23.136.22> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.20i Sender: help-hurd-admin@gnu.org Errors-To: help-hurd-admin@gnu.org X-BeenThere: help-hurd@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Hurd List-Unsubscribe: , List-Archive: Status: O Content-Length: 1024 Lines: 24 On Sat, Aug 11, 2001 at 01:29:52PM +0200, Niels M?ller wrote: > Marcus Brinkmann 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 brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de >From help-hurd-admin@gnu.org 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 ; 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: ) id for ; 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 ; 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: <20010831031438.A3735@nohost.nowhere> References: <3B729591.882318DA@netinsight.se> <20010809170600.C186@212.23.136.22> <20010812143831.C903@212.23.136.22> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010812143831.C903@212.23.136.22> User-Agent: Mutt/1.3.18i From: Gerhard Muntingh Sender: help-hurd-admin@gnu.org Errors-To: help-hurd-admin@gnu.org X-BeenThere: help-hurd@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Hurd List-Unsubscribe: , List-Archive: 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 list@lists.debian.org Wed Jan 30 18:40:48 2002 Return-path: 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: Marcus.Brinkmann@ruhr-uni-bochum.de 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 To: Derek L Davies Cc: Neal H Walfield , debian-hurd@lists.debian.org Subject: Re: Not enough entropy in RNG Message-ID: <20020130174030.GF808@212.23.136.22> References: <87d6ztzp0h.fsf@bassanio.walfield.org> <20020129164622.GA850@212.23.136.22> <20020130155032.GA808@212.23.136.22> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: Marcus Brinkmann Resent-Message-ID: <7InN6B.A.vbG.gADW8@murphy> Resent-From: debian-hurd@lists.debian.org X-Mailing-List: archive/latest/10602 X-Loop: debian-hurd@lists.debian.org Precedence: list Resent-Sender: debian-hurd-request@lists.debian.org Delivered-To: joy-list-archive@debian.org 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 brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de