[openbeosnetteam] Re: Integration Q's

> Ports :-)
> Won't be that hard. Just have an area where you have your commands, 
> and where the pointers to the packet areas are stored in, and send 
> this from one port to the other (which means copying).

Or even store the commands, packets and other needed stuffs in a big area 
shared between the driver (create_area()) and the net_server (clone_area()), 
and only use driver port <-> net_server port to *notify* about commands 
(just send and area offset, aka 32 bits, smaller copy operation :-) )

In fact, I was remembered about some ksocketd and a driver design I saw one day 
somewhere yesterday, and I found out this today:
http://www.befaqs.com/mirror/classic-be/aboutbe/benewsletter/volume_III/Issue20.html#Insight

The sample-code still could be found here:
http://planetmirror.com.au/pub/beos/samples/add-ons/ofnfs.tgz

Apart that if you (we?) go the userland net stack way for R1, there would be 
many many threads in net_server team:
- one rx_thread per device
- one tx_thread per device (is it necessary ? Even BONE don't do it and let 
the send() / sendto() / write(socket) calling thread block on packet 
transmition (so, it's up to app to use a separate thread if he don't want 
this behavior...)
- one thread (at least) for waiting on read_port() new packets written to 
a socket thru the /dev/net/socket driver

There is a great risk of bottleneck with this design, as all socket i/o would 
be kind of serialized. Bad performance expected. We could have one thread 
looping on read_port() per socket, yep, but woa, (too) many threads then...

But, again, filedescriptor sockets support is yet secondary at this stage. 

Oh, btw, some side ideas:

- MTU/MRU are usefull, particulary with other net media (ATM, to speak 
of one I'm wrestling with on my Alcatel Speed Touch USB ADSL Modem driver
project...). 
In BeOS net_server, it's the BNetDevice addon who give this limit, via 
his MaxPacketSize() method. 
Here, as we're using directly the /dev/net/* drivers, we don't have this 
information (at least, not yet, with current BeOS networks drivers...) at all...

- Not all /dev/net/* drivers are ethernet ones. Again, under BeOS net_server, 
it's the BNetDevice::Type() method who tell stack the device type.
Without the help of add-on, we're expecting all /dev/net/* entries are 
ethernet ones, but I know at least one (my beloved & hated 
/dev/net/speed_touch/0) which is ATM. 

And I want my pet driver to be ready for OBOS new net stack from day one ;-)

-Philippe.

Other related posts: