2009-06-11 11:13:48

by Jens Axboe

[permalink] [raw]
Subject: [GIT PULL] first block round for 2.6.31

Hi Linus,

This is the bulk of the block changes for 2.6.31, please pull.

git://git.kernel.dk/linux-2.6-block.git for-2.6.31

Akinobu Mita (1):
loop: use BIO list management functions

Andrew Morton (2):
splice: fix error return code
cciss: use schedule_timeout_interruptible()

Andrew Patterson (1):
cciss: add cciss driver sysfs entries

Bartlomiej Zolnierkiewicz (4):
mg_disk: fix CONFIG_LBD=y warning
block: enable by default support for large devices and files on 32-bit archs
mg_disk: fix dependency on libata
mg_disk: use defines from <linux/ata.h>

Boaz Harrosh (5):
libosd: Use new blk_rq_map_kern
block: Add blk_make_request(), takes bio, returns a request
libosd: Use of new blk_make_request
block: Un-export blk_rq_append_bio
scsi_lib: remove unused variable

Borislav Petkov (3):
ide: add helpers for preparing sense requests
ide-cd: convert to using generic sense request
ide-atapi: convert ide-{floppy,tape} to using preallocated sense buffer

Christoph Hellwig (1):
virtio_blk: don't blindly derefence req->rq_disk

FUJITA Tomonori (4):
block: let blk_end_request_all handle bidi requests
scsi: simplify the bidi completion
block: move completion related functions back to blk-core.c
block: needs to set the residual length of a bidi request

Hannes Reinecke (1):
virtio_blk: SG_IO passthru support

James Bottomley (3):
block: allow blk_rq_map_kern to append to requests
block: fix oops with block tag queueing
block: fix an oops on BLKPREP_KILL

Jeff Moyer (1):
block: implement blkdev_readpages

Jens Axboe (11):
block: make blk_do_io_stat() do the full "is this rq accountable" checks
block: include discard requests in IO accounting
splice: fix misleading comment
splice: fix repeated kmap()'s in default_file_splice_read()
virtio_blk: get rid of unused variable
block: add warning to blk_make_request()
block: change the tag sync vs async restriction logic
Merge branch 'master' into for-2.6.31
Merge branch 'master' into for-2.6.31
Revert "block: implement blkdev_readpages"
Revert "block: Fix bounce limit setting in DM"

Kiyoshi Ueda (3):
block: fix no diskstat problem
block: fix a possible oops on elv_abort_queue()
block: add request clone interface (v2)

Martin K. Petersen (8):
block: Do away with the notion of hardsect_size
block: Use accessor functions for queue limits
block: Move queue limits to an embedded struct
block: Expose stacked device queues in sysfs
block: Export I/O topology for block devices and partitions
ide-disk: fix missing max_sectors accessor function
block: Fix bounce limit setting in DM
block: Add missing bounce_pfn stacking and fix comments

Michal Simek (1):
fs/bio.c: add missing __user annotation

Mike Snitzer (1):
block: export blk_stack_limits()

Miklos Szeredi (4):
splice: implement pipe to pipe splicing
splice: implement default splice_read method
splice: implement default splice_write method
splice: fix kmaps in default_file_splice_write()

Nikanth Karthikesan (2):
block: catch trying to use more bits than request->cmd_flags has
block: prevent possible io_context->refcount overflow

Ondrej Zary (1):
floppy: fix hibernation

Robert P. J. Day (1):
ramdisk: remove long-deprecated "ramdisk=" boot-time parameter

Roel Kluin (1):
xen-blkfront: beyond ARRAY_SIZE of info->shadow

Stephen M. Cameron (2):
cciss: factor out core of sendcmd() for a more sane interface
cciss: fix SCSI device reset handler

