On Sun, 9 Jan 2000, Theodore Y. Ts'o wrote:
> Richard B. Johnson wrote:
> > For instance, there was a simple new change in the type of
> > an object passed to poll and friends. This just cost me two
> > weeks of unpaid work! Unpaid because I had to hide it. If
> > anyone in Production Engineering had learned about this, the
> > stuff would have been thrown out, the MicroCreeps would have
> > settled in with "I told you so..", and at least three of us
> > would have lost our jobs.
>
> You had the choice of not upgrading to the latest kernel, didn't you?
>
> If it was you who chose to upgrade to the latest kernel, why are you
> complaining to us?
>
> If you told your management that Linux kernel interfaces never change
> across versions, then you were sadly mistaken. However, the mistake is
> on your end, I'm afraid.
>
No. According to our Legal Department, to satisfy the GPL requirement
that we provide source to the end-user, they required that we supply a
"current" distribution of Linux if the end-user requests it.
This seemed, by them, to be an easy solution to possible problems.
Unfortunately, for Engineering, this means that we have to keep everything
"current" during development so that, by the time equipment is shipped, it
will run with the "current" distribution (whatever this is).
The obvious solution, given these constraints, is that we just ignore
all changes until shipping time, then attempt to compile with the latest
distribution, fixing all the problems at once. However, we then end up
shipping untested software which ends up being another problem. Checking
to see if it "runs" isn't testing software in the cold cruel world of
industry.
So, presently, I have 13 drivers I have to keep "current". Yesterday
they all got broken again. A week before, half of them were broken
because somebody didn't like a variable name!
That said, a major problem with changes that I see, is that the changes
are made without the notion of a terminating condition. For instance,
new parameters are being passed to existing interface functions.
If you are going to break an interface, you should plan on only breaking
it once rather than opening the door for more changes and leaving it
open. For instance, once you have to pass more than (depends upon the
machine) about 3 parameters, it's best to put them all in a parameter-
list (structure) and pass only the address of the parameter list
(pointer).
>From that time on, you only have to add structure members to the parameter
list if you have to add changes. If I had seen these kinds of changes
I would not have complained. It means I have to rework stuff only once.
So `read(f,.......)` should have been changed to `read(params *)` and
you are done with it forever as long as you don't change structure member
names and functions for kicks.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:15 EST