> And your response to the rest of the points I raised would be?
fs/block_dev.c is not a hot spot in the kernel. It's been patched maybe 3
or 4 times over the last year, so I don't buy the argument that it would
have been difficult to maintain. (Think if (offset >=
last_block_start(dev) return read_last_block(offset, buf, len);)
> I'm sorry about e2fsprogs. If I had known a bit better (this was my first
> kernel patch), I would have added a magic number to the struct you pass
> in, and that would have prevented this little bit of braindamage.
No, that's not what's got me miffed. What is a problem here is that an
obvious next to use ioctl number in a *CORE* kernel api was used without
reserving it. AND PEOPLE SHIPPED IT! I for one don't go about shipping
new ABIs without reserving at least a placeholder for it in the main
kernel (or stating that the code is not bearing a fixed ABI). If the
ioctl # was in the main kernel, this mess would never have happened even
with the accidental shipping of the patch in e2fsprogs. I just hope
people will remember this in the future. ABI compatibility is not that
hard if it's thought about.
-ben
-
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/