Tejun Heo (84):
mg_disk: fix locking
hd: fix locking
block: clear req->errors on bio completion only for fs requests
ide-tape: remove back-to-back REQUEST_SENSE detection
ide: use blk_run_queue() instead of blk_start_queueing()
ide: don't set REQ_SOFTBARRIER
ide kill unused ide_cmd->special
ide-cd: clear sense buffer before issuing request sense
ide-floppy: block pc always uses bio
ide-taskfile: don't abuse rq->buffer
ide-atapi: don't abuse rq->buffer
ide-cd: don't abuse rq->buffer
ide-cd,atapi: use bio for internal commands
ide-pm: don't abuse rq->data
ide-tape,floppy: fix failed command completion after request sense
ide-atapi,tape,floppy: allow ->pc_callback() to change rq->data_len
ide-tape: use single continuous buffer
ide-tape: use standard data transfer mechanism
ide-tape: kill idetape_bh
ide-tape: unify r/w init paths
ide-tape: use byte size instead of sectors on rw issue functions
ide-tape: simplify read/write functions
ide-atapi: kill unused fields and callbacks
ide: drop rq->data handling from ide_map_sg()
ide-dma: don't reset request fields on dma_timeout_retry()
block: merge blk_invoke_request_fn() into __blk_run_queue()
block: kill blk_start_queueing()
block: don't set REQ_NOMERGE unnecessarily
block: cleanup REQ_SOFTBARRIER usages
block: clean up misc stuff after block layer timeout conversion
block: reorder request completion functions
block: reorganize request fetching functions
block: kill blk_end_request_callback()
block: clean up request completion API
block: move rq->start_time initialization to blk_rq_init()
block: implement and use [__]blk_end_request_all()
block: replace end_request() with [__]blk_end_request_cur()
arm-omap: don't abuse rq->data
block: kill rq->data
block: make blk_end_request_cur() return bool
block: don't init rq fields unnecessarily
amiflop,ataflop,xd,mg_disk: clean up unnecessary stuff from block drivers
ps3disk: simplify request completion
sunvdc: kill vdc_end_request()
ubd: cleanup completion path
ubd: drop unnecessary rq->sector manipulation
hd: clean up request completion paths
swim3: clean up request completion paths
swim: clean up request completion paths
mg_disk: fold mg_disk.h into mg_disk.c
mg_disk: clean up request completion paths
nbd: don't clear rq->sector and nr_sectors unnecessarily
ide-tape: don't initialize rq->sector for rw requests
block: add rq->resid_len
block: implement blk_rq_pos/[cur_]sectors() and convert obvious ones
block: convert to pos and nr_sectors accessors
ide: convert to rq pos and nr_sectors accessors
block: drop request->hard_* and *nr_sectors
block: cleanup rq->data_len usages
ide: cleanup rq->data_len usages
block: hide request sector and data_len
block: blk_rq_[cur_]_{sectors|bytes}() usage cleanup
ide: dequeue in-flight request
mg_disk: fix queue hang / infinite retry on !fs requests
mg_disk: dequeue and track in-flight request
hd: dequeue and track in-flight request
ataflop: dequeue and track in-flight request
swim3: dequeue in-flight request
xsysace: dequeue in-flight request
paride: dequeue in-flight request
ps3disk: dequeue in-flight request
amiflop: dequeue in-flight request
swim: dequeue in-flight request
xd: dequeue in-flight request
mtd_blkdevs: dequeue in-flight request
jsflash: dequeue in-flight request
z2ram: dequeue in-flight request
block: convert to dequeueing model (easy ones)
gdrom: dequeue in-flight request
block: implement and enforce request peek/start/fetch
scsi: fix resid_len mis-conversion in scsi_end_request()
ub: use __blk_end_request_all()
block: set rq->resid_len to blk_rq_bytes() on issue
bio: always copy back data for copied kernel requests

john cooper (1):
Add serial number support for virtio_blk, V4a

[email protected] (8):
cciss: Use schedule_timeout_uninterruptible in SCSI error handling code
cciss: factor out core of sendcmd_withirq() for use by SCSI error handling code
cciss: simplify interface of sendcmd() and sendcmd_withirq()
cciss: factor out fix target status processing code from sendcmd functions
cciss: separate error processing and command retrying code in sendcmd_withirq_core()
cciss: change SCSI error handling routines to work with interrupts enabled.
cciss: Remove no longer needed sendcmd reject processing code
cciss: decode unit attention in SCSI error handling code

vibi sreenivasan (1):
Removed reference to non-existing file Documentation/PCI/PCI-DMA-mapping.txt

