From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by mx.groups.io with SMTP id smtpd.web08.1846.1659382589008543359 for ; Mon, 01 Aug 2022 12:36:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=UbM7kw83; spf=pass (domain: gmail.com, ip: 209.85.210.170, mailfrom: ayushdevel1325@gmail.com) Received: by mail-pf1-f170.google.com with SMTP id d20so4125046pfq.5 for ; Mon, 01 Aug 2022 12:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc; bh=PO8hmY5UZJQRtNtB52EoF4rP0TSobKOb6voZ4KCVxrc=; b=UbM7kw83j+frEVlXyx+wTCzs6pIXTP/KiKy7shH/yyBxg2yD8Rw4fPb1tSQF/l0NJ4 UFSDuE9+RvzzH7m9EZyeqGXhhQ931APBqIKhlKXDcUvUcehXZ5Jk+Y9OHMUx3eee14NA Ou3eCdu3G23r26slyNN/M3H7YbMbolm28B1qhkASnSI7zuoT7a/b1SQ39KBlJU7I04zI JrNhuTT8YO2SLXVRez3B0SYtdnJqCWXeIEhJwtHr0aY9UtzVUjRLCe/80F8fNTWQOIS8 GSbS2n0oBU21bnw5y6+T9g0aAa+gArdjZQD3v/dR23kMY5qNc+V3XfggI6dUS+Z+mXUr YSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc; bh=PO8hmY5UZJQRtNtB52EoF4rP0TSobKOb6voZ4KCVxrc=; b=7OYJBZLGnKXrj1vrVja+0C4+VoNeC36d+N0FvfbfeIzZTJpcX+ZubMQqa2dKai1NCH ARvbB0tD+ZcUxQoFNx4L7ekagtMdKMfdTzstO6P3WSpkq8xtWX3DeM7blLHu/ly6itwP H5Re/4ce+j4MiKTU60e+xe03VFp1cOSGS6chXhlwU/Ls5kVmsiHdAlSYXrRSSK/MXO9u wrVX2d1f3PHxMr/pa36ltzM8V9qI9X5CV2UxoC/XGKYVJZWo/s+//pF0IRM6c8RsyZud dYctm4nIFBVwO26wou7dgpRBPDgSqjqHIBdiIe69t9xFEr5isOvIMIpoQkrvnc2ZSQUp MDnw== X-Gm-Message-State: AJIora8hh2g/Bara/0S1fneTXLrqUKolt3i84DdoprTs6NkLXpmX1F6U IGaGbECPCRkWVwBfSD5uxDY= X-Google-Smtp-Source: AGRyM1trWeJnBLQP1QAbWoiuxNZDbla8GUWpRjgKOXc83mlZ3Y+2FVJzFq7iRHEJePev83i184sutg== X-Received: by 2002:a05:6a00:14c1:b0:52b:4602:5af1 with SMTP id w1-20020a056a0014c100b0052b46025af1mr17160242pfu.24.1659382588309; Mon, 01 Aug 2022 12:36:28 -0700 (PDT) Return-Path: Received: from ?IPV6:2401:4900:1f3e:17ce:2380:94ae:b852:be4? ([2401:4900:1f3e:17ce:2380:94ae:b852:be4]) by smtp.gmail.com with ESMTPSA id a142-20020a621a94000000b00528c22fbb45sm4027778pfa.141.2022.08.01.12.36.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Aug 2022 12:36:27 -0700 (PDT) Message-ID: Date: Tue, 2 Aug 2022 01:06:23 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [edk2-devel] Proposal to move Rust std work to a Repository under Tianocore To: Pedro Falcato Cc: edk2-devel-groups-io , "Kinney, Michael D" , Michael Kubacki , "Yao, Jiewen" , "Gaibusab, Jabeena B" References: <33ac1f75-d6c9-2093-8701-698a3e553d64@gmail.com> <25b8fe0b-12ae-8c51-5e3b-6397a727c863@gmail.com> From: "Ayush Singh" In-Reply-To: Content-Type: multipart/alternative; boundary="------------VwCVj00jQJZ7sf7nNCmh10iW" Content-Language: en-US --------------VwCVj00jQJZ7sf7nNCmh10iW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Well, testing without std is quite difficult (`uefi-rs` does have some support for it). For the bare targets of Linux, they simply use the std linux targets for testing and that works fine. Not so much for a bare target without an std counterpart. Also, Rust for Linux project is a bit of a special case. There is only 1 main Linux Kernel and that's all. This essentially means u can create all the Rust tooling in the Kernel, and then all the crates for the Kernel development can depend on those modules/drivers in the Kernel. Essentially, the Kernel here acts as the standard library itself. UEFI is a specification that can have many implementations. There is no single source of truth for all UEFI crates/modules to depend on. This means, any crate/application you want to create for UEFI (not just edk2), will have to start from scratch without anything to base on. It might be possible to extract the allocator and other stuff from the std so that they can be used without std, but that's not really the goal right now. Ayush Singh On 8/2/22 00:36, Pedro Falcato wrote: > Right. I had no idea that you were going to go for std support in your > project. This makes me like your project much less. I thought you were > going to go the way of linux, where they do not use std but rather > custom stuff that fits well with the rest of the kernel. I very much > do not think that a whole standard library (especially a full-fledged > one like Rust's) is useful, or fits well, or is even usable in this > context; this is why no one that is working on firmware or a kernel > uses your userspace's libc, C++ standard library or rust's std. I can > see how std can be useful when trying to run standalone EFI apps, but > the security critical code is the rest of EFI, which needs to fit the > EDK2 system and sometimes run in awkward contexts like runtime > services, SMM, etc. > > Is there no chance to upstream build integration and some basic > wrappers around existing code? > > On Mon, Aug 1, 2022 at 6:39 PM Ayush Singh > wrote: > > Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support > for no_std Rust has been present upstream for a few years. > However, as you might be able to guess, bare Rust without any > allocation and use of external crates simply did not provide > enough benefits over C to migrate older projects to it. > Additionally, without std, it's difficult to do enough significant > testing to generate enough confidence in a new language like this. > > Also to clarify, using Rust std in an application does not mean > the whole std will be bundled with the application. Only the parts > of std that are actually used by the application will be bundled > in the final binary. > > You can find more information about what is already present in > upstream Rust for UEFI here: > https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html > > There is also some talks about promoting UEFI target to Tier-2, > and having an std implementation will certainly help with that. > > > Yours Sincerely. > > Ayush Singh > > > On 8/1/22 22:56, Pedro Falcato wrote: >> Hi, >> >> May I suggest you just port the bare rust language (no crates, no >> std) to EDK2? It seems far more plausible to expect people to use >> a cut down version with some bindings to the rest of the project >> instead of hoping people just use the whole of rust, a lot of >> which isnt proven (or even used AFAIK) in bare metal projects. >> Porting just the bare minimum is way more realistic in my opinion. >> >> Thanks, >> Pedro >> >> On Mon, 1 Aug 2022, 18:02 Ayush Singh, >> wrote: >> >> Hello everyone. In the previous email thread [1], I discussed >> the >> proposal to move Rust std work to edk2-staging and mentioned its >> potential problems. After some discussion with mentors, we >> arrived at >> the conclusion to have a rustlang [2] fork under the Tianocore >> organization, and move all the std related work there. We can >> then open >> a PR upstream from there, while allowing PRs in this >> repository. This >> should help provide an easier and streamlined way for people to >> experiment and work on this project while it is in the >> process of being >> merged upstream. >> >> >> For a status update about tests: >> >> - passed: 12797 >> >> - failed: 40 >> >> - ignored: 375 >> >> >> Yours Sincerely, >> >> Ayush Singh >> >> >> [1]: https://edk2.groups.io/g/devel/message/91989 >> >> [2]: https://github.com/rust-lang/rust >> >> >> >> >> >> > > > -- > Pedro Falcato --------------VwCVj00jQJZ7sf7nNCmh10iW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Well, testing without std is quite difficult (`uefi-rs` does have some support for it). For the bare targets of Linux, they simply use the std linux targets for testing and that works fine. Not so much for a bare target without an std counterpart.

