From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Gary Thomas Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Documentation for new Ethernet driver interface? Date: Mon, 11 Dec 2000 14:05:00 -0000 Message-id: <20001211160838.A4187@visi.com> References: <20001211152555.A3841@visi.com> X-SW-Source: 2000-12/msg00238.html > > 1) The DSR that is called now seems to be a generic Ethernet > > DSR which then arranges for a future call to the "deliver" > > callback pointing to what used to be the driver DSR. > > > > The "deliver" callback is called from a thread context > > rather than a DSR context. [...] > Yes. You can pretty much take your old 'dsr' function and > rename it to be 'deliver' (possibly with different signature). That's more or less what I thought. I'll have to watch out for synchronization issues. My DSRs all used to run atomically (with respect to each other) and after moving one of them to the user thread level, that's no longer true. In my previous posting I has said my driver uses 3 interrupts -- I forgot about a couple, it actually uses 5 -- but most of them don't do much. :) If I put dsr_lock/unlock calls in my deliver routine, it should behave pretty much like it used to. > > 2) What is the "poll" callback in ETH_DRV_SC for? [...] > It's pretty much the same, but it needs to be resilient to the > fact that it's called just to see if there is work for the > driver. That is, the 'isr' has not been called. One way to > think about this is that poll() is the same as isr() and then > dsr() (or deliver()). OK, thanks. > > 3) What is done with the return value from the int_vector > > callback? [...] > It's used to help decide if a network interrupt could possibly > be associated with typing ^C while using the network for debug > I/O. If you've got multiple interrupts, use the receive > interrupt (assuming that's the way they are stratified). More or less. I've got a PHY layer interrupt, MAC layer Rx/Tx interrupts and DMA layer Rx/Tx interrupts. The DMA Rx interrupt is the one that tells us a packet is ready to be handled, so that's the one. I'm assuming that the eth_drv_dsr() only needs to be hooked to the DMA Rx "frame ready" interrupt, and not any of the others? > > 4) The poll() and int_vector() callbacks seem not to be unused > > in "net/eth_drv.c" and are used only in stand_alone/eth_drv.c. > > Can I just put in stubs that do nothing for those two? > Yes, unless you want to build RedBoot with networking support! > > That's what all these changes were for, BTW. RedBoot now > supports complete networking based debugging - including > downloading your applications over the network and sending the > "console" output over the network as well. That might be too useful to pass up. One of these days I'm going to need some sort of DHCP/BOOTP/TFTP boot loader, so I'll keep it in mind. -- Grant Edwards grante@visi.com