Documentation/ABI/testing/sysfs-block | 59 ++
.../ABI/testing/sysfs-bus-pci-devices-cciss | 33 +
Documentation/block/biodoc.txt | 2 +-
arch/arm/plat-omap/mailbox.c | 63 +-
arch/powerpc/sysdev/axonram.c | 2 +-
arch/um/drivers/ubd_kern.c | 36 +-
block/Kconfig | 11 +-
block/as-iosched.c | 24 +-
block/blk-barrier.c | 27 +-
block/blk-core.c | 858 ++++++++++++-------
block/blk-exec.c | 1 -
block/blk-integrity.c | 2 +-
block/blk-ioc.c | 12 +-
block/blk-map.c | 25 +-
block/blk-merge.c | 71 +-
block/blk-settings.c | 269 +++++-
block/blk-sysfs.c | 59 +-
block/blk-tag.c | 17 +-
block/blk-timeout.c | 22 +-
block/blk.h | 51 +-
block/bsg.c | 8 +-
block/cfq-iosched.c | 38 +-
block/compat_ioctl.c | 4 +-
block/deadline-iosched.c | 2 +-
block/elevator.c | 185 +----
block/genhd.c | 11 +
block/ioctl.c | 12 +-
block/scsi_ioctl.c | 13 +-
drivers/ata/libata-scsi.c | 2 +-
drivers/block/DAC960.c | 10 +-
drivers/block/Kconfig | 2 +-
drivers/block/amiflop.c | 54 +-
drivers/block/ataflop.c | 66 +-
drivers/block/brd.c | 7 +-
drivers/block/cciss.c | 927 ++++++++++++--------
drivers/block/cciss.h | 34 +-
drivers/block/cciss_cmd.h | 2 +
drivers/block/cciss_scsi.c | 109 ++-
drivers/block/cpqarray.c | 20 +-
drivers/block/floppy.c | 85 ++-
drivers/block/hd.c | 106 ++--
drivers/block/loop.c | 37 +-
drivers/block/mg_disk.c | 537 +++++++-----
drivers/block/nbd.c | 23 +-
drivers/block/paride/pcd.c | 29 +-
drivers/block/paride/pd.c | 22 +-
drivers/block/paride/pf.c | 47 +-
drivers/block/pktcdvd.c | 8 +-
drivers/block/ps3disk.c | 24 +-
drivers/block/sunvdc.c | 14 +-
drivers/block/swim.c | 48 +-
drivers/block/swim3.c | 107 ++--
drivers/block/sx8.c | 17 +-
drivers/block/ub.c | 54 +-
drivers/block/viodasd.c | 12 +-
drivers/block/virtio_blk.c | 110 ++-
drivers/block/xd.c | 41 +-
drivers/block/xen-blkfront.c | 34 +-
drivers/block/xsysace.c | 46 +-
drivers/block/z2ram.c | 19 +-
drivers/cdrom/cdrom.c | 4 +-
drivers/cdrom/gdrom.c | 36 +-
drivers/cdrom/viocd.c | 33 +-
drivers/char/raw.c | 2 +-
drivers/ide/ide-atapi.c | 177 +++--
drivers/ide/ide-cd.c | 152 +---
drivers/ide/ide-cd.h | 4 -
drivers/ide/ide-disk.c | 11 +-
drivers/ide/ide-dma.c | 22 +-
drivers/ide/ide-floppy.c | 32 +-
drivers/ide/ide-io.c | 57 +-
drivers/ide/ide-ioctls.c | 1 -
drivers/ide/ide-lib.c | 2 +-
drivers/ide/ide-park.c | 7 +-
drivers/ide/ide-pm.c | 38 +-
drivers/ide/ide-tape.c | 735 ++++------------
drivers/ide/ide-taskfile.c | 20 +-
drivers/ide/pdc202xx_old.c | 2 +-
drivers/ide/tc86c001.c | 2 +-
drivers/ide/tx4939ide.c | 2 +-
drivers/md/bitmap.c | 4 +-
drivers/md/dm-exception-store.c | 2 +-
drivers/md/dm-log.c | 3 +-
drivers/md/dm-snap-persistent.c | 2 +-
drivers/md/dm-table.c | 38 +-
drivers/md/linear.c | 2 +-
drivers/md/md.c | 2 +-
drivers/md/multipath.c | 4 +-
drivers/md/raid0.c | 2 +-
drivers/md/raid1.c | 4 +-
drivers/md/raid10.c | 8 +-
drivers/md/raid5.c | 4 +-
drivers/memstick/core/mspro_block.c | 19 +-
drivers/message/fusion/mptsas.c | 22 +-
drivers/message/i2o/i2o_block.c | 43 +-
drivers/mmc/card/block.c | 12 +-
drivers/mmc/card/queue.c | 11 +-
drivers/mtd/mtd_blkdevs.c | 43 +-
drivers/s390/block/dasd.c | 37 +-
drivers/s390/block/dasd_diag.c | 5 +-
drivers/s390/block/dasd_eckd.c | 6 +-
drivers/s390/block/dasd_fba.c | 7 +-
drivers/s390/block/dcssblk.c | 2 +-
drivers/s390/block/xpram.c | 2 +-
drivers/s390/char/tape_34xx.c | 2 +-
drivers/s390/char/tape_3590.c | 2 +-
drivers/s390/char/tape_block.c | 26 +-
drivers/sbus/char/jsflash.c | 26 +-
drivers/scsi/eata.c | 24 +-
drivers/scsi/libsas/sas_expander.c | 16 +-
drivers/scsi/libsas/sas_host_smp.c | 49 +-
drivers/scsi/lpfc/lpfc_scsi.c | 22 +-
drivers/scsi/mpt2sas/mpt2sas_transport.c | 23 +-
drivers/scsi/osd/osd_initiator.c | 72 +-
drivers/scsi/scsi_lib.c | 87 +--
drivers/scsi/scsi_tgt_lib.c | 2 +-
drivers/scsi/scsi_transport_sas.c | 4 +-
drivers/scsi/sd.c | 26 +-
drivers/scsi/sd_dif.c | 2 +-
drivers/scsi/sg.c | 17 +-
drivers/scsi/sr.c | 17 +-
drivers/scsi/st.c | 6 +-
drivers/scsi/u14-34f.c | 22 +-
drivers/usb/storage/scsiglue.c | 4 +-
fs/bio.c | 26 +-
fs/block_dev.c | 6 +-
fs/buffer.c | 6 +-
fs/coda/file.c | 9 +-
fs/direct-io.c | 2 +-
fs/exofs/osd.c | 4 +-
fs/ext3/super.c | 4 +-
fs/ext4/super.c | 2 +-
fs/gfs2/ops_fstype.c | 4 +-
fs/gfs2/rgrp.c | 2 +-
fs/nilfs2/the_nilfs.c | 2 +-
fs/ntfs/super.c | 6 +-
fs/ocfs2/cluster/heartbeat.c | 2 +-
fs/ocfs2/super.c | 2 +-
fs/partitions/check.c | 10 +
fs/partitions/ibm.c | 2 +-
fs/partitions/msdos.c | 4 +-
fs/pipe.c | 14 +
fs/read_write.c | 7 +-
fs/splice.c | 338 +++++++-
fs/udf/super.c | 2 +-
fs/xfs/linux-2.6/xfs_buf.c | 2 +-
include/linux/bio.h | 10 +-
include/linux/blkdev.h | 245 ++++--
include/linux/device-mapper.h | 2 +-
include/linux/elevator.h | 4 +-
include/linux/fs.h | 2 +
include/linux/genhd.h | 1 +
include/linux/ide.h | 27 +-
include/linux/iocontext.h | 6 +-
include/linux/loop.h | 3 +-
include/linux/mg_disk.h | 206 -----
include/linux/pipe_fs_i.h | 1 +
include/linux/splice.h | 3 +-
include/linux/virtio_blk.h | 12 +
include/scsi/scsi_cmnd.h | 2 +-
kernel/trace/blktrace.c | 16 +-
mm/bounce.c | 4 +-
162 files changed, 4126 insertions(+), 3516 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
delete mode 100644 include/linux/mg_disk.h

