Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jul 1995 18:51:02 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        davidg@Root.COM
Cc:        bde@zeta.org.au, CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject:   Re: cvs commit: src/sys/kern tty.c
Message-ID:  <199507310151.SAA01837@gndrsh.aac.dev.com>
In-Reply-To: <199507301844.LAA00185@corbin.Root.COM> from "David Greenman" at Jul 30, 95 11:44:55 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> >>bde         95/07/30 06:52:57
> >
> >>  Modified:    sys/kern  tty.c
> >>  Log:
> >>  Don't swap the queue headers to implement concatenation of the
> >>  queues for TIOCSETA[W].  Swapping an even number of times broke
> >>  the queue resource limits.  This would have broken CRTSCTS flow
> >>  control if the clist slush list was used up.
> >>  
> >>  Don'concatenate the queues for TIOCSETA[W] if one of the queues
> >>  has a resource limit of 0.  Concatenation would cause a panic if
> >>  one of the queues is nonempty and the other is limited to length
> >>  0.  This may have caused panics in PPPDISC.
> >>  
> >>  Wake up readers after all transitions of ICANON.  When ICANON is
> >>  turned off it is quite likely that characters will become available
> >>  to be read.
> >>  
> >>  Reduce indentation near these changes.
> >
> >This change should go in 2.1.
> 
>    There have been 14 commits to tty.c since it was branched for 2.1. I'm
> slowly beginning to think that we should consider taking the bulk of the fixes
> rather than doing this piece-meal. Many of the fixes are important and most of
> them seem to be intertwined. Some of the changes are matched with changes to 
> sio.c and other serial drivers...so these changes must be brought in, too.
>    I'd like to hear other opinions about this.

IMHO this is a mixture of bug fixes from 1.x, and new work.  Since it
is intertwined segregating what is well tested and known code from new
and unknown code is very hard.

Without 2 to 4 weeks of heavy testing it is a bad idea to bring new code
into a release branch.  Just ask anyone who has ever done a release.

Then #1 cause for release slippage is bug fixing new code brought in
after branching.

I would classify this as more than bug fixes, it is more like major reworking
to fix the design flaws.  Something that should wait for a 2.2 release.

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507310151.SAA01837>