No, the best way to announce a change is to tell people in words on
the kernel list.
> It is, after all, absolute and obvious. (Who can miss page after
> page of a NULL being added with the comment, /* flush */ ?)
It should not be necessary to read the patches to see what's changed.
> Besides, if you're developing a driver, you should read the patches
> to see what may have an impact on your driver. A new PCI interface,
> better IRQ code, SMP changes, maybe a file operation, or perhaps
> user space DMA method may appear.
Ignoring the fact that this is a lot of work (announcements of changes
are a better method), this also ignores a driver patch that people
apply to the latest kernel. I get plenty of people applying patches to
a later kernel version than what I made and tested the patch for.
You expect all these people to read the kernel patches to see what's
changed???
> If you're suggesting it should be possible to take a 2.0 driver and
> instantly port it to 2.1 without a single thing breaking, you have
> some extremely optimistic ideas and I'd like to sell you a bridge.
I'm talking about breakage within the 2.1 series. I never mentioned
2.0.
> I'd say fixing a serious NFS bug is worth temporarily breaking every
> driver (which they might later take advantage of it themselves if
> needed) in a _developmental_ kernel. If this was a 2.2.x or 2.0.x
> kernel I might see your point, but 2.1.x? No way.
Fixing the NFS bug was good. It could have been fixed without breaking
any source code. Linus chose to break things for maintainability
reasons, which Doug has finally explained. I've made a suggestion
which I hope will give him the maintainability goals he wishes but
also avoids breakage. If he likes this approach, I'll send a patch.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html