[Top][All Lists]

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

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

From: Flavio Cruz
Subject: Re: [PATCH gnumach] Use c_string for dev_name_t in the device subsystem.
Date: Thu, 27 Apr 2023 23:13:53 -0400

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.


reply via email to

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