[Top][All Lists]

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

Re: [PATCH 2/2] add rpc_versions for vm types

From: Samuel Thibault
Subject: Re: [PATCH 2/2] add rpc_versions for vm types
Date: Mon, 29 Aug 2022 01:21:23 +0200
User-agent: NeoMutt/20170609 (1.8.3)


Luca Dariz, le dim. 03 avril 2022 16:59:55 +0200, a ecrit:
> @@ -88,13 +94,36 @@ typedef unsigned long long rpc_phys_addr_t;
>   * expressing the difference between two
>   * vm_offset_t entities.
>   */
> -#ifdef __x86_64__
>  typedef      unsigned long   vm_size_t;
> -#else
> -typedef      natural_t       vm_size_t;
> -#endif
>  typedef      vm_size_t *     vm_size_array_t;

Mmm, this has triggered a lot of warnings & errors about mismatches
between vm_size_t and mach_msg_type_number_t in userland hurd&glibc.

While a lot of them are real mistakes (passing mach_msg_type_number_t*
for a vm_size_t* parameter), others are questioning, for instance:

routine io_read (
        io_object: io_t;
        out data: data_t, dealloc;
        offset: loff_t;
        amount: vm_size_t);

amount is a vm_size_t, thus unsigned long, but the data_t array will
have a mach_msg_type_number_t size. On a 64bit userland, vm_size_t being
64bit would be useless if mach_msg_type_number_t is 32bit. Perhaps we
want to make mach_msg_type_number_t long? Or use another type for
the size of data_t?

That's tricky questions ahead. Perhaps we can for now use

#if defined(KERNEL) || defined(__x86_64__)
typedef unsigned long   vm_size_t;
typedef natural_t       vm_size_t;

to avoid exposing the new type to userland for now, so as to have the
time to fix such questions before exposing the switch?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]