ieee80211 updates

DISCUSSION Jeff Garzik 2 participants 2 messages Sep 19, 2005 6 messages not in the archive

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jeff Garzik

author

2005-09-19 05:41 UTC #6 lore raw

Quoted 1 line · Michael Wu

If it has a version, then only the maintainer can submit patches -

False. Presence of an optional label in source code files does not change the fundamental rules of open source, or the processes surrounding patch merging in the Linux kernel. Anybody who feels the version number should be changed is welcome to submit a patch. And a reviewer along the line is welcome to reject such a patch, if they think it is unwarranted.

Quoted 2 lines

otherwise the
version is useless for identifying what code you're running. (unless other

False. We have plenty of examples of slower-moving drivers where community consensus often dictates a version number change.

Quoted 1 line

submitters decide to alter the version too, which is probably not a good idea)

For any given driver/subsystem/whatever version number in the kernel, ultimately a submittor changes the version and one or more reviewers approve this, by pulling the change into their tree. Your "probably not a good idea" is the 100% case here, including the master version number in ./Makefile.

Quoted 11 lines

Quoted 9 lines
Quoted 4 lines
That early and often thing is true for drivers aswell, the intel wireless driver are so hopelessly out of date in mainline just after submission that it's not funny anymore. Hopefully we'll have a mainline maintainer for them soon that imports everything important from intel and other contributors.
Patience: We still have over 20 patches to merge, before even getting to the ipw updates.
I wish those patches were submitted and merged quickly when they were created instead of piling up. Other people can't get patches merged because it

Agreed.

Quoted 3 lines

Other people can't get patches merged because it
would
break the chain of patches. Patches are being sent too late and and infrequently..

Patience. We've got to balance kernel hackers' insatiable desire for cleanups, with the desire of users and driver developers to move forward with Linux wireless support.

Since Intel has useful stuff, stuff which affects a wide range of hardware owned by Linux users, it's worth waiting a bit to let them catch up. Of course, if it takes forever to merge their stuff, someone else will inevitably come along and speed up the process. Open source at work.

Currently, it has rather been like a clock algorithm: merge initial ieee80211 code from Intel. Accept months worth of cleanups from community. Accept unifying updates from Jouni. Begin merging work from Jiri and SuSE. Now the clock hand points at Intel again, and they've been waiting a while to send useful stuff.

People are slowly converging at a decent solution, while at the same moving wireless hardware support forward. The need to improve the wireless API is balanced with the need to keep wireless hardware working (and/or enable new wireless hardware).

This convergence will be attained more rapidly once the community starts WORKING TOGETHER, rather than sending me competing patches. Person A breaks Person B's work. And then back again.

Jeff

Matt Domsch

2005-09-19 22:00 UTC #7 lore raw

Quoted 10 lines · Jeff Garzik

Quoted 1 line · Michael Wu
If it has a version, then only the maintainer can submit patches -
False. Presence of an optional label in source code files does not change the fundamental rules of open source, or the processes surrounding patch merging in the Linux kernel. Anybody who feels the version number should be changed is welcome to submit a patch. And a reviewer along the line is welcome to reject such a patch, if they think it is unwarranted.

Quoted 5 lines

Quoted 2 lines
otherwise the
version is useless for identifying what code you're running. (unless other
False. We have plenty of examples of slower-moving drivers where community consensus often dictates a version number change.

This is also the reason for the 'srcversion' field available in modinfo. This is a CRC across the source code for a given module (not counting #include<*>, but counting #include "*"). The version field may not change, but if anything really cares about a particular source code copy, and that it hasn't been patched, but the version field not updated, they can see that.

Thanks to Rusty for implementing this.

Thanks,
Matt

Signature · 4 lines

Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com