Yep.
: 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 think it is possible even without a rewrite of syncppp.c. The
slaves should be generated on the fly using some ioctl (which gets
a PVC #, and returns the slave name, for example). And of course some
ioctl for deleting the slave, and one for seting a link-protocol
(maybe we should delete SPPPIOCCISCO and SPPPIOCPPP and make one
ioctl with a parameter for setting the link-level protocol).
: I have a month of free time now, so I expect to have it done, after all
: design issues are resolved.
I am ready to help you with the design, testing and maybe some
coding (not much, because I don't have lots of free time, but some).
I can even provide space at the linux.cz listserver for a
mailing list, and the CVS at cvs.linux.cz.
: 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.
Well, I think it is a marginal issue. The syncppp.c can be
modified for character device even after the FR is written. I even
thought about going opposite way: to add the character device as one
of the link protocols. Using this, the task queues, etc will be
at one place for all sync drivers.
I would like to focus on writing the FR layer for syncppp.c first.
-Yenya
-- \ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// The new code base has not stabilized enough yet for benchmarking. Be patient, we'll be sure to delay NT5's release a bit, trust me... (DaveM)- 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/