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     ! 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.