Re: MII-less network card support

[Dan Williams <dcbw redhat com>]

On Wed, 2005-01-26 at 19:31 +0100, Tom Parker wrote:
> This seemed like an interesting little project (especially after a few 
> frustrations with my day work), and so I've actually just implemented it 
> :-) Easier than I thought, patch against current CVS attached. What it's 
> doing at the moment is if we fail all of the standard MII checks, then 
> it waits 3 seconds for an ethernet frame, and reports 'link ok' if we 
> get one. There's some setsockopt() work with SO_BINDTODEVICE that 
> *should* only get frames sent to the relevant interface, but can someone 
> double-check please.

Tom,

I haven't forgotten this patch :)  I spent some time this weekend
thinking about it, and how to generalize the patch for continuous
operation.  The patch you've got only checks for link on startup
(because that's the only time that the mii code is used in NM).  So how
can we use this code to work around drivers that don't know link-
detection on their own hardware?

I had the though of using a GIOChannel linked to the fd of the data-read
socket on the device.  We'd integrate this GIOChannel into the device
thread's main loop, and it would get triggered whenever there was data
on the socket to be read.  This way, we'd set the LINK = TRUE whenever
incoming data was detected.  Furthermore, we'd have to have a timeout of
some sort that would set LINK = FALSE when data hadn't appeared for a
while (not sure how long), possibly waking up every so often and
checking the last time that data was received , which would be updated
by the GIOChannel's callback.

The only problem I could think of here was data throughput.  If our
GIOChannel callback is being triggered every time that incoming data was
present, that would be fairly often if you're transferring a file or
downloading something.  I haven't tested that out, but I would assume
that we would start using much more CPU than we do now.  One way to deal
with that would be to have the GIOChannel remove & re-add itself if its
been called more than a certain number of times in 10s (ie, making it
take a breather for a while).  This gets rather complicated though as
you have a number of idle/timeout functions and the GIOChannel callback
all interacting with each other.

Anyone got any better ideas?  We can't just have a timeout (because it
might miss data on the socket that came before it was called) and we
can't just have the GIOChannel callback (because then we'd never get
called to set LINK = FALSE when no data arrived after a certain time,
and because it might get called TOO often), but having both seems a bit
complicated.

However, given the number of stupid drivers out there, we might have to
eat the complexity and deal with it.

Tom?

Dan