> 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/