[openbeosnetteam] Re: Quick question about the stack

Just too expand on what Waldemar had replied already:

> According to the diagram, the stack is very modular (which is good).
> That said, lets use ping for an example.  ping, as an app, only
> "knows about" the libnet.so sockets API, and libnet.so interfaces
> with the stack driver.  

Just a point here: libnet.so isn't limited to sockets API only. 

It implement the Network Names Service API too (getXbyY(), 
getservname(), etc, plus several utilities functions (inet_ntoa(), 
etc).
On some systems, the Name API is exported by a separate libbind.so 
library. BONE do that too, but we choose to follow R5 way: put all in 
libnet.so.

Currently, this Name Service implementation is a port of ISC BIND 
client code, and works fully in this *userland* library, just using 
standard sockets API to do network queries.

It may change in the future, features like ZeroConf/multicast DNS or 
kernelland access to whole sockets APIs will push for moving the Name 
Service into stack too...

> The stack driver interfaces with core, and
> core interfaces with the protocol modules.  Are there any violations
> anywhere in the code to this modularity? 

No. Well, most of the time. :-)

There is a way to control a specific stack module, thru the ioctl() 
opcode Waldemar reported :

control_net_module_args args;

args.name = PPP_INTERFACE_MODULE_NAME;
args.op = op;
args.data = data;
args.length = length;

fd = open("/dev/net/stack"), 
ioctl(fd, NET_STACK_CONTROL_NET_MODULE, &args);

However, it's a private mechanism and should be kept that way:

1) it's not desirable that apps does that themselves, 
2) opcodes supported by network modules are not supposed to be public,
3) we'll add public functions to libnet.so to wrap this mecanism in the 
near future:
  - iterate over loaded network modules names
  - control_net_module() call
  - iterate over network interfaces
  - notify/broadcast network modules a message (think "reload your 
settings" send by Network Preflet)
  - start / stop the whole stack ?

>  For example, any case where
> code in ping.c makes a call directly to a routine in the net stack
> driver, bypassing libnet.so?

No.
 
> Also, where does the ethernet driver fit in?  It looks like the
> ethernet module would interact with the driver, which then obviously
> controls the hardware...

I think Waldemar fully answer this point.
Ethernet module is in fact an "ethernet drivers" wrapper module, 
driving all /dev/net/* ethernet-type devices found.
It's what allow the stack to works with all BeOS ethernet drivers 
already available, a very important point as we don't have to rewrite 
all drivers ourselves.

A last note here: under BeOS R5 net_server design, drivers comes in two 
parts:
- a kernel driver
- a net_server (userland) add-on.

AFAIK, all kernel drivers follow the same Be Inc. sample driver design. 
That means they implement the same behavior, handling the same set of 
ioctl() opcodes. Our ethernet module is compatible with that *API*.

BTW, I really should move the several ether_driver.h files we have to 
headers/private/net directory, and use the constants in ethernet module 
code instead of IF_GETADDR & co! 
So much to do, so little time...

The net_server addons are of no use in our design. 

- Philippe


--
Fortune Cookie Says:

You can't carve your way to success without cutting remarks.

Other related posts: