Re: State of the Union: Wireless

[Adrian Bunk <bunk@stusta.de>]

On Tue, Jan 10, 2006 at 02:34:00PM +0100, Tim Tassonis wrote:
> Adrian Bunk wrote:
> >On Tue, Jan 10, 2006 at 01:38:58PM +0100, Tim Tassonis wrote:
> >>...
> >>>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.
> >>You were right if there were ten, but there seem to be only two at the 
> >>moment. One stack will survive and one will die. There's no point in 
> >>deciding this now.
> >
> >No, we'll end up with two stacks, some drivers using the first stack and 
> >some the second one.
> >
> >You can't simply let one stack die because this would imply either 
> >rewriting all drivers using this stack or dropping support for some 
> >hardware.
> 
> By "die", I didn't mean "delete it from kernel sources".
> 
> It is very probable that over time, the "winning" stack will contain 
> most drivers for the most common hardware, and the "losing" one just a 
> few obscure ones. The "losing" one will still be available for people 
> using hardware only supported by that stack.
> 
> Like the OSS/Alsa or XFree3.x/XFree4.x situations.

And OSS/ALSA is an example why this is not a good thing:
- OSS in the kernel is unmaintained
- people forced to use OSS drivers can't use applications only 
  supporting ALSA

In the OSS/ALSA case this was not avoidable since OSS was for a long 
time the sound system in the kernel, and ALSA came later.

But if you have the possibility to choose which stack to use at the 
beginning (as in the wireless case), the only reasonable solution is to 
choose _one_ stack.

> Tim

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/