Since early 2.4.x all cdrom drivers implement the block_device methods
themselves, so they can handle additional ioctls directly instead of going
through the cdrom layer.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The patch
[SCSI] SCSI core kmalloc2kzalloc
Has an incorrect piece in sr_ioctl.c; it changes buffer from kmalloc
to kzalloc, but then removes the clearing of the stack variable struct
packet_command. This, in turn leaves rubbish in the sense pointer
which the sr_do_ioctl() command then happily writes to ... oops.
Thanks to Mike Christie <michaelc@cs.wisc.edu> for spotting this.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The SCSI layer uses SCSI_SENSE_BUFFERSIZE (96) for the sense buffer
size, even though some other code uses "sizeof(struct request_sense)"
(which is 64 bytes). Allocate the buffer using the bigger of the two
for safety.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Change the core SCSI code to use kzalloc rather than kmalloc+memset
where possible.
Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
split each ioctl handled in sr_audio_ioctl into a function of it's own.
This cleans the code up nicely, and allows various places in sr_ioctl
to call these helpers directly instead of going through the multiplexer.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This follows almost the identical model to sd, except that there's one
ioctl which returns raw sense data, so it had to use scsi_execute()
instead.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
I noticed a case in sr_ioctl.c's sr_get_mcn where a buffer is
allocated, but the pointer isn't checked for null.
Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Christoph Hellwig