blkgetsize64 ioctl
From: Ben LaHaise
...
An interesting conversation, this.
A is blamed for making the terrible mistake of shipping an unreserved ioctl, very stupid, because by accident B has made the minor mistake of shipping an unreserved ioctl.
Maybe I misread something.
From: Michael E Brown <[email protected]>
Alan,
Here is a patch that reserves the 108 and 109 ioctl numbers for
get/set last sector. This patch has already been merged into the ia64 tree, and is currently necessary in order to support the EFI GPT partitioning scheme on ia64. It is also in the Red Hat kernel tree. I had assumed that somebody at Red Hat would have forwarded it to you.
Marking the numbers not-to-be-used is certainly a good idea.
Concerning the need for this particular nonsense - we have had this discussion earlier this year, and also without any patches one can read the last sector. (Using some bad kludge, but still..)
One of the patches I have at ftp.kernel.org removes the entire problem - one needs (1) a test in ll_rw_blk.c that uses not the size in 1024-byte blocks but in 512-byte sectors, and (2) a set-blocksize ioctl.
And this latter is needed for other reasons as well.
Maybe I should resubmit some such patch fragments?
Andries
Quoted 3 lines
Content-Disposition: attachment; filename=patch-getlastsector-20010213
ZGlmZiAtcnVQIGxpbnV4L2luY2x1ZGUvbGludXgvZnMuaCBsaW51eC1pb2N0
Yes, indeed.
Quoted 5 lines
one needs (1) a test in
ll_rw_blk.cthat uses not the size in 1024-byte blocks but in 512-byte sectors, and (2) a set-blocksize ioctl.
And this latter is needed for other reasons as well.Maybe I should resubmit some such patch fragments?
If you can doit cleanly - yes