> Gerard Roudier wrote:
> > > You will be pleased to hear that your system ran out
> > > of memory under the 16MB level even though your
> > > sym53c8xx could have used any available RAM for
> > > DMA purposes.
> >
> > Hmmm... If you are severe each time you discover that something that
> > worked fine years ago does not work at the moment, you may end-up thinking
> > that all ancient programs had been write by stupid guys and obviously this
> > is absolutely _untrue_. The problem of the current SCSI code is that it
> > hasn't been maintained as it should have been, and it is a good thing that
> > people like you decided to maintain this code.
>
> I am one of those ancient programmers :-) who
> still hasn't heard a good excuse for not checking
> malloc() returns (kmalloc in this case) for NULL.
I donnot think so. My opinion is that human are lazy in essence, but some
are not smart enough to deserve their lazyness. :-)
The 'not check for malloc case' is a good example of that. You are
allowed not to check malloc returns if you donnot want to handle this
situation, but you are stupid if you donnot wrap malloc to some function
that will panic/exit on failure (or trigger some exception). Adding some
parameter/tag to the wrapper that help locate the caller and some output
is still better.
A well design and well written program should not test explicitely for
errors it is unable or does not want to handle. For that to be achieved,
it must rely on appropriate interfaces and if such are not available, you
just have to implement them prior to writing the main part of the program.
Programs that are bloated by "if malloc() == NULL, printf(...)
exit/panic(..) are the ugliest possible programs.
> The difference in 2.2 seems to be an increased
> probability of kmalloc(..., GFP_DMA) returning
> NULL.
>
> As for the design of the SCSI sub-system, I quite
> like it and give credit to Drew and Eric for that.
> Given the relatively short time scales they are
> talking about for the 2.3 series of kernels it seems
> as though we will be living with this design into
> 2.4 . Doug Ledford seemed to suggested that the whole
> sub-system was going to be re-designed in 2.3 but
> my guess is that it is already too late for that.
> The CAM design from a Linux point of view looks
> like "throw the whole thing out and start again".
> This seems to be what they did in FreeBSD.
And they just killed all SCSI device drivers except the aic7xxx one at
CAM introduction. ;-)
And their CAM is not fully compatible CAM. This hasn't been smart not to
follow exactly CAM, in my opinion.
On the other hand, it would have been possible to add CAM to the kernel
without throwing away the previous method in order to allow driver
conversion without dropping support of most of them at the same time.
In my opinion, the right approach is 'make a new thing' better enough to
encourage people to go with it ASAP.
> So how about a spot of strengthening of the design
> we have in Linux? I have 2 suggestions:
> - increase the sense buffer from 16 to 32 bytes
> (that way we at least comply with SCSI 2)
> - add an "actual bytes tranfered" count into
> the same structure
OK for the sense buffer. But the "actual bytes transferred" does not make
sense in SCSI due to the MODIFY DATA POINTER message. So does not make
sense the calculation of any residual based on some DMA counter for the
same reason. Even if the MODIFY DATA POINTER is rarely supported and/or
used, we must consider it.
You only need to be aware of the amount of data that has been transferred
for some situations involving tape devices (stream devices). For these
situations there are flags and REQUEST SENSE data that allow to deal with
them gracefully.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/