Re: [PATCH gnumach] Use c_string for dev_name_t in the device subsystem.

[Flavio Cruz]

Hi Sergey

On Wed, Apr 26, 2023 at 01:43:55PM +0300, Sergey Bugaev wrote:
> Hi Flavio,
>
> could you please explain what the difference / the advantage of
> new_dev_name_t is over dev_name_t? (Preferably, put it into the commit
> message too.)

tl;dr; we can get rid of mach_msg_type_long_t on x86_64.

Longer explanation: MACH_MSG_TYPE_STRING_C sets msgt_size to be 1024 and 
msgt_number to be 1. So this is the only type which overflows the 
existing msgt_size. c_string is better since it uses 
msgt_size = 8 and msgt_number is the length of the string.

Once dev_name_t and default_pager_filename_t can be represented using msgt_size 
< 255,
then we only will need a larger msgtl_size, which can be added directly in the 8 
byte mach_msg_type_t.

> Isn't c_string same as MACH_MSG_TYPE_STRING_C? What are we gaining?
>
> What is your overall plan concerning string handling in RPCs? The two
> things I'd like to see improved in string handling are:
>
> * drop static upper bounds (I already ranted about this in a
>  response to one of your patches, and you said you agree...)
> * avoid memcpying strings into the message body (maybe unless
>  they're very short), and instead transmit them out of line / by VM
>  copy; and avoid *reserving* lots of space (4096, or 128 bytes like
>  here) for the string in the message body either

I sent a patch to solve this. We can probably use the new type here 
since it's strictly more flexible.

> Is this a step towards any of these goals? If not, when we do figure
> out the proper out-of-line dyn-sized strings, won't we have to
> introduce new_new_dev_name_t and device_open_new_new_request etc?
>
> Sorry if I'm missing something obvious here.
>
> Sergey