Re: [ECOS] Documentation for new Ethernet driver interface?

[Grant Edwards <grante at visi dot com>]

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