Messages in this thread | | | Subject | Re: Frame Relay generic driver | From | Krzysztof Halasa <> | Date | 03 Jul 1999 13:21:03 +0200 |
| |
Jan Kasprzak <kas@informatics.muni.cz> writes:
> did you make any progress with it?
Not in the real code yet. I have the docs now, and the task seems to be not very hard to write. In fact, integrating FR with the rest of kernel _the_right_way_ seems to be harder.
> I need to write the FR interface > for COSA sync serial boards (www.fi.muni.cz/~kas/cosa), and I need to > decide whether it would be better to write my own FR layer (and probably > merge it to syncppp.c), or adapt one of the existing ones (most probably > Mike Natale's FR layer for SDL Riscoms - what is the license of it?).
SDL requires NDA for their fr routines. Their Linux developer/distributor - Imagestream - distributes only binary kernel modules, and has probably more restrictive license (you are IMHO not even permitted to distribute binaries freely, at least I got it this way). BTW, at least older drivers from SDL and then from Imagestream don't work in real environment - there are memory leaks there and other problems.
In fact, I have few SDL cards. They are quite good in Cisco, but I'd like some of them to do FR instead.
> The SDL driver can be a good starting point as well as the source > of documentation.
Not very :-(
> However, I am not sure whether its approach is correct: > It uses one netdev for each channel, and inside this device you can set > particular PVCs using the "frarp" utility. This essentialy maps > the remote IP address to the PVC number. It makes it impossible to transmit > anything but IP over that device, I think.
Sure, it has one device for one serial port (not for each PVC). It seems it isn't good even for transmitting IP - you may require different IPs for different DLCIs, and I don't think their FR code has such capability. At least older drivers behave this way.
> The Sangoma driver (drivers/net/dlci.c), OTOH, uses one master > device and lots of slaves - one per PVC. I think this would be a better > approach. But it will IMHO fit less to syncppp.c.
I think syncppp.c should be rewritten a little. Then there would be a place for one master device (used for PPP/Cisco/LMI interface), and for slaves for each PVC.
I have a month of free time now, so I expect to have it done, after all design issues are resolved.
One of them: moving all sync drivers from net to char devices (they are serial ports as async ones), and adding ppp/fr/cisco/whatever drivers the same way as async SLIP and PPP. Of course, we should use frame- oriented interface there. That would simplify hardware drivers, and there would be consistent interface to all sync network devices (common names, etc). We shouldn't lose performance that way.
Anyway, I've started coding. -- Krzysztof Halasa Network Administrator
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |