From: Andries.Brouwer@cwi.nl
To: alan@lxorguk.ukuu.org.uk
Cc: bcrl@redhat.com, linux-kernel@vger.kernel.org,
michael_e_brown@dell.com, tytso@mit.edu
Subject: Re: [PATCH] blkgetsize64 ioctl
Date: Fri, 31 Aug 2001 01:15:50 GMT [thread overview]
Message-ID: <200108310115.BAA318386@vlet.cwi.nl> (raw)
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 <michael_e_brown@dell.com>
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
> Content-Disposition: attachment; filename=patch-getlastsector-20010213
>
> ZGlmZiAtcnVQIGxpbnV4L2luY2x1ZGUvbGludXgvZnMuaCBsaW51eC1pb2N0
Yes, indeed.
next reply other threads:[~2001-08-31 1:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-31 1:15 Andries.Brouwer [this message]
2001-08-31 1:23 ` [PATCH] blkgetsize64 ioctl Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-08-30 16:11 Michael E Brown
2001-08-30 16:25 ` Ben LaHaise
2001-08-30 16:44 ` Michael E Brown
2001-08-30 16:47 ` Ben LaHaise
2001-08-30 17:02 ` Michael E Brown
2001-08-30 17:12 ` Ben LaHaise
2001-08-30 17:34 ` Michael E Brown
2001-08-30 18:51 ` Theodore Tso
2001-08-30 19:03 ` Alan Cox
2001-08-30 19:10 ` Michael E Brown
2001-08-30 19:18 ` Alan Cox
2001-08-30 11:57 Andries.Brouwer
2001-08-29 22:45 Ben LaHaise
2001-08-30 0:03 ` David S. Miller
2001-08-30 0:16 ` Ben LaHaise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200108310115.BAA318386@vlet.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael_e_brown@dell.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).