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>