On Fri, Apr 28, 2023 at 5:08 AM Sergey Bugaev <buga...@gmail.com> wrote:

> On Fri, Apr 28, 2023 at 6:00 AM Flavio Cruz <flavioc...@gmail.com> wrote:
> > Dynamically sized strings can be represented as c_string[*] (*). We
> inline
> > up to 64 bytes but can pass arbitrary strings if needed out of line.
> Currently
> > implementation is limited to input arguments only (MiG will error out if
> > used as output).
> >
> > In the user stub, we first run strlen on the parameter to get
> > its length and pass it to msgtl_number. If the size is greater than 64,
> > then we pass the pointer instead, otherwise we strncpy the parameter
> > into the message and limit the size of the string in the final message
> > to only mach_msg_type_long_t + strlen(string) + 1.
> Hi -- this is super great!! looks exactly like what I was wishing for!
> > Tested by replacing file name for dir_lookup using c_string[*] and
> > bootstrapping the whole system.
> Could you please clarify what you mean by bootstrapping here? Did you
> rebuild the whole system (Debian?) with your change? Does it build?
> Boot? Pass tests? Or did you LD_PRELOAD your build of glibc or
> something like that?

Sorry for the lack of clarity. I cross-compiled a basic Hurd system from my
Linux machine (used https://github.com/flavioc/cross-hurd) and browsed
through the file system and ran a few programs to check if something was

> Since this is using strlen, it will likely need something like glibc's
> 56010b73e81e2cb1082e418699f98353598fe671. And we'd need to land the
> glibc change first, and ensure that older glibc is not getting built
> with the new MIG / defs. (As I understand it, Debian ships old glibc
> but fresh MIG.)

I think you might be correct and, to be safe, we should do that. How do I
that what I have done looks good? Looking at the threads, it seems like I
to run the glibc test suite?

> As for ABI and API compatibility, do I understand it right that
> c_string[*] is not message-ABI-compatible with string_t, so we cannot
> just transparently replace the file name in dir_lookup, recompile
> _some_ programs and expect things to still work?

That is correct. However, I think it's possible to update MiG to write
code that can handle both situations. We would need to release all the
servers first
so that they recognize both formats and then eventually the user stubs.
we could also build functionality in MiG to call two stubs (first try the
new one using
c_string[*], then fallback to old) from the existing user API.

However, I'm not sure if this will get us closer to solving the problem of
being limited to 1024 chars since we also need to update retry_name to use
something like data_t which requires changing dir_lookup for both user and

> Sergey

Reply via email to