Date: Mon, 23 Feb 2004 15:09:05 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: John Baldwin <jhb@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 Message-ID: <20040223150304.F66630@pooker.samsco.home> In-Reply-To: <200402231551.14698.jhb@FreeBSD.org> References: <8758.1077551092@critter.freebsd.dk> <200402231551.14698.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040223150304.F66630>