>As I mentioned above, we CAN license the driver code and the DDK for >development. This means that you could produce FreeBSD drivers which we >could then distribute in a binary form under a free end-user license. >
>Frankly this is the only way I can see that FreeBSD drivers for the 5xx >series would ever come about. Porting SAND over, while having >advantages >of long term support, is just overkill for this, besides which it's unlikely >you will get a FreeBSD developer to work on GPL code. >This would end up putting a WANic 5xx driver into the same status as the >drivers for the Emerging Technologies, or Sangoma sync cards, which both >come >with binary-only FreeBSD drivers. It would actually have a leg up over >those drivers because it would have Netgraph hooks and I believe that the >Sangoma drivers don't (but I've never worked with the Sangoma cards so I >don't know for certain) The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that have integrated bandwidth management and prioritization, WAN bridging support, load balancing and a probably 25% performance advantage is a bit entertaining. Unless you need to do some convoluted encapsulation netgraph is, aside from being appallingly non-standard to anything else in the market, not much of an "advantage", and its a poster child for the trade off of "flexibility" versus performance. Lets face it. If you were going to sit down and design an interface for frame relay, multi-protocol support, etc, you'd have to be smoking something pretty strong to come up with netgraph. But its free and there is source, so it must be great! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
