lkml.org 
[lkml]   [2003]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] new system call mknod64

    On Mon, 21 Apr 2003, Roman Zippel wrote:
    >
    > May I ask what advantage it has to split that number?
    > Everywhere it's just a simple number, only when we present that number to
    > the user, we create some kind of illusion that this split has any meaning.

    Oh, the split has huge meaning inside the kernel. We split the number
    every time we open the device, and use that split to look up the result.

    There's another issue, though, which may or may not be a good thing. If we
    split and re-create the device number, that will always force the "dev_t"
    to be in "canonical form", ie if the major and minor both fit in 8 bits,
    then we will always fit the whole dev_t in 16 bits.

    This shows up as a difference in the two approaches: if you consider the
    user-supplied number as a unsplit binary "dev_t", then the user can supply
    a 64-bit number like 0x00000001000000001, and we will actually use that as
    the dev_t. However, if we split it up, and the user supplies <1,1>, then
    we will always generate 0x0000000000000101 as the 64-bit dev_t, and there
    is never any way to generate the "non-canonical" form.

    Does it matter? Probably not. I actually think it's slightly preferable to
    alway shave things in the canonical form, and the networked filesystems
    will generally canonicalize it anyway since they usually split it up into
    major/minor. But it _is_ potentially a user-visible difference.

    Linus

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:3.254 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site