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.)
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 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