--
Jens Axboe


2009-06-11 18:20:23

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31



On Thu, 11 Jun 2009, Jens Axboe wrote:
>
> This is the bulk of the block changes for 2.6.31, please pull.
>
> git://git.kernel.dk/linux-2.6-block.git for-2.6.31

Ok, this clashed pretty badly with both the tracing tree (which obviously
has block tracers) and with my pull ide pull from Bartlomiej (which
obviously has ide driver changes).

I fixed everything up, and it _looks_ ok, including a "allyesconfig" build
etc. It wasn't totally trivial, though - in the sense that it's entirely
possible that I fixed something up incorrectly. Also, in the tracer code,
I kept the checks for whether something is a "pc" of "fs" request, so it
now looks like

__entry->sector = blk_pc_request(rq) ? 0 : blk_rq_pos(rq);

and I suspect that it could just be an unconditional

__entry->sector = blk_rq_pos(rq);

instead, but somebody involved with the whole block tracing thing needs to
check that out.

The ide-tape.c changes also need some expert tender loving checks. I
neither know the code, nor have the hardware to check my fixups. Almost
all the changes are actually by the same person - it's almost all Tejun's
code (and mostly the same patches), just coming in through two different
trees. Not very nice.

Btw, Jens: in your tree, you've committed Tejun's changes without adding
your own sign-off. Not good!

