我正在寻找描述 ioctl 0x1268 (BLKSSZGET) 的预期参数和行为的明确规范。

这个数字在很多地方都有声明(没有一个包含明确的引用来源)，例如 linux/fs.h，但我找不到它的规范。

当然，过去某个时候有人决定 0x1268 将获取设备的物理扇区大小，并将其记录在某处。这些信息从何而来，我在哪里可以找到它？

编辑:我不是在问 BLKSSZGET 通常做什么，也不是在问它在什么标题中定义。我正在寻找一个确定的、标准化的来源，说明它应该采用什么参数类型以及它的行为应该是什么任何实现它的驱动程序。

具体来说，我问是因为在 util-linux 2.23(和 2.24)的 blkdiscard 中似乎存在一个错误，其中扇区大小被查询到 uint64_t，但高 32 位未被触及，因为 BLKSSZGET 出现 需要一个 32 位整数，这会导致扇区大小不正确、对齐计算不正确以及在blkdiscard 当它应该成功时。所以在我提交补丁之前，我需要绝对确定地确定问题是 blkdiscard 应该使用 32 位整数，还是我内核中的驱动程序实现应该使用64 位整数。

编辑 2:由于我们正处于主题中，建议的补丁假设 blkdiscard 是不正确的 是:

--- sys-utils/blkdiscard.c-2.23 2013-11-01 18:28:19.270004947 -0400
+++ sys-utils/blkdiscard.c  2013-11-01 18:29:07.334002382 -0400
@@ -71,7 +71,8 @@
 {
    char *path;
    int c, fd, verbose = 0, secure = 0;
-   uint64_t end, blksize, secsize, range[2];
+   uint64_t end, blksize, range[2];
+   uint32_t secsize;
    struct stat sb;

    static const struct option longopts[] = {
@@ -146,8 +147,8 @@
        err(EXIT_FAILURE, _("%s: BLKSSZGET ioctl failed"), path);

    /* align range to the sector size */
-   range[0] = (range[0] + secsize - 1) & ~(secsize - 1);
-   range[1] &= ~(secsize - 1);
+   range[0] = (range[0] + (uint64_t)secsize - 1) & ~((uint64_t)secsize - 1);
+   range[1] &= ~((uint64_t)secsize - 1);

    /* is the range end behind the end of the device ?*/
    end = range[0] + range[1];

应用于例如https://www.kernel.org/pub/linux/utils/util-linux/v2.23/ .

最佳答案

“这是在哪里指定的？”的答案似乎确实是内核源代码。

我在这里的内核邮件列表上问了这个问题:https://lkml.org/lkml/2013/11/1/620

作为回应，Theodore Ts'o wrote (注意:他在他的列表中错误地标识了 sys-utils/blkdiscard.c，但这无关紧要):

BLKSSZGET returns an int.  If you look at the sources of util-linux
v2.23, you'll see it passes an int to BLKSSZGET in 

    sys-utils/blkdiscard.c
    lib/blkdev.c

E2fsprogs also expects BLKSSZGET to return an int, and if you look at
the kernel sources, it very clearly returns an int.

The one place it doesn't is in sys-utils/blkdiscard.c, where as you
have noted, it is passing in a uint64 to BLKSSZGET.  This looks like
it's a bug in sys-util/blkdiscard.c.

然后他继续向 util-linux 上的 blkdiscard 提交补丁¹:

--- a/sys-utils/blkdiscard.c
+++ b/sys-utils/blkdiscard.c
@@ -70,8 +70,8 @@ static void __attribute__((__noreturn__)) usage(FILE *out)
 int main(int argc, char **argv)
 {
        char *path;
-       int c, fd, verbose = 0, secure = 0;
-       uint64_t end, blksize, secsize, range[2];
+       int c, fd, verbose = 0, secure = 0, secsize;
+       uint64_t end, blksize, range[2];
        struct stat sb;

        static const struct option longopts[] = {

我一直犹豫是否要在我的邮件列表帖子和这个 SO 问题的原始版本中提及 blkdiscard 工具，特别是因为这个原因:我知道我的内核源代码中有什么，修改 blkdiscard 以符合来源，这最终分散了人们对“这个记录在哪里？”这个真正问题的注意力。

因此，至于具体细节，比我更正式的人也表示 BLKSSZGET ioctl 采用 int，但关于文档的一般问题仍然存在。然后我跟进了 https://lkml.org/lkml/2013/11/3/125并收到了 Theodore Ts'o(wiki 的可信度)的另一个回复，回答了这个问题。他wrote :

> There was a bigger question hidden behind the context there that I'm
> still wondering about: Are these ioctl interfaces specified and
> documented somewhere? From what I've seen, and from your response, the
> implication is that the kernel source *is* the specification, and not
> document exists that the kernel is expected to comply with; is this
> the case?

The kernel source is the specification.  Some of these ioctl are
documented as part of the linux man pages, for which the project home
page is here:

     https://www.kernel.org/doc/man-pages/

However, these document existing practice; if there is a discrepancy
between what is in the kernel has implemented and the Linux man pages,
it is the Linux man pages which are buggy and which will be changed.
That is man pages are descriptive, not perscriptive.

我还询问了公共(public)内核 API 对“int”的一般使用，his response is there尽管这是题外话。

答案: 所以，你知道了，最后的答案是:ioctl 接口(interface)由内核源代码本身指定；没有内核遵守的文档。有文档描述了内核对各种ioctl的实现，但是如果不匹配，那是文档中的错误，而不是内核中的错误。

¹ 考虑到以上所有内容，我想指出，与我的相比，Theodore Ts'o 提交的补丁中的一个重要区别是使用“int”而不是“uint32_t”——根据内核源代码，BLKSSZGET 确实需要一个参数，该参数是平台上“int”的任何大小，而不是强制的 32 位值。

关于linux - ioctl参数(如0x1268/BLKSSZGET)实际指定在哪里？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19747663/