[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: |
Tue, 6 Dec 2022 02:10:52 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello Flavio,
What do you think of that?
Samuel
Samuel Thibault, le lun. 29 août 2022 01:21:23 +0200, a ecrit:
> Hello,
>
> 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;
> RPT
> 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;
> #else
> typedef natural_t vm_size_t;
> #endif
>
> to avoid exposing the new type to userland for now, so as to have the
> time to fix such questions before exposing the switch?
>
> Samuel
- Re: [PATCH 2/2] add rpc_versions for vm types,
Samuel Thibault <=