Date: Sun, 22 Sep 1996 19:09:38 -0700 From: Julian Elischer <julian@whistle.com> To: grefen@carpe.net Cc: atm@freebsd.org, hm@kts.org, rminnich@Sarnoff.COM, dennis@etinc.com Subject: Re: VC support, *BSD and atm/frame/isdn Message-ID: <3245F162.5656AEC7@whistle.com> References: <3244E619.ABD322C@whistle.com> <1892.843437138@hex.grefen.carpe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Grefen wrote: > > In message <3244E619.ABD322C@whistle.com> Julian Elischer wrote: > > [...] > > > > > Ron, You once indicated that you prefered the etinc style of > > things, where each VC became a separate interface, and indead > > I've been using that style of things here myself. but > > you've been recomending chuck's work, and I see that it has a single > > interface for the hardware, and uses routing tables > > and llinfo (arpish) information to connect VCs with > > logical connections. > > 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? > > 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.. > > 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 better > 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). 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) > > 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 interfaces 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, 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.. > 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? julian (I'd like to "hack it " to make it a module in the VC package I sent out..... julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3245F162.5656AEC7>