Linus

2009-06-11 18:27:08

by Jens Axboe

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31

On Thu, Jun 11 2009, Linus Torvalds wrote:
>
>
> On Thu, 11 Jun 2009, Jens Axboe wrote:
> >
> > This is the bulk of the block changes for 2.6.31, please pull.
> >
> > git://git.kernel.dk/linux-2.6-block.git for-2.6.31
>
> Ok, this clashed pretty badly with both the tracing tree (which obviously
> has block tracers) and with my pull ide pull from Bartlomiej (which
> obviously has ide driver changes).
>
> I fixed everything up, and it _looks_ ok, including a "allyesconfig" build
> etc. It wasn't totally trivial, though - in the sense that it's entirely
> possible that I fixed something up incorrectly. Also, in the tracer code,
> I kept the checks for whether something is a "pc" of "fs" request, so it
> now looks like
>
> __entry->sector = blk_pc_request(rq) ? 0 : blk_rq_pos(rq);
>
> and I suspect that it could just be an unconditional
>
> __entry->sector = blk_rq_pos(rq);
>
> instead, but somebody involved with the whole block tracing thing needs to
> check that out.
>
> The ide-tape.c changes also need some expert tender loving checks. I
> neither know the code, nor have the hardware to check my fixups. Almost
> all the changes are actually by the same person - it's almost all Tejun's
> code (and mostly the same patches), just coming in through two different
> trees. Not very nice.

I agree, that part is a mess. Hopefully we wont have this degree of
churn in this area again, but I do wish that we had more block consumers
based off the block tree. Having cross-dependent stuff in different
trees just gets messy quickly. Thanks for resolving it though, the IDE
code wasn't pulled in when I sent the pull request or I would've done it
myself. I usually try to make sure that it merges cleanly with your head
of tree before sending it out.

> Btw, Jens: in your tree, you've committed Tejun's changes without adding
> your own sign-off. Not good!

That's for the patches that I pulled from his git tree. It should list
him as committer too.

--
Jens Axboe

2009-06-11 18:44:29

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31



On Thu, 11 Jun 2009, Jens Axboe wrote:
>
> > Btw, Jens: in your tree, you've committed Tejun's changes without adding
> > your own sign-off. Not good!
>
> That's for the patches that I pulled from his git tree. It should list
> him as committer too.

NO!

It sounds like you have done a _major_ no-no, which is to pull from his
tree, and then rebase it.

DO NOT DO THAT! NOT EVER!

If you pull from somebody elses tree, you can no longer touch the commit.
It absolutely has to stay the same. Otherwise we see this kind of insane
duplication.

You're doing something seriously wrong here. I wrote a long rant about
what the rules were last release cycle, but now I can't find it.
Basically, if you're not the committer, you really must never EVER touch
it.

[ Anybody with enough google-fu to find my rant, so I don't have to
re-rant? ]

Linus

2009-06-11 18:52:13

by Jens Axboe

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31

On Thu, Jun 11 2009, Linus Torvalds wrote:
>
>
> On Thu, 11 Jun 2009, Jens Axboe wrote:
> >
> > > Btw, Jens: in your tree, you've committed Tejun's changes without adding
> > > your own sign-off. Not good!
> >
> > That's for the patches that I pulled from his git tree. It should list
> > him as committer too.
>
> NO!
>
> It sounds like you have done a _major_ no-no, which is to pull from his
> tree, and then rebase it.
>
> DO NOT DO THAT! NOT EVER!
>
> If you pull from somebody elses tree, you can no longer touch the commit.
> It absolutely has to stay the same. Otherwise we see this kind of insane
> duplication.
>
> You're doing something seriously wrong here. I wrote a long rant about
> what the rules were last release cycle, but now I can't find it.
> Basically, if you're not the committer, you really must never EVER touch
> it.
>
> [ Anybody with enough google-fu to find my rant, so I don't have to
> re-rant? ]

