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

[Scott Long]

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 at FreeBSD.org>, John Baldwin writes:
> > >On Saturday 21 February 2004 06:13 pm, Poul-Henning Kamp wrote:
> > >> In message <20040221161339.X52892 at 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