Messages in this thread | | | Date | Tue, 24 Aug 1999 21:03:36 +0200 | From | Jens Axboe <> | Subject | Re: cdrom changer support for scsi [patch] |
| |
On Mon, Aug 23 1999, Richard Sharman wrote: > Having recently bought a CD writer I started using the scsi-emulation > driver, but then lost support for my CD-changer since the scsi driver > doesn't have changer support. > > So, I decided to implement it based on the ide code. > > The patch is against 2.3.13, and has been tested both as modules > (sg.o sr_mod.o cdrom.o ide-scsi.o) and built-in to the kernel. > > It seems to work fine when used through scsi-emulation on my IDE > cdroms, but I have no SCSI equipment to test it on. > > > If anyone could test this patch with a SCSI changer that would be great. > If anyone could test it with any SCSI cdrom (to make sure it hasn't > broken anything!) I would appreciate it. If anyone is willing to test > it and wants say a 2.2 version please let me know. > > A small readme and any newer version will appear in > http://www.pobox.com/~rsharman/linux/ > > (What do I do next after any feedback is incorporated? Mail it to the > SCSI maintainer?)
The patch looks fine in itself, but it adds a lot of duplication of code which is always a bad thing. I've done some work recently to eliminate ATAPI/SCSI redundancy and put most of this in the Uniform layer. I don't see why changers couldn't be handled like that, too.
With regards to the cdrom.[ch] parts of the patch - they look fine, I've put them in my tree here.
> Finally (sorry for the long post!), I have a related question. > Is there a problem with having large local variables in a kernel > function? In a few places I have a local (stack based) buffer of 248 > bytes. I see in some places in sr.c `scsi_malloc' is used even > though the buffer is freed in the same routine. I would have thought > this adds unnecessary overhead, but am wondering if there is some > limit to the stack usage in the kernel.
There is a limit of about 8KB-some available kernel stack. I've recently taken out some of the mallocs in sr*.c which spinlocked and malloced for as little as 32 bytes which is just silly. If you came across similar places I'd like to know (it is very possible that I didn't get them all, I just fixed the ones I bumped into).
-- * Jens Axboe <axboe@image.dk> * Linux CD-ROM Maintainer * http://www.kernel.dk
- 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/
| |