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

[christos%astron.com@localhost (Christos Zoulas)]

In article <200901061801.TAA0000063553%zel459.zel.kfa-juelich.de@localhost>,
Matthias Drochner  <M.Drochner%fz-juelich.de@localhost> wrote:
>
>christos%zoulas.com@localhost said:
>> changes time_t and dev_t to become 64 bits
>
>My impression is that the dev_t part is not complete;
>there are some inconsistencies.
>(I don't see a compelling reason to change it at all, but
>I agree that if there was one, it would be wise to
>piggyback it onto the "struct stat" change happening anyway.)
>-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.
>-config(1) mixes build host and target definitions, in
> particular a host's PRIxx format letter is used in
> target context, and "long long" is assumed to match dev_t.
> At a first glance, it might be feasible to avoid
> calculations with the target's full dev_t within config(1)
> completely, just pass major and minor numbers around. Needs
> to be checked.

The point is that the externally visible API's (kernel and userland)
are 64 bit now, and the values have not changed internally for
compatibility. You can always make things use more bits transparently
later if you make the proposed change now.

christos