public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [resend PATCH] reserve BLKGETSIZE64 ioctl
@ 2001-09-04 21:43 Andries.Brouwer
  2001-09-04 22:27 ` Ben LaHaise
  0 siblings, 1 reply; 9+ messages in thread
From: Andries.Brouwer @ 2001-09-04 21:43 UTC (permalink / raw)
  To: Andries.Brouwer, bcrl; +Cc: linux-kernel, torvalds

    From bcrl@redhat.com Tue Sep  4 22:54:05 2001

    On Tue, 4 Sep 2001 Andries.Brouwer@cwi.nl wrote:

    > Then I am happy (as long as you don't take a reserved number).

    So the patch below is okay?

Roughly speaking, yes.

(But why do you insist on using 110?
I wrote "A jump here: 108-111 have been used" because that is
what I recall: three groups using 108-109 and one shifting to
110-111. I have no details, so may misremember, but still..)


Andries

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [resend PATCH] reserve BLKGETSIZE64 ioctl
@ 2001-09-04 13:50 Andries.Brouwer
  2001-09-04 20:54 ` Ben LaHaise
  0 siblings, 1 reply; 9+ messages in thread
From: Andries.Brouwer @ 2001-09-04 13:50 UTC (permalink / raw)
  To: Andries.Brouwer, bcrl; +Cc: linux-kernel, torvalds

>> Soon we'll all need a BLKGETSIZE64 ioctl, that gives
>> the size of a block device in bytes.

> I'd accepted that suggestion

Then I am happy (as long as you don't take a reserved number).

Concerning policy, of course that is up to Linus -
for myself I would prefer adding a well-motivated ioctl
above reserving a number. After all, an ioctl is almost
always about transporting some small amount of information,
hence is implemented by a dozen lines of code or so,
clean, and without impact on the rest of the kernel,
so if it is going to be added eventually it might as well
be added immediately.

So, until Linus says otherwise, you might try once or twice
to submit the actual ioctl instead of just the reservation.

Andries


^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [resend PATCH] reserve BLKGETSIZE64 ioctl
@ 2001-09-03 20:57 Andries.Brouwer
  2001-09-04  1:09 ` Ben LaHaise
  0 siblings, 1 reply; 9+ messages in thread
From: Andries.Brouwer @ 2001-09-03 20:57 UTC (permalink / raw)
  To: bcrl, torvalds; +Cc: linux-kernel

    From: Ben LaHaise <bcrl@redhat.com>

    Is there any problem with the patch below for reserving a 64 bit get block
    device size ioctl?

    +#define BLKBSZGET  _IOR(0x12,110,sizeof(u64))
     #define BLKBSZGET  _IOR(0x12,112,sizeof(int))

Yes.

(1) As you can see you'll only get redefinition complaints.
In other words, there is a B too much in the ioctl name.

(2) We just concluded that 108-111 have been used for various
private purposes. If we avoid 108-111 in all official kernels
then nobody will be surprised if he ever uses some system
utility that uses one of these.
Thus, it is a very bad idea to want to use these again.

(3) Soon we'll all need a BLKGETSIZE64 ioctl, that gives
the size of a block device in bytes. Your proposed ioctl
gave the size in blocks if I recall correctly.
So, if you have to change the name and the number,
you might as well change the definition.

Andries


[We might reserve an area for private use - some ioctl numbers
that are guaranteed never to become part of an official kernel.]



^ permalink raw reply	[flat|nested] 9+ messages in thread
[parent not found: <Pine.LNX.4.33.0109031119400.1610-100000@toomuch.toronto.re dhat.com>]
* [resend PATCH] reserve BLKGETSIZE64 ioctl
@ 2001-09-03 15:21 Ben LaHaise
  2001-09-03 16:02 ` Andreas Schwab
  0 siblings, 1 reply; 9+ messages in thread
From: Ben LaHaise @ 2001-09-03 15:21 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

Hello,

Is there any problem with the patch below for reserving a 64 bit get block
device size ioctl?

		-ben

diff -urN v2.4.10-pre4/include/linux/fs.h work/include/linux/fs.h
--- v2.4.10-pre4/include/linux/fs.h	Mon Sep  3 11:04:39 2001
+++ work/include/linux/fs.h	Mon Sep  3 11:18:44 2001
@@ -182,7 +182,8 @@
 /* This was here just to show that the number is taken -
    probably all these _IO(0x12,*) ioctls should be moved to blkpg.h. */
 #endif
-/* A jump here: 108-111 have been used for various private purposes. */
+/* A jump here: 108,109,111 have been used for various private purposes. */
+#define BLKBSZGET  _IOR(0x12,110,sizeof(u64))
 #define BLKBSZGET  _IOR(0x12,112,sizeof(int))
 #define BLKBSZSET  _IOW(0x12,113,sizeof(int))



^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-09-04 22:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-04 21:43 [resend PATCH] reserve BLKGETSIZE64 ioctl Andries.Brouwer
2001-09-04 22:27 ` Ben LaHaise
  -- strict thread matches above, loose matches on Subject: below --
2001-09-04 13:50 Andries.Brouwer
2001-09-04 20:54 ` Ben LaHaise
2001-09-03 20:57 Andries.Brouwer
2001-09-04  1:09 ` Ben LaHaise
     [not found] <Pine.LNX.4.33.0109031119400.1610-100000@toomuch.toronto.re dhat.com>
2001-09-03 15:40 ` Anton Altaparmakov
2001-09-03 15:21 Ben LaHaise
2001-09-03 16:02 ` Andreas Schwab

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox