Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)

[Jens Axboe <axboe@suse.de>]

On Wed, Jan 25 2006, Joerg Schilling wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> > >1. compile a list of their requirements,
> >
> > Have as few code duplicated (e.g. ATAPI and SCSI may share some - after 
> > all, ATAPI is (to me) some sort of SCSI tunneled in ATA.)
> 
> Thank you! This is a vote _pro_ a unified SCSI generic implementation for all
> types of devices. The current implementation unneccssarily duplicates a lot 
> of code.

The block layer SG_IO is just that, it's completely transport agnostic.
There's not a lot of duplicated code. In the future, perhaps sg will
disappear and be replaced by bsg which is just the full block layer
implementation of that (SG_IO can currently be considered a subset of
that support).

> > Make it, in accordance with the above, possible to have as few kernel 
> > modules loaded as possible and therefore reducing footprint - if I had not 
> > to load sd_mod for usb_storage fun, I would get an itch to load a 78564 
> > byte scsi_mod module just to be able to use ATAPI. (MINOR one, though.)
> 
> On Solaris, the SCSI glue code (between hostadaptor drivers and target drivers) is 
> really small:
> 
> /usr/ccs/bin/size /kernel/misc/scsi 
> 28482 + 27042 + 2036 = 57560
> 
> 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.

Deja vu, anyone?

-- 
Jens Axboe