Date: Tue, 25 Jun 1996 19:45:35 -0400 From: dennis@etinc.com (Dennis) To: "JULIAN Elischer" <julian@ref.tfs.com> Cc: hackers@freebsd.org Subject: Re: Frame relay and ATM support: virtual interface per vpi? Message-ID: <199606252345.TAA20076@etinc.com>
next in thread | raw e-mail | index | archive | help
>> >> >> virtual interface per vpi is what i'm doing for MINI. I have to: MINI >> looks like 4096 atm interfaces *at the hardware level*, so the carrying >> that through to the OS and applications makes sense. >> >> I vote for the virtual interface approach ... >err yukk! >:) > >what do you mean "at the hardware"? >does it have 4096 interrupt vectors and 4096 shared memeory buffers? > >I put it to you that there is only one driver running, with >one 'instance' of itself, and that there is only one >line to the outside, and one "packet's received" counter. >(well there may be more I guess). I also guess that you can't run one >at one speed and another at another speed... >If you bring down the interface, they should all stop etc.etc. >in other words, while your hardware might support 4096 VCIs I'll >bet that I can make as good an argument for having one interface as you can for >having many.. >One might as well argue that ethjernet should be implimented by having >a separate virtual interface for every machine for which there is an >ARP table entry. > >I'm not really arguing AGAINST you rather than trying to understand the reasons >being used as If I start writing something that will be available in FreeBSD >as a standard interface (in much the same way that my SCSI interface is >the standard interface for BSD scsi drivers) for VC based interfaces >then I don;t want to have to REWRITE it too many times when I find that >the original method is unworkable.. > >julian You'll never do it in a way that makes everybody happy, so just make sure that you don't hack anything in the O/S that make other potential implementations unworkable. The worst thing that you can do is to force the O/S into only working with your implementation. Our frame implementation for freebsd is approaching perfection, and I'd hate to see all of the effort and gains made with freebsd go to waste just so some hackers can have source. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606252345.TAA20076>