Date: Mon, 23 Feb 2004 15:51:14 -0500 From: John Baldwin <jhb@FreeBSD.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha mem.c promcons.c src/sys/alpha/tlsb zs_tlsb.c src/sys/amd64/amd64 mem.c src/sys/cam cam_xpt.c src/sys/cam/scsi scsi_ch.c scsi_pass.c scsi_pt.c s Message-ID: <200402231551.14698.jhb@FreeBSD.org> In-Reply-To: <8758.1077551092@critter.freebsd.dk> References: <8758.1077551092@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402231551.14698.jhb>