> Mike Smith wrote:
> > > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote:
> > >
> > > > You can do better than this. Put the lock in FILE, and define a new
> > > > structure FILE_old, which has the same size/layout as the old FILE
> > > > structure.
> > >
> > > How is this more acceptable than bumping the major number? Are they
> > > really so precious that they can only be incremented once for a release
> > > cycle? Seems to me that a new major number is far cleaner than a gross hac
> > The major number has ALREADY BEEN BUMPED.
> > The "gross hack" is a transitional step necessary for the upgrade path to
> > work, and would be removed after it was no longer required.
> The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE
> and 5.0-STABLE, because we *continue* to compile in the wrong sizes into
Er, no, we wouldn't do this.
The "gross hack" ensures binary compatibility with old applications.
It's up to you or someone else to fix the source-level implementation of
stdin/out/err such that it's not dependant on the size of the new FILE
This is the same as, for example, renaming an ioctl to keep an old
interface alive. Newly compiled code uses the new interface, not the old
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message