Also, Rust for Linux project is a bit of a special case. There is only 1 main Linux Kernel and that's all. This essentially means u can create all the Rust tooling in the Kernel, and then all the crates for the Kernel development can depend on those modules/drivers in the Kernel. Essentially, the Kernel here acts as the standard library itself.

UEFI is a specification that can have many implementations. There is no single source of truth for all UEFI crates/modules to depend on. This means, any crate/application you want to create for UEFI (not just edk2), will have to start from scratch without anything to base on.

It might be possible to extract the allocator and other stuff from the std so that they can be used without std, but that's not really the goal right now.


Ayush Singh


On 8/2/22 00:36, Pedro Falcato wrote:
Right. I had no idea that you were going to go for std support in your project. This makes me like your project much less. I thought you were going to go the way of linux, where they do not use std but rather custom stuff that fits well with the rest of the kernel. I very much do not think that a whole standard library (especially a full-fledged one like Rust's) is useful, or fits well, or is even usable in this context; this is why no one that is working on firmware or a kernel uses your userspace's libc, C++ standard library or rust's std. I can see how std can be useful when trying to run standalone EFI apps, but the security critical code is the rest of EFI, which needs to fit the EDK2 system and sometimes run in awkward contexts like runtime services, SMM, etc.

Is there no chance to upstream build integration and some basic wrappers around existing code?

On Mon, Aug 1, 2022 at 6:39 PM Ayush Singh <ayushdevel1325@gmail.com> wrote:

Hi Pedro. Bare Rust already works in UEFI. In fact, UEFI support for no_std Rust has been present upstream for a few years. However, as you might be able to guess, bare Rust without any allocation and use of external crates simply did not provide enough benefits over C to migrate older projects to it. Additionally, without std, it's difficult to do enough significant testing to generate enough confidence in a new language like this.

Also to clarify, using Rust std in an application does not mean the whole std will be bundled with the application. Only the parts of std that are actually used by the application will be bundled in the final binary.

You can find more information about what is already present in upstream Rust for UEFI here: https://doc.rust-lang.org/nightly/rustc/platform-support/unknown-uefi.html

There is also some talks about promoting UEFI target to Tier-2, and having an std implementation will certainly help with that.


Yours Sincerely.

Ayush Singh


On 8/1/22 22:56, Pedro Falcato wrote:
Hi,

May I suggest you just port the bare rust language (no crates, no std) to EDK2? It seems far more plausible to expect people to use a cut down version with some bindings to the rest of the project instead of hoping people just use the whole of rust, a lot of which isnt proven (or even used AFAIK) in bare metal projects. Porting just the bare minimum is way more realistic in my opinion.

Thanks,
Pedro

On Mon, 1 Aug 2022, 18:02 Ayush Singh, <ayushdevel1325@gmail.com> wrote:
Hello everyone. In the previous email thread [1], I discussed the
proposal to move Rust std work to edk2-staging and mentioned its
potential problems. After some discussion with mentors, we arrived at
the conclusion to have a rustlang [2] fork under the Tianocore
organization, and move all the std related work there. We can then open
a PR upstream from there, while allowing PRs in this repository. This
should help provide an easier and streamlined way for people to
experiment and work on this project while it is in the process of being
merged upstream.


For a status update about tests:

- passed: 12797

- failed: 40

- ignored: 375


Yours Sincerely,

Ayush Singh


[1]: https://edk2.groups.io/g/devel/message/91989

[2]: https://github.com/rust-lang/rust








--
Pedro Falcato
--------------VwCVj00jQJZ7sf7nNCmh10iW--