Messages in this thread | | | Date | Sat, 29 Aug 1998 12:27:52 +1000 | From | Richard Gooch <> | Subject | Re: 2.1.118 Tons of oopes |
| |
greerga@nidhogg.ham.muohio.edu writes: > On Sat, 29 Aug 1998, Richard Gooch wrote: > > >I'll rephrase my question: why is it better to break every driver than > >to announce a new flush() method which has been appended? > > Is the patch not the best way to announce a change?
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
| |