Linus has commented a little bit further. He said that if the
switchover is reasonably straightforward, he would not be opposed to ripping
out the old error handling now. The new error handling code has been
demonstrated to be fairly stable. His other point is that making such a
change in the 2.5 series would lead to nasty back/forwards compatibility
issues with people trying to maintain drivers for both 2.4 and 2.5. While
in general this may be true, in this instance it might not be the case that
there would be nasty compatibility issues. I would need to think about it
some.
I am not yet convinced that now is the appropriate time to do it, but no
matter when it gets done, the general approach would be as follows:
First of all, I wouldn't make any attempt to adapt the old error
handling driver entrypoints to do the new work. Instead what I would do is
simply remove the function pointers for the old error handling entrypoints
from the host template, and always force the value of use_new_eh to 1. The
second thing that would need to be done is to ensure that the queuecommand
entrypoint always returns 0. With the old error handling code the return
value was ignored.
These steps alone should be sufficient to get the drivers to compile and
mostly work. The net effect of this is that unless an error took place
there should be no observable difference in behavior. In the event of an
error, the net effect would be that the device would be taken offline, as
there would be no error handling strategy. This is probably not the
optimal behavior, but it seems like the appropriate step to take to force
driver authors to update their drivers.
Again, my original idea was to do this in the 2.5 series, but this is
based upon an assumption that 2.4 is only a month or so away. If that
assumption is incorrect, then I would want to re-evaluate. No matter when
it happens, I would probably do it as I described above (unless anyone has
any better ideas).
One other point - there is no reason why they would all need to be done
in one patchset, but it would probably be better if it were. Technically
the "use_new_eh" flag itself also becomes redundant when this task is
completed, and that could also be removed, but that would make it a little
more difficult for driver maintainers to keep a single version that works
with older kernels. If we did it all at once, the drivers that got
converted would never have the need to set the flag in the first place, and
thus it would be easier to remove
the flag at a later date.
If anyone wants more information on how to convert an older driver to
the new error handling code, please see http://www.andante.org/scsi_eh.html.
The new error handling first went in back in the 2.1 series kernels, I
believe, so in theory there should be no backwards compatibility issues with
older kernels unless you want to go back as far as the 2.0 series.
Anyways, that's the news.
-Eric
----- Original Message -----
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, February 09, 2000 10:06 PM
Subject: Re: SCSI SMP safety.
> > Linus doesn't like the smp_safe flag at all. He wants us to
> > switch all of the drivers in one fell swoop if we are going to do it.
> > Ugh is all I can say.
>
> Given past experience I think its not a bad idea to do it once and for
> all. Im still fighting 2.2.x partial smp fixup bugs now.
>
> > I don't even want to think about a massive change like this until
> > all of the drivers are no longer using the old error handling code.
There
> > wasn't any particular reason I was thinking of doing it now except that
it
> > is a cleanup that eventually needs to happen.
>
> Agreed. 2.5.x is the place to do the big switch
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
