Re: MII-less network card support

[Tom Parker <palfrey tevp net>]

Dan Williams wrote:
> 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.

I've got a few thoughts, but they all depend on just how much traffic 
you see on a 'idle' network. Anyone with more knowledge of ethernet 
traffic patterns than me?

However, I've still got a few thoughts. Best idea I've had so far 
consists of

1) The GIOChannel waits for data for 3 seconds (or another small time - 
must be small enough to not induce significant delay in the link removed 
detection, but not so small that we get false positives). Actually, 
looking over the docs, GIOChannel looks like a bad option. A separate 
thread with plain simple fd's looks like a better option, because then 
we can do blocking 'peek' operations on the channel, which GIOChannel's 
don't appear to be able to do AFAIK.

2) If we see data, announce 'link created' if that's a change in state 
(this will only be in the init phase), wait for a second or so, then go 
to step 1.
3) If we don't see data after 3 seconds, announce 'link removed'.
4) Wait eternally for frames. If we see one, announce 'link created' and 
go to step 1.

There is the timeout problem and that we may see data followed by 
several seconds of quiet, but I don't know *how* quiet for ethernet. If 
it's "almost quiet, but some frames" then we're ok, otherwise we may see 
some false positives. People connecting to hubs and/or busy networks are 
on good ground here...

I'd rather see how this approach works first, and if it doesn't work 
well enough with quiet networks, then go with the data intensive one.

Just my 2 eurocents,

Tom
--
palfrey tevp net - http://tevp.net
Illegitimus non carborundum