Return to enetOld.questions CVS log

Up to [Apple Darwin 0.x] / driverkit / notes

Annotation of driverkit/notes/enetOld.questions, revision 1.1.1.1

1.1       root        1: Ethernet questions
                      2: 
                      3: 1) current driver - how is enprobe() called? It's in bus_driver endriver, but
                      4:    I don't see where it's referred to...
                      5:    > in ioconf.c - endriver inferred (during config) from en0 in MASTER.next?
                      6:    
                      7: 2) netif stuff: In Unix server? In kernel? In separate task containing all of
                      8:    the network drivers and protocols etc.?
                      9:    
                     10:    In Unix server:
                     11:      -- easy to implement "Network Object" which provides methods analogous 
                     12:         to init_func, input_func, etc. (args to if_attach()). 
                     13:        
                     14:      -- very dirty to implement all of the functions in netif (e.g.,
                     15:         if_oerrors(), if_oerrors_set(), etc.). Need objc interface to
                     16:        all of these (in Unix server, accessible from network driver tasks)?
                     17:        Or RPCs to Unix server? Who would do all of this?
                     18:        
                     19:        -- a lot of these (like if_oerrors(), if_oerrors_set()) are pretty
                     20:           dumb and shouldn't require RPCs. Just maintain this stuff
                     21:           locally; these functions could be provided by NetworkDevice
                     22:           superclass.
                     23:           
                     24:        -- Necessary netif functions (called by driver, in netif.c):
                     25:        
                     26:                if_attach
                     27:                if_down
                     28:                if_handle_input (rld'd into driver task)?
                     29: 
                     30:      -- rld things like venip_input (the if_input function, in
                     31:         net/if_venip.c) into Enet task? What happens to the current 
                     32:        ifnet.if_input?
                     33:        
                     34:      -- What about ifnet.if_getbuf()? Seems way too expensive to do an RPC
                     35:         every time you do need to get an output buffer (one RPC to get
                     36:        the buffer, one to send to the driver). Also, mbuf chains ain't
                     37:        gonna work across RPCs. Need to unroll mbuf chains to get one
                     38:        continguous piece of vm to send to driver task...
                     39: 
                     40:      -- besides, this doesn't really seem right...IP is not Unix!
                     41:      
                     42:      -- How are we going to provide 3rd party network protocol support? 
                     43:         Rld into Unix server? Huh-uh. 
                     44:        
                     45:    In kernel: 
                     46:      -- could implement the netif functions needed by driver task as
                     47:         traps...seems kind of kludgy.
                     48:      
                     49:    One big "network" task, rld'd into at run time for 3rd party or optional
                     50:    protocols:
                     51:       -- rld inherently evil?
                     52:       -- use existing netif, or redo it in ObjC?
                     53:      
                     54:    Separate task for each driver and protocol:
                     55:       -- seems cleanest from one point of view (no rld, one module can't 
                     56:          crash another)
                     57:       -- Redo entire netif in ObjC? What's the interface to the rest of the 
                     58:          world (i.e., Unix and the kernel)? IODevice? NetworkDevice?

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.