From owner-cvs-src@FreeBSD.ORG Mon Feb 23 14:07:35 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD6A16A52B for ; Mon, 23 Feb 2004 14:07:34 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id A9DF543D2F for ; Mon, 23 Feb 2004 14:07:34 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 11074 invoked by uid 1002); 23 Feb 2004 22:07:34 -0000 Received: from unknown (HELO ?10.4.1.17?) (64.58.1.252) by smtp.mho.net with SMTP; 23 Feb 2004 22:07:34 -0000 Date: Mon, 23 Feb 2004 15:09:05 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: John Baldwin In-Reply-To: <200402231551.14698.jhb@FreeBSD.org> Message-ID: <20040223150304.F66630@pooker.samsco.home> References: <8758.1077551092@critter.freebsd.dk> <200402231551.14698.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: Poul-Henning Kamp cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/alpha/alpha mem.c promcons.csrc/sys/alpha/tlsbsrc/sys/cam/scsi scsi_ch.c scsi_pass.c scsi_pt.c s X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 22:07:35 -0000 On Mon, 23 Feb 2004, John Baldwin wrote: > On Monday 23 February 2004 10:44 am, Poul-Henning Kamp wrote: > > In message <200402230945.42440.jhb@FreeBSD.org>, John Baldwin writes: > > >On Saturday 21 February 2004 06:13 pm, Poul-Henning Kamp wrote: > > >> In message <20040221161339.X52892@pooker.samsco.home>, Scott Long writes: > > >> >> A grace period is not possible, that is why I have been so vocal > > >> >> with my heads-up messages to current for the last two weeks. > > >> > > > >> >What are the technical reasons for a grace period not being possible? > > >> > > >> The signflip on the GIANT flag. > > > > > >Which was arguably premature given the vast number of NEEDGIANT vs. > > > NOGIANT case. The MPSAFE flag for interrupts hasn't been flipped yet > > > either for that reason. > > > > I thought the idea was to try to get the API's set up correctly before > > the RELENG_5 branch so that we do not make MFC'ing impossible a few > > months after the branchpoing like it happened for 3.x ? > > I guess I'm less optimistic. I don't expect most of the drivers to be locked > in the 5.x timeframe, but I also don't expect the 6.0-CURRENT timeframe to be > very long either. However, I don't think NEEDGIANT vs. MPSAFE is all that > big of an MFC'ing issue. We have similar ones already for 4.x vs. 5.x and > they haven't really caused that much driver divergence in those branches. Good planning now is worth a ton of #ifdefs later. I support what PHK is aiming for here. I don't think that you really are away of the significant differences between 4.x and 5.x and how messy it has become to support both with the same source. > > > Another part is psychological: I think we need to mark the spots > > that need work done rather than put congratulatory notices in dmesg > > for the little headway we've done. > > Yes, but that is not but so practical when 90% still needs to be done. I also > want to get rid of the syscall MP safe flag and just assume all are MP safe > by making the ones that aren't explicitly grab Giant, but if all that does is > add code churn that has to get backed out when the subsystem in question is > eventually locked, then that code churn is far less useful than just doing > the locking to begin with. FWIW, I didn't add the "congratulatory" notices > and I'm not a fan of the extra clutter myself. > The 'MPSAFE' and 'FAST' lines will probably be either reversed or put under bootverbose before 5.3. It would be nice if there was a way to express these flags from within the probe line, but our driver model doesn't suppor that at all. Tearing up the API for such a cosmetic change probably isn't worthwhile right now, but might be considered if we ever get a multi-pass newbus framwork. Scott