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: NChristoph Hellwig <hch@lst.de>
Acked-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NJames 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: NLinus Torvalds <torvalds@osdl.org>

Change the core SCSI code to use kzalloc rather than kmalloc+memset
where possible.
Signed-off-by: NJes Sorensen <jes@sgi.com>
Signed-off-by: NJames 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: NChristoph Hellwig <hch@lst.de>
Acked-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NJames 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: NJames 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: NNate Dailey <nate.dailey@stratus.com>
Signed-off-by: NJames 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!