FreeLists / openbeosnetteam / [openbeosnetteam] Re: PPP API

["Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>]

> I like the idea of "layer names", but failed to understand from code 
> how 
> do you connect each layers between them.
> Could you expand there?

What happens is that you declare yourself, say, ppp/ethernet. The net 
stack, which keeps a register of all active layers, then tries to 
attach all ethernet/* devices underneath you, and to attach you to all 
*/ppp devices. In the case of PPP, since the ppp protocol does things 
itself, pppoe would be something like ppptransport/ethernet, and PPP 
would be ppp/ppptransport. 

> BTW, you try to get the /dev/net/* device max frame size using the 
> wrong ioctl() opcode:
>   int framesize = 0;
>   if (ioctl(fd,ETHER_GETADDR,&framesize,0) <= 0)  // <- should be 
> ETHER_GETFRAMESIZE
>     framesize = 1514;

Oops :P

> Next, having attributs attached to a net packet make sense.
> Your NetPacket class, seem to follow a bone_data, aka iovec'zised 
> buffers, design.
> But I'm wondering how we could reuse these ideas without:
> 1) going full C++ into kernelland :-|
> 2) importing all your IO::* framework...

Well, as I said, the code I posted is mostly for reading. It's slow, 
for a variety of reasons, like using string attribute names (which is 
also a pain in the ass, since they usually come as integers), and it 
requires a ton of support code that we really don't want in the kernel. 
To make things worse in terms of the kernel, all error handling is 
based on C++ exceptions. As I said, for our context, it's mostly for 
reading or for stealing snippets.

> Currently, if we want to use C++ in kernelland, I think it's better 
> to 
> keep any C++ code invisible from outside, otherwise 
> we'll have the classes heritage issue pointed by Axel.
> That means having plain C public API. It apply to stack utilities 
> features used by network modules, too.
> NetPackets falls in this utilities case, don't they?

A few basic, pure abstract, interface classes shouldn't be too 
terrible, like the Net::Layer class. I'm rather fond of Net::Packet, as 
it nicely combines a number of important interfaces (attributes, 
transparent iovec). It is also unlikely to change (what new features 
are packets going to develop?). But so long as we make the C *readable*
, it shouldn't be too bad.

> Maybe it could be made simpler for R1?

Maybe :P
-Nathan

--
Fortune Cookie Says:

That secret you've been guarding, isn't.