On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> about your driver list;
> do you have an idea of what the top 5 relevant ones would be?
> I'd be surprised if the top 5 together had less than 95% market share,
> so if we fix those we'd be mostly done already.
In terms of what I've seen on vaguely modern hardware, I'd guess at
e1000 and sky2 as the top ones. b44 is still common in cheaper hardware,
with via-rhine appearing at the very low end. I'll try to grep through
our hardware database results to get a stronger idea about percentages.
> > The situation is more complicated for wireless. Userspace expects to be
> > able to get scan results from the card even if the interface is down.
>
> if it's down userspace cannot currently expect this (if it does it's
> broken), just as it currently can't expect link notifications when the
> interface is down. It needs to have the interface up for this.
> (but point taken for a 3rd state)
The documentation for what userspace can legitimately expect of the
kernel is distinctly lacking, and as far as I can tell most of the
common drivers support scanning while the interface is down. It would be
immensely helpful if we could have a better idea of which kernel
behaviour is deliberate, and which bits of kernel functionality are
accidental and might go away at any time. Right now, I have various
scripts depending on this behaviour because there's absolutely no
indication that I'm not supposed to be.
(Of course, I may have missed it somewhere - I've never been able to
find terribly comprehensive documentation on WE)
> so what do you want from this 3rd state? rough guess based on what I
> think the desktop wants (so please correct/append)
Just to be clear: in this world view, "down" maps to "fully powered
down", so this third state is a "low power consumption mode"? If so:
> In the third state you
> * don't expect to get or send "regular" packets
> * don't have a dhcp lease or anything like that
> * you do expect to get link change notification [1]
> * you do expect to be able to scan for access points [2]
Yes, I think that's a fair summary.
> open questions
> * what if you get a WOL event?
In an ideal world, I think the information would be passed to userspace
and it would get to make the distinction. I appreciate that the hardware
may have different ideas about what's appropriate...
> [1] What kind of latency would be allowed? Would an implementation be
> allowed to power up the phy say once per minute or once per 5 minutes to
> see if there is link? The implementation could do this progressively;
> first poll every X seconds, then after an hour, every minute etc.
Yeah, I guess that's a problem. From a user perspective, the
functionality is only really useful if the latency is very small. I
think where possible we'd want to power down the chip while keeping the
phy up, but it would be nice to know how much power that would actually
cost us.
(We have a similar issue when it comes to stuff like monitor hotplug -
it's the sort of thing that many users are willing to accept losing some
battery for, and there probably isn't a single right answer)
> [2] would it be permissible to temporarily power up the device on scan?
> Eg how frequently does the desktop expect to poll for scanning, and what
> kind of latency would be tolerable?
network-manager's behaviour when the interface is inactive is to scan
every 2 minutes. I don't think latency is too much of an issue.
--
Matthew Garrett | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
