Messages in this thread | | | Date | Sat, 3 Jul 1999 20:15:12 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Kernel OOPS on 2.2.10 SCSI related |
| |
On Sat, 3 Jul 1999, Douglas Gilbert wrote:
> 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/
| |