public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ayush Singh" <ayushdevel1325@gmail.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
	Michael Kubacki <mikuback@linux.microsoft.com>,
	 michael.d.kinney@intel.com, jabeena.b.gaibusab@intel.com,
	 Jiewen Yao <jiewen.yao@intel.com>
Subject: Discussing how SystemTable and its Pointers should be treated in Rust
Date: Tue, 21 Jun 2022 11:34:42 +0530	[thread overview]
Message-ID: <CA+Yfj7tm8-1omF20eXznHG0b43vagw1VgyWAvpsTn4SZQKfZ-w@mail.gmail.com> (raw)

Hello everyone,

I wanted to discuss and get ideas about how I should implement the
various services (like allocator and stdin) for UEFI in Rust. I have
come up with two approaches:

1. Initialize the pointers needed for a module to work early on and
keep them local to the module. This will mean that the allocator
module will store the `allocate_pool` and `free_pool` pointers in a
static private to the module which will be initialized by the std
before the Rust main is run.

2. Only have one global pointer to the SystemTable and pass that to
the functions (like allocate and deallocate) when needed.

I am leaning more towards the first approach right now since it would
mean that we will only need to assert that the local pointer is valid.
However, the 1st approach is a NOGO if it is possible that the
pointers in SysteTable can be changed by UEFI.

By change, I mean that for example the `allocate_pool` pointer in
SystemTable is replaced with a different pointer midway through the
program. In that case, the pointer in the allocator module will become
invalid but the SystemTable will contain the pointer to the new
location of `allocate_pool` and stay valid.

Yours Sincerely,
Ayush Singh

             reply	other threads:[~2022-06-21  6:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21  6:04 Ayush Singh [this message]
2022-06-21  7:28 ` [edk2-devel] Discussing how SystemTable and its Pointers should be treated in Rust Michael Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+Yfj7tm8-1omF20eXznHG0b43vagw1VgyWAvpsTn4SZQKfZ-w@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox