> OK, there is a reason to do it. But is the benefit really worth the
> breakage?
> Yes because your drivers will silently break anyways, god knows what
> lies at the next word at the end of the old file_operations structure
> in your non-source driver (maybe the first word of some other
> structure, maybe the first instruction of some function, who knows).
> Perhaps you consider silent total failures acceptable.
Kernel Zen: Would they be failures if they were truely "silent"?
(A JOKE! Don't flame me on this...
Maybe something below, but not for this...)
Let's look at this a little more carefully...
Case 1) Drivers with sources
Case 2) Binary only drivers
In case one with the current situation, if the driver does not get
updated PROPERLY its going to cause random acts of terrorism and cause
the kernel to blow chunks in unpredicable ways. Best we can hope for is
that someone NOTICES the insignificant warning you get when you compile the
driver. I got real DAMN lucky noticing the warning with the joystick
driver - THAT WAS IN THE MAIN KERNEL SOURCES. Considering that the kernel
is no where near a zero warning compile, this could easily be lost in
the noise.
If the driver does get updated properly, with version conditional
compiles, all is right with the world and you can compile it with which
ever kernel you wish. Ok... I would at least hope for that...
In case one with the addition at the end of the structure, if the
driver does not get updated, the structure gets backfilled with NULL's,
when compiled with the newer structure, on initialization and does the
right thing. Not pretty and it lacks encouragement for the developer
to update his driver (how long has several PCI drivers been emitting
warnings about an obsolete PCI interface) but at least it doesn't cause
the kernel to blow chunks. As someone pointed out to me in an earlier
message, there is lots of precedence for that in the kernel, right now.
If the driver DOES get updated properly, it still needs the
conditional compile to avoid generating more severe compiler warnings
when compiling on older revisions (I like that additional severity [too
many initializers for structure] AND the fact that it hits the OLDER revs).
In case two, if the developer compiles a driver with the older
structure, then your arguement applies with full force. But, you get
random acts of terrorism IN BOTH CASES, whether you put the additional
element at the end or in the middle. In the case of the inserted structure
element, you get it when the moved functions are improperly referenced.
In the case of the appended structure element, you get it from the random
garbage that is referenced beyond the structure when the NEW element is
referenced. Looks to me like the two cases of random terror balance
here... Since the driver is not compiled in either case, you don't get
compiler warnings in either case. Ok, ok, I will concede that there is
and enhanced element of randomness in the terrorism which occurs in
the case of the appended element because it is a) less likely to get
referenced and b) not guarenteed to cough up a bad value... Still...
BOTH are BAD.
In case two, if the developer compiles a driver with the newer
structure and the inserted element, then he ends up with a driver that
is incompatible with the older kernels (yes, yes, I know, you shouldn't
be using older DEVELOPMENT kernels anyways...) and causes the older kernels
to blow chunks. If he compiles with the newer structure and an appended
element, his driver works perfectly fine with the older kernels (presuming
nothing ELSE commits mayhem - not a good assumption, I will agree) and
fits right in with the new kernels.
So... With an inserted structure element, you are forced to
update all driver sources AND maintain two separate versions of any
binary drivers. In the case of an appended element, you may or may not
be forced to update the driver sources and you CAN create a driver binary
which is compatible with both the old and the new kernels.
Drivers SHOULD be in step with the kernel revs and we shouldn't
be crossing revs with single driver binaries, but... We do see it happen.
We are more likely to see it happen in the released kernel line than in
the development line, but...
Looks to me like we ended up with the worst of both possible
worlds in this case... :-(
This IS the development series and, as such, these aren't dire
deadly issues to be addressed at all cost, but we should at least be in
the habit of paying attention to them so we don't develop (yuck - pun
alarm - sorry) bad habits that spill over into the "stable" line. A lot
of people are already using the development line because it's just as stable
(in most cases) as the release series and it's got LOTS of features that
some of us need (now if I could JUST get both IPSEC AND IPv6 in the same
kernels...). Let's not aquire a "bull in a china shop" reputation by
throwing in unecessary incompatibilities and destablizing the kernel.
Especially just before a major release....
Please??? :-) ;-) :->
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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