Re: [PATCH] blkgetsize64 ioctl

[Michael E Brown]

On Thu, 30 Aug 2001, Ben LaHaise wrote:

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

Ok. I can agree with that. As a junior kernel hacker, I did not know about
this issue, and I agree that somebody with a bit more experience should
have reserved the next number. Sorry :-(

But, since I've gone through this ioctl reservation conflict twice now
(e2fsprogs and something having to do with XFS), I think this is a more
general problem.

As a side note, a copy of the second edition of "Linux Device Drivers" I
am using doesn't mention this idea of reserving ioctl numbers.

-- 
Michael Brown
Linux OS Development
Dell Computer Corp

  If each of us have one object, and we exchange them,
     then each of us still has one object.
  If each of us have one idea,   and we exchange them,
     then each of us now has two ideas.