On Sun, 9 Jan 2000, Richard B. Johnson wrote:
> 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.
Ummm Richard, as far as I know the GPL requirement only means that you are
obliged the source code to whatever version you _shipped_ , not whatever
version the customer can possibly obtain from CVS or ftp (or Linus).
So, for example, you are free to take Linux 1.2.13, write device drivers
for it and provide (to your customers) a third cdrom with source. Of
course someone might want a newer Linux release, but that is another
issue.
I think that "make it work with the very latest kernel" approach if
fundamentally wrong. What if one of the new kernels has a bug ? Are you
supposed to work around it and then write code again when it is fixed ?
I would suggest picking a reasonably stable development kernel, write
your drivers for it and then upgrade when sufficiently many chagnes are
introduced. This way when new even series appears you already have drivers
working with it. In no event you should be shipping development kernels
to your customers.
Vladimir Dergachev
>
> 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/
>
-
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