Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: HEADS UP: I will be merging christos-time_t by the end of the week

In article <>,
David Holland  <> wrote:
>On Tue, Jan 06, 2009 at 07:01:11PM +0100, Matthias Drochner wrote:
> > -major()/minor() return 64-bit numbers now, but calculations
> >  are done with ints and 32 bits elsewhere in the kernel.
> >  Imho it would be better to leave major and minor numbers
> >  alone for now - for now only 12/20 bits are used anyway,
> >  and any change here would require a lot more compatibility
> >  considerations. And use of 64-bit arithmetics where not
> >  necessary is wasteful, at least on 32-bit machines.
> > -Likewise, major numbers should not use NODEV as special
> >  value. This is a different namespace.
>What conclusions did we come to regarding PR 39215? I got behind on
>the discussion there at the time and haven't caught up on it yet.
>(Or were there no conclusions and this is the next round?)
>I think your(?) argument that minor numbers are used for array
>indexing and whatnot and shouldn't be bigger than machine words was
>fairly persuasive.

I think that we could define new types (either devmajor_t or major_t)
and have those be something like size_t since they are used for array
The problem with this approach is that we cannot check
    devmajor_t maj;

    if (maj == NODEV)

since NODEV is (dev_t)~0 not (devmajor_t)~0. We could define another
constant NODEVMAJOR, but the proliferation of constants makes this
suboptimal. As far as the cost of doing 64 bit arithmetic on a 32 bit
platform, there is no significant difference, since the following:

#include <sys/types.h>

char  barf[100];

foo(size_t l)
        return barf[l];

bar(unsigned long long l)
        return barf[(size_t)l];

produces the same assembly code for both functions, and changing the above
to barf[l + 1] and barf[(size_t)l + 1], adds one instruction in the second

I am more inclined to leave major() and minor() to return dev_t for
simplicity, but I don't feel strongly about it and I will add the
extra types if there is consensus.


Home | Main Index | Thread Index | Old Index