On Tuesday 10 January 2006 00:39, Denis Vlasenko wrote:
> How are we going to find out which stack is best and which stack
> we should concentrate our efforts on? In an absense of wifi maintainer,
> maybe we should throw _all stacks_ (currently two) into the mainline,
> and evolution will find the best one. Yes, it would be a bit ugly
> at first, but I hope it will speed up evolution a lot.
>
> Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*,
> add dcape one into include/net/wlan*.h and net/wlan/*
> (s/wlan/dscape/ or whatever)
>
> We can even give Devicescape folks blanket permissions to
> maintain their stack in include/net/wlan*.h and net/wlan/*.
> Maybe they can act as a wifi maintainer long term.
>
> Existing drivers won't need to closely track every change
> in dscape stack. If dscape will survive, old drivers can be
> converted to it gradually. If not, just dike it out.
I don't like the idea of maintaining two of anything. What if I have two
wireless interfaces, each using a different stack?
Performance--,
Kernel size++
I get that it's hard to get everyone to agree on one stack or another, but we
need to make the decision now because the longer we don't have a decision
made (this includes maintaining two in-tree stacks) the longer it's going to
take us to have serious / robust / reliable / consistent wireless support.
I know basically nothing about 802.11, but it seems to me that what should
happen is that if there is sufficient motivation to boot ieee80211 in favor
of DeviceScape, someone should cook up the patches.
Besides, assume we did bless two stacks. Every new driver / driver that wanted
to go mainline would choose one or another (it's already clear that people
disagree). Thus we end up with *more* work to do in order to decide one way
or another (since we have to partially break & fully port all the drivers
from one stack to another).
There's incompatibility all over this wireless landscape. The best way to deal
with it is to make all the big hard decisions now - say "this is the way it's
going to be" and work from there. We can always undo mistakes later, but
we'll never get to that point if we don't start moving in one direction
instead of ten.
> --
> vda
> -
Cheers,
Chase
-
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]
