Date: Mon, 23 Sep 1996 10:23:24 +0200 From: Stefan Grefen <grefen@carpe.net> To: Julian Elischer <julian@whistle.com> Cc: atm@freebsd.org, hm@kts.org, rminnich@Sarnoff.COM, dennis@etinc.com Subject: Re: VC support, *BSD and atm/frame/isdn Message-ID: <3139.843467004@hex.grefen.carpe.net> In-Reply-To: Julian Elischer's message <3245F162.5656AEC7@whistle.com> of Sun, 22 Sep 96 19:09:38 PDT. References: <3244E619.ABD322C@whistle.com> <1892.843437138@hex.grefen.carpe.net> <3245F162.5656AEC7@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3245F162.5656AEC7@whistle.com> Julian Elischer wrote: > Stefan Grefen wrote: > > In message <3244E619.ABD322C@whistle.com> Julian Elischer wrote: > > [...] > > I see someone else is working on this too. The basic code should > > be shared between all implementations, so that the modules can be > > reused for different hardware devices. > Well I agree, but do we have any of the other players? > I know that dennis' main comment was "don't break what already works" > and I have to admit that that must be a primary goal. > Also, re-used with different transports.. > I wonder if there is a better forum for this, and what about the > Net/Open-BSD guys? If there is existing code doing something like thise (besides your stuff that I know) I would like to have look at it so I don't do it differently. Why should there be a problem with different transports? Basic stuff like the MTU needs to be configurable by the transport, and existing modules may be needed to split in a protocol and a transport part (if there is a transport depended address in it). BTW. I'm running NetBSD and BSDI's BSD/OS, which both share the problem of dynamnic devices. But I think this is not a major problem for interfaces, You just can't free the associatet memory chunk (dangling pointer problem). I've done that with pcmcia-devices in NetBSD and could attach/detatch/reattach them. > > > > Reading that, > > Anybody thought of implementing a rudimentary STREAMS version (with the > > possibility to make the head end in an interface to be compatible with the > > rest of the kernel). > yes, that's (kind of) what OSF did.. Kind of, the lower levels are even more nasty (at least in /AD). > > > > > We would simply redesign the streams functionality in incompatible way. > > (I don't think we would come up with a programming model that so much bette > r > > than streams, that it is worth to be incompatible ( I DIDN'T said it can't > be > > done better, but this is another research project)). > > At the moment I get paid for hacking streams-modules, and I volunteer to > > work on this STREAMS for BSD stuff. > > The only tricky (and maybe incompatible) thing would be the usage of MBUFS > > instead of STREAMS mblk_t / datab pairs.. > > The main thing I want to get to is to complete teh transition > in teh way that mbufs are considered, (from the original) > buffer with a descriptor structure tacked on teh front, > to a buffer descriptor which "HAPPENS" to come with a ready made buffer > but usually doens't use it.. > OSF have a NEAT way of doing this.. > and I think Matt Thomas is considering > adding it to the kernel. > it allows random malloc'd memory to be used > to hold net data (or any other random allocation scheme). Thats the same thing streams do, and MBUFS are able to hold 'external' memory today (at the cost of a wasted MBUF per memory chunk, which is unaccapetable for a streams/MBUF gateway). > > it's really a sematic differnece, but Van jacobson, in his rehash, had > a replacement that I forget the name of, > In his scheme, the buffer portion of the mbuf was ALWAYS a separate > memory chunk. The descriptors were only the front art of the current > mbuf. > anyway I digress. > yes something that has at least LEARNED from STREAMS would be good, > even if it ISN'T STREAMS. (Not to decide right now) If we would agree on model for the modules, that is streams with exeception that msgb_t is a struct mbuf, b_rptr=mh_data and b_wptr=mh_data+mh_len and forget about the data blocks, we would have the structure as the streams systeam and if Matt adds his stuff, we could even go to using data blocks with out wasting an MBUF each time. As I said before, there may be a better model for this, but streams is a working model for stacking protocol modules. > > > > > We would solve all of our problems here (and we could reuse our modules > > for SYS5 systems or SYS5 modules as available) ... > > > > This would be a (kind of) IF per VC structure. > > But below that IF multiplexor modules can merge any number of real interfac > es > > It doesn't help NetBSD and Open BSD, but I (for the Interjet) > was considering making devices flash in and out of existance in the > device filesystem for control purposes, Thats missing in Net/open yet, but I don't comsider that as a major problem. > rather than in the 'if-space'. thus the actual frame card would be a > DEVICE > rather than an interface, and the VCs would be Interfaces, unlike > in my present code, where both levels are "interfaces" so that > it gets confusing as to which you should be using.. That was my main objection to stacking interfaces. > > > to any number of pseudo interfaces, plus that the real interface wouldn't > > be a BSD network-interfaces so all above problems wouldn't appear. > > For our *BSD systems an interface would 'magicly' appear with all > > characteristics properly set. > > [...] > Well all very nice. > Other design goals.. > > arbitrary stacking order.. > e.g. > ppp over frame over sync > ppp over frame over ISDN Bmux > ppp over sync > ppp over atm AAL5 pdu > ip over all the above, > ppp over rfc1490 over all the above > etc. > > loadable modules with arbitrary naming > (e.g. link by NAME not address or magic number.."PPP" not 0x03) > etc. etc > > stefan.. you said earier you had 'hacked the sppp code to run on BISDN. > can you share what the hacks were? As I'm using NetBSD I looked at hacking if_ppp.c but did get it working without changes in if_ppp.c. The isdn code attaches to the existing if_ppp. This is for the current BISDN, the rewrite to make it a network protocol is not far enough. > > julian (I'd like to "hack it " to make it a module in the VC package > I sent out..... The NetBSD if_ppp may be a good starting point, as this PPP -async stuff. (the is ppp_tty.c for that). The big problem for me was to get a file-handle for the ioctl-stuff and lcp/chap packets etc. passes up to the pppd daemon. I used existing isdn infrastructure for that (Some resulting kludge was one of my main reasons to reconsider they way isdn is done in the kernel). My stuff should be at ftp.ditec.de:pub/bisdn/ppp. (there is a header file missing, I hope to add today :-)) Stefan > > julian -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3139.843467004>