On Mon, Apr 19, 2021 at 10:18 PM Matthew Wilcox wrote:
>
> Yes, I agree, we need a better story for name mangling.
> My proposal is that we store a pretty name which matches the source
> (eg rust_binder::range_alloc) and a sha1 of the mangled symbol
> (40 bytes of uninteresting hex). Symbol
Hi David,
On Mon, Apr 19, 2021 at 10:01 PM David Sterba wrote:
>
> for simple functions it's barely parseable but the following is hardly
> readable
>
> translates to
>
>core[8787f43e282added]::fmt::Debug>::fmt
Some details can be omitted without much problem, e.g. try the `-i`
option of
On Mon, Apr 19, 2021 at 09:58:51PM +0200, David Sterba wrote:
> On Fri, Apr 16, 2021 at 07:34:51PM +0200, Miguel Ojeda wrote:
> > something like:
> >
> > [0.903456] rust_begin_unwind+0x9/0x10
> > [0.903456] ? _RNvNtCsbDqzXfLQacH_4core9panicking9panic_fmt+0x29/0x30
> > [0.903456] ?
On Fri, Apr 16, 2021 at 07:34:51PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
> >
> > So if I read all this right, rust compiles to .o and, like any other .o
> > file is then fed into objtool (for x86_64). Did you have any problems
> > with objtool? Does it
On Thu, Apr 15, 2021 at 9:43 AM Miguel Ojeda
wrote:
>
> On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
> wrote:
> >
> > Rather than check the origin (yikes, are we intentionally avoiding env
> > vars?), can this simply be
> > ifneq ($(CLIPPY),)
> > KBUILD_CLIPPY := $(CLIPPY)
> > endif
> >
>
On Sat, Apr 17, 2021 at 6:24 AM Willy Tarreau wrote:
>
> My concern was to know what field to look at to reliably detect an error
> from the C side after a sequence doing C -> Rust -> C when the inner C
> code uses NULL to mark an error and the upper C code uses NULL as a valid
> value and needs
On Sat, Apr 17, 2021 at 01:46:35AM +0200, Miguel Ojeda wrote:
> On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
> >
> > But my point remains that the point of extreme care is at the interface
> > with the rest of the kernel because there is a change of semantics
> > there.
> >
> > Sure but
On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
>
> But my point remains that the point of extreme care is at the interface
> with the rest of the kernel because there is a change of semantics
> there.
>
> Sure but as I said most often (due to API or ABI inheritance), both
> are already
On Sat, Apr 17, 2021 at 12:04:16AM +0200, Willy Tarreau wrote:
> Yep but I kept it just to have comparable output code since in C
> you'd simply use "goto leave" and not have this function call to
> do the cleanup.
... or use any number of other technics; the real question was how
much of
On Fri, Apr 16, 2021 at 11:39:00PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
> >
> > No, two:
> > - ok in %rax (seems like it's "!ok" technically speaking since it
> > returns 1 on !ok and 0 on ok)
> > - foo_or_err in %rdx
>
> Yes, but that is the
On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
>
> No, two:
> - ok in %rax (seems like it's "!ok" technically speaking since it
> returns 1 on !ok and 0 on ok)
> - foo_or_err in %rdx
Yes, but that is the implementation -- conceptually you only have one
or the other, and Rust won't
On Fri, Apr 16, 2021 at 10:22 PM Willy Tarreau wrote:
>
> So it simply does the equivalent of:
>
> struct result {
> int status;
> int error;
> };
Not exactly, it is more like a tagged union, as Connor mentioned.
However, and this is the critical bit: it is a compile-time error to
On Fri, Apr 16, 2021 at 03:34:50PM -0500, Connor Kuehl wrote:
> On 4/16/21 3:22 PM, Willy Tarreau wrote:
> > So it simply does the equivalent of:
> >
> > #define EINVAL -1234
> >
> > struct result {
> > int status;
> > int error;
> > };
>
> Result and Option types are more like
On 4/16/21 3:22 PM, Willy Tarreau wrote:
> So it simply does the equivalent of:
>
> #define EINVAL -1234
>
> struct result {
> int status;
> int error;
> };
Result and Option types are more like a union with a tag that
describes which variant it is.
struct foo_result {
/*
On Fri, Apr 16, 2021 at 08:57:07PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
> >
> > How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> > along the lines of "if argument matches Err(_), return Err(_)", the types
> > shouldn't be an
On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
>
> How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> along the lines of "if argument matches Err(_), return Err(_)", the types
> shouldn't be an issue, but that might need some fun with releasing resources,
> etc. If it's
On Fri, Apr 16, 2021 at 07:47:32PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
> wrote:
> >
> > Typical Rust error handling should match the regular kernel
> > IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> > fairly different (and it's not
On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
wrote:
>
> Typical Rust error handling should match the regular kernel
> IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> fairly different (and it's not limited to pointers).
Yeah, exactly. We already have a `KernelResult` type
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
>
> So if I read all this right, rust compiles to .o and, like any other .o
> file is then fed into objtool (for x86_64). Did you have any problems
> with objtool? Does it generate correct ORC unwind information?
I opened an issue a while ago
On Fri, Apr 16, 2021 at 6:38 AM Peter Zijlstra wrote:
>
> AFAICT rust has try/throw/catch exception handling (like
> C++/Java/others) which is typically implemented with stack unwinding of
> its own.
I was assuming that the kernel side would never do that.
There's some kind of "catch_unwind()"
On Wed, Apr 14, 2021 at 08:45:55PM +0200, oj...@kernel.org wrote:
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 1b6094a13034..3665c49c4dcf 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -26,6 +26,7 @@ EXTRA_CPPFLAGS :=
> EXTRA_LDFLAGS :=
>
On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers
wrote:
>
> Until then, I don't see why we need to permit developers to express
> such flexibility for just the Rust code, or have it differ from the
> intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and
> CC_OPTIMIZE_FOR_SIZE? I
On Wed, Apr 14, 2021 at 5:43 PM Miguel Ojeda
wrote:
>
> On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
> wrote:
> >
> > -Oz in clang typically generates larger kernel code than -Os; LLVM
> > seems to aggressively emit libcalls even when the setup for a call
> > would be larger than the inlined
On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
wrote:
>
> Rather than check the origin (yikes, are we intentionally avoiding env
> vars?), can this simply be
> ifneq ($(CLIPPY),)
> KBUILD_CLIPPY := $(CLIPPY)
> endif
>
> Then you can specify whatever value you want, support command line or
>
On Wed, Apr 14, 2021 at 11:48 AM wrote:
>
> From: Miguel Ojeda
>
> This commit includes also the `Kconfig` entries related to Rust,
> the Rust configuration printer, the target definition files,
> the version detection script and a few other bits.
>
> In the future, we will likely want to
25 matches
Mail list logo
