Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosnetteam] || [Date Prev] [07-2003 Date Index] [Date Next] || [Thread Prev] [07-2003 Thread Index] [Thread Next]

[openbeosnetteam] Re: New stack

  • From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
  • To: <openbeosnetteam@xxxxxxxxxxxxx>
  • Date: Mon, 21 Jul 2003 12:38:29 +0200
Hi Philippe,
does your new stack allow these global dynamic/static attributes that I
suggested some time ago?
I could really need some way to set up nameservers from the kernel.
Or do you think it would be better to have a ppp_server application and an
interface that just routes all packets?
Bandwidth is increasing and in some years we will have very fast dial-up
connections for everyone. A kernel implementation is much faster.

Waldemar

> > Hi all (especially Philippe),
>
> Hi all, especially Niels :-)
>
> > I was sort of wondering what the status of the new stack is,
>
> It's a early, pre-alpha state, new stack design and stack modules API.
> It's why I put it under current/src/tests/kits/net currently.
> It's also include the userland stack hosting app.
> Only ethernet interfaces works currently, as the core features of the
> stack is not all there it make no sense to
> waste time on upper protocols until the API available for them is fully
> there.
>
> To test it:
> - build all projects
> - the net_server binary should be symlinked as _APP_ in each sub-
> drectories/projects, so
>   each module can be linked against it to find the kernel module API
> exported in this app.
> - the net_server will try to load the modules from a local add-ons
> folder (or ~/config/add-ons/network/*, which should
>   be setup by hands today: please symlink each module like this:
>
> new_stack/
>   net_server
>   add-ons/
>     generic/
>       memory_pool -> ../../memory_pool/memory_pool
>     network/
>       stack -> ../../stack/stack
>       layers/
>         protocols/
>           arp -> ../../../../arp/arp
>         interfaces/
>           ethernet -> ../../../../ethernet/ethernet
>           loopback -> ../../../../loopback/loopback
>
> - Then, run net_server from a Terminal :
>
> $ cd /data/projects/openbeos/current/src/tests/kits/net/new_stack
> $ net_server
> stack: B_MODULE_INIT
> memory_pool: B_MODULE_INIT
> stack: starting...
> net buffers service started.
> net timers service started.
> ethernet: B_MODULE_INIT
> layers_manager: initing network/layers/interfaces/ethernet layer(s)
> module...
> ethernet: Found device '/dev/net/rtl8139/0': MAC address:
> 00:10:a7:1b:36:6d, MTU: 1514 bytes
> layers_manager: 'ethernet/rtl8139/0' layer registered
> ethernet: Unable to open /dev/net/vt86c100/0 device -> -1 [General OS
> error]. Skipping...
> loopback: B_MODULE_INIT
> layers_manager: initing network/layers/interfaces/loopback layer(s)
> module...
> layers_manager: '*/loopback' layer registered
> arp: B_MODULE_INIT
> layers_manager: initing network/layers/protocols/arp/v0 layer(s)
> module...
> layers_manager: 'ethernet/arp' layer registered
> layers_manager: 'arp/ethernet' layer registered
> net layers manager started.
> ethernet/rtl8139/0: device reader started.
> stack: started.
> Userland net stack (net_server) is running.
> Press any key to quit.
>
> Until you press a key to end the stack, you may see some input packets,
> wrapping by a net_buffer, coming thru your ethernet interface(s).
> Here, an ARP request packet, dumped by new_stack/stack/
> buffer.c:dump_buffer():
>
> ethernet/rtl8139/0: input buffer:
> ---- net_buffer 0x800093a8: total len 64
> data_chunks:
>   * chunk 0x800091d0: data 0x80029848, len 64
>       ff ff ff ff ff ff 00 50 ba c7 d4 33 08 06 00 01 .......P...3....
>       08 00 06 04 00 01 00 50 ba c7 d4 33 c0 a8 00 01 .......P...3....
>       00 00 00 00 00 00 c0 a8 00 db 37 a2 1e b3 50 10 ..........7...P.
>       19 20 5d a9 00 00 02 04 05 64 01 03 8f ac 21 2b . ]......d....!+
>     next: (nil)
> all_chunks:
>   * chunk 0x800091d0: data 0x80029848, len 64, ref_count 1
>     free_func: 0xec06a554, free_cookie (nil)
>     next: (nil)
> delete_buffer(0x800093a8)
>
> The ethernet module pass them directly to layers above him, but as
> layers are not yet chained by layers_manager.c, none of them get
> handled by
> other layers/protocols today.
>
> [..../....]
>
> At net_server end, a test of buffers is run, stressing multiple chunks
> support this time, and then the stack si shutdown:
>
> test_buffer():
> ---- net_buffer 0x80008048: total len 69
> data_chunks:
>   * chunk 0x80019410: data 0x80004ad4, len 27
>       74 68 69 73 20 69 73 20 61 20 6e 65 74 5f 62 75 this is a net_bu
>       66 66 65 72 20 74 65 73 74 3a 20                ffer test:
>     next: 0x80019798
>   * chunk 0x80019798: data 0x800093a8, len 5
>       30 31 32 33 34                                  01234
>     next: 0x800197f8
>   * chunk 0x800197f8: data 0x800091e8, len 26
>       61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
>       71 72 73 74 75 76 77 78 79 7a                   qrstuvwxyz
>     next: 0x800197d8
>   * chunk 0x800197d8: data 0x800093ad, len 5
>       35 36 37 38 39                                  56789
>     next: 0x80008060
>   * chunk 0x80008060: data 0x800091d0, len 6
>       41 42 43 44 45 46                               ABCDEF
>     next: (nil)
> all_chunks:
>   * chunk 0x80019410: data 0x80004ad4, len 27, ref_count 1
>     next: 0x800197f8
>   * chunk 0x800197f8: data 0x800091e8, len 26, ref_count 1
>     free_func: 0x800023d0, free_cookie (nil)
>     next: 0x800197d8
>   * chunk 0x800197d8: data 0x800093ad, len 5, ref_count 1
>     next: 0x800197b8
>   * chunk 0x800197b8: data 0x80008030, len 0, ref_count 1
>     free_func: 0x8000240c, free_cookie 0x80004ac8
>     next: 0x80019798
>   * chunk 0x80019798: data 0x800093a8, len 5, ref_count 1
>     free_func: 0x800023d0, free_cookie (nil)
>     next: 0x80008060
>   * chunk 0x80008060: data 0x800091d0, len 6, ref_count 1
>     free_func: 0x800023d0, free_cookie (nil)
>     next: (nil)
> data = [is is a net_buffer test:
> 01234abcdefghijklmnopqrstuvwxyz56789ABCDEF]
> delete_buffer(0x80008048)
> my_free(0x800091e8)
> hello there: my_free2(0x80008030)
> my_free(0x800093a8)
> my_free(0x800091d0)
> stack: stopping...
> layers_manager: uniniting 'arp/ethernet' layer
> arp/ethernet: uniniting layer
> layers_manager: unloading network/layers/protocols/arp/v0 layer(s)
> module
> layers_manager: uniniting 'ethernet/arp' layer
> ethernet/arp: uniniting layer
> layers_manager: unloading network/layers/protocols/arp/v0 layer(s)
> module
> arp: B_MODULE_UNINIT
> layers_manager: uniniting '*/loopback' layer
> */loopback: uniniting layer
> layers_manager: unloading network/layers/interfaces/loopback layer(s)
> module
> loopback: B_MODULE_UNINIT
> layers_manager: uniniting 'ethernet/rtl8139/0' layer
> ethernet/rtl8139/0: device reader stopped.
> ethernet/rtl8139/0: uniniting layer
> layers_manager: unloading network/layers/interfaces/ethernet layer(s)
> module
> ethernet: B_MODULE_UNINIT
> net layers manager stopped.
> net timers service stopped.
> net buffers service stopped.
> stack: stopped.
> stack: B_MODULE_UNINIT
> memory_pool: B_MODULE_UNINIT
> $
>
> As you can see yourself, it's in no way ready for replacing anything
> yet.
> I'll be glad to discuss (IRC) with any of yours how it can evolved, if
> you find it interesting enough.
>
> On my TODO-list for this new_stack:
> - jamify the build (currently it's BeIDE projects, sorry guys). Ingo
> recently fix the -soname linker option in Jamrules, I should see if it
> help...
> - forward/fork/adapt the userland stack app code to host current stack
> modules + fixing the select support un userland_ipc.c/.h
> - finish new_stack/stack/net_buffer.c implementation:
> remove_from_buffer(), adds attributs support (add/find/
> delete_buffer_attributs)
> - implement in new_stack/stack/layers_manager.c an automatic net_layers
> chaining
> - write some layers to test/stress the design (arp, icmp, ip)
>
> > and which
> > stack will be eventually used by the project.
>
> Good question.
>
> I put the new_stack into CVS both for backup and ideas sharing
> purposes. I fall far on the second point, as I can't find enough time
> to discuss them.
> But it's only a "in progress" prototype of a new stack design and API
> I've in mind.
> Mostly inspired from both BONE (my net_buffer aim to be like BONE's
> bone_data) and Nathan Whitehorn's NetLayer'ed designs (attributs, auto-
> chaining).
>
> But... until this new design reach a working state, if any, the only
> working (even if it's broken here and there) code we have is the
> current one under
> current/src/add-ons/kernel/network/*.
> This code cry to be cleaned/fixed:
> - make functions names more friendly.
>   Marcus did some in current/src/add-ons/kernel/network/core/socket.c,
> renaming so*() into socket_*(). Other core code needs this too.
> - find where locking lack in the stack. There is many global variables/
> linked lists, not all are multithread protected.
>
> > Also, can you give me some
> > pointers in understanding the stack (I have little knowledge of
> > network
> > stack, though I do understand networks).
>
> Current stack design?
> Well, it's basicly a BSD's stack implementation.
> Data are passed thru "mbuf" buffers, and the layers are chained by the
> way of a global protosw array (well, it's a linked list in fact),
> telling for each layer code (protocol ID) and layer level pair which
> protocol module to call for input and ouput.
> Interfaces are handling by different module APIs, handled in a linked
> list of ifnet_t structures.
>
> new_stack design?
> Well, if you ask, I can explain my ideas about it in another post, just
> tell me...
>
> > And last but not least: are
> > there some small things that can be done by a person like me?
>
> Yep. The graphical network preflet is still needed.
> BNetEndpoint implementation is still missing, too (Scott???)
> And any other unassigned tasks displayed at team web page...
>
> -Philippe
>
> --
> Fortune Cookie Says:
>
> We have only two things to worry about:  That things will never get
> back to normal, and that they already have.
>
>






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.