On Wed, 2 Jan 2008, James Bottomley wrote:
> >
> > To say that another way:
> >
> > "the code is functionally equivalent, EXCEPT IT ISN'T, and it's
> > known to be broken".
> >
> > wouldn't you say my version is more honest and correct?
>
> No. Just because a bug appears when a particular piece of code is in
> and disappears when it is reverted doesn't automatically equate to the
> code in question being buggy.
But it *DOES* mean that it's not equivalent.
> Look at the taxonomy of the bug. This is the form of the error:
>
> buffer I/O error on device sr0, logical block 20304
> attempt to access beyond end of device
> sr0: rw=0, want=81224, limit=40944
>
> The last limit is the most suggestive, that comes straight from
> bdev->bd_inode->i_size>>9 and is supposed to be the size of the block
> device in 512 byte blocks. For a 4.7GB DVD, it's a little small.
> Nothing in the sr code sets this directly (although it does come from
> get_blkdev() for the first opener). pktcdvd does set it, though ... and
> probably wrongly if the drive in question isn't UDF formatted.
.. but you're ignoring the fact that if pktcdvd sets it wrong, then it
should be visible with the pre-commit kernel *also*.
In other words, you continue to ignore the fact that BEHAVIOUR CHANGED.
Why?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
