linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2006-03-23	[PATCH] kill cdrom ->dev_ioctl method	Christoph Hellwig	1	-19/+0
	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>
2006-03-06	Allocate 96 bytes for SCSI sense data reply	Linus Torvalds	1	-1/+1
	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>
2006-01-14	[SCSI] sr: split sr_audio_ioctl into specific helpers	Christoph Hellwig	1	-91/+111
	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>
2005-08-28	[SCSI] convert sr to scsi_execute_req	James Bottomley	1	-35/+27
	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>
2005-04-21	[SCSI] drivers/scsi/sr_ioctl.c: check for failed allocation	Nate Dailey	1	-0/+3
	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>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+568
	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!