> So what is the difference between breaking all source and then
> inserting NULLs, or appending the new method and taking advantage of
> automatic structure initialisation. The only difference I've seen is
> that one approach breaks things and requires lots of effort.
Automatic structure initing is damn sloppy coding in the kernel. If that's
the way you want to do things, fine, but you won't get any kudos from me for
proper coding practice. Let's give a little scenario.
Linus adds flush() to the struct. He puts it at the end, only the NFS code
uses it, every one else uses auto initing of their struct.
Later he adds another new option to the end that not all fses need.
However, you decide you need it in your code. You add the initializer to
the end of your struct, but you forget that the flush item was never added,
so all of a sudden you now have a flush entry that does something totally
different and many people totally screw their filesystems thanks to you.
Think it won't happen? It happened to me. While I was off working on
2.0.x, the new SCSI code was added to 2.1.65. When I came back, I didn't
notice the changes to the scsi_host structure until about 4 or 5 versions
into 5.0.x driver. I then modified my struct initializer so that I put the
variable name with *every* intitializer element to make sure I avoided this
problem in the future no matter what happened to the scsi_host structure.
> Maybe the inner circle *does* know some deep dark secret, but *I*
> don't know it and it hasn't been made public. In light of this, my
> questions are entirely reasonable. Instead of flaming me for pursuing
> this, why not come forth with some clearer explanations?
The clearer explanation is that Linus doesn't want to track down bugs caused
by someone else's sloppy, lazy coding. So, he forces the breakage in order
to make sure that all of the code is updated in the *right* way, not the
sloppy, break it in the future way of automatic initialization and
assumptions.
--Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.
- 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