On Wed, Jan 25 2006, Jan Engelhardt wrote: > > >> And if you check the amount of completely unneeded code Linux currently has > >> just to implement e.g. SG_IO in /dev/hd*, it could even _save_ space in the > >> kernel when converting to a clean SCSI based design. > > > >Please point me at that huge amount of code. Hint: there is none. > > I'm getting a grin: > > 15:46 takeshi:../drivers/ide > find . -type f -print0 | xargs -0 grep SG_IO > (no results) > > Looks like it's already non-redundant :) SG_IO turns requests into REQ_BLOCK_PC (or blk_pc_request()) types, so you should probably check for that as well. But it's truly a miniscule amount of code, and if I got off my ass and folded cdrom_newpc_intr() and cdrom_pc_intr() into one (that was the intention), it would be even less. It just looks like Joerg needs to do his homework, before spreading false information on lkml. Then again, all his "arguments" are the same as last time (and the time before, and before, and so on). -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Joerg Schilling <schilling@fokus.fraunhofer.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Jens Axboe <axboe@suse.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- References:
- Re: Rationale for RLIMIT_MEMLOCK?
- From: Matthias Andree <matthias.andree@gmx.de>
- Re: Rationale for RLIMIT_MEMLOCK?
- From: Arjan van de Ven <arjan@infradead.org>
- Re: Rationale for RLIMIT_MEMLOCK?
- From: Matthias Andree <matthias.andree@gmx.de>
- Re: Rationale for RLIMIT_MEMLOCK?
- From: Joerg Schilling <schilling@fokus.fraunhofer.de>
- Re: Rationale for RLIMIT_MEMLOCK?
- From: Lee Revell <rlrevell@joe-job.com>
- CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Matthias Andree <matthias.andree@gmx.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Jan Engelhardt <jengelh@linux01.gwdg.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Joerg Schilling <schilling@fokus.fraunhofer.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Jens Axboe <axboe@suse.de>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Jan Engelhardt <jengelh@linux01.gwdg.de>
- Re: Rationale for RLIMIT_MEMLOCK?
- Prev by Date: ALSA on MIPS platform
- Next by Date: Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Previous by thread: Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Next by thread: Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Index(es):
![]() |