lkml.org 
[lkml]   [2001]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] blkgetsize64 ioctl
On Thu, 30 Aug 2001, Michael E Brown wrote:

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:01    [W:0.073 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site