I pulled from his tree, don't think I ever rebased it. To be honest, I
rebase a lot, and I used to do that for the 'export' branches as well.
But for this cycle I have kept it clean and pulled in your tree when I
knew a conflict at arisen. More trees are now based off the block tree,
so I wanted to make sure that they were able to pull cleanly when they
wanted to. I usually also always apply the patches manually instead of
pulling it in, since I go over the patches anyway.

So I fully agree with what you are saying, if anything was rebased this
time then it was a mistake (that I don't recollect)...

--
Jens Axboe

2009-06-11 19:24:48

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31



On Thu, 11 Jun 2009, Jens Axboe wrote:
>
> I pulled from his tree, don't think I ever rebased it.

I'm pretty sure you did. That's why
(a) you're the committer (because you are)
(b) the commits aren't the same when I pull, even though the diffs are.

Anyway, it's ok to take an occational patch from another tree, but then it
needs to be signed off (and no faking of committer data, please) as a
cherry-pick, not the way you did it.

Linus

2009-06-11 19:54:00

by Diego Calleja

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31

On Jueves 11 Junio 2009 20:42:04 Linus Torvalds escribi?:

> [ Anybody with enough google-fu to find my rant, so I don't have to
> re-rant? ]

My google-fu is not great, but I usually save the most interesting rants.

http://www.mail-archive.com/[email protected]/msg39091.html
http://lkml.org/lkml/2008/5/16/540

2009-06-11 20:04:18

by Jens Axboe

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31

On Thu, Jun 11 2009, Linus Torvalds wrote:
>
>
> On Thu, 11 Jun 2009, Jens Axboe wrote:
> >
> > I pulled from his tree, don't think I ever rebased it.
>
> I'm pretty sure you did. That's why
> (a) you're the committer (because you are)
> (b) the commits aren't the same when I pull, even though the diffs are.
>
> Anyway, it's ok to take an occational patch from another tree, but then it
> needs to be signed off (and no faking of committer data, please) as a
> cherry-pick, not the way you did it.

I just looked up the offending commits, and you are right. I must have
rebased early on, after having pull some of the patches from Tejun. My
bad, wont repeat!

--
Jens Axboe

2009-06-11 20:06:54

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31



On Thu, 11 Jun 2009, Diego Calleja wrote:

> On Jueves 11 Junio 2009 20:42:04 Linus Torvalds escribi?:
>
> > [ Anybody with enough google-fu to find my rant, so I don't have to
> > re-rant? ]
>
> My google-fu is not great, but I usually save the most interesting rants.
>
> http://www.mail-archive.com/[email protected]/msg39091.html
> http://lkml.org/lkml/2008/5/16/540

Yup, that first one was the one I meant.

Linus

2009-06-12 06:48:31

by Borislav Petkov

[permalink] [raw]
Subject: Re: [GIT PULL] first block round for 2.6.31

On Thu, Jun 11, 2009 at 11:18:41AM -0700, Linus Torvalds wrote:
> The ide-tape.c changes also need some expert tender loving checks. I
> neither know the code, nor have the hardware to check my fixups.

Yep, this is the result of the slimming exercise and diet pills we've
put ide-tape on because it'd grown obese over the years and it had its
own contraptions for buffer and pipeline handling which were clearly too
much. It had to be taught to behave just like every other ATAPI device
driver.

But seriously, I'm testing ide-atapi stuff regularly and I'll take a
look at the merge result during the weekend just to make sure everything
went fine.

> Almost
> all the changes are actually by the same person - it's almost all Tejun's
> code (and mostly the same patches), just coming in through two different
> trees. Not very nice.

I think this was a one-time-thing only since it required syncing between
at least three trees so it is possible that somewhere along the way
things clash. It'll probably happen again when someone decides to change
block layer/LLDDs interface again but those are very seldom, I hope, for
the sake of everybody involved :).

--
Regards/Gruss,
Boris.