[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transfering Data from GRUB to userspace?

From: Daniel Kiper
Subject: Re: Transfering Data from GRUB to userspace?
Date: Fri, 15 Nov 2019 13:42:49 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Nov 14, 2019 at 10:27:10AM +0000, Max Tottenham via Grub-devel wrote:
> On 10/28, Daniel Kiper wrote:
> > Hi Max,
> ...
> > Yeah, I think you are right. Additionally, please take a look at [1] and
> > especially at [2]. The series is about to commit and setup_indirect part

FYI, it is in tip:x86/boot right now and will land in 5.5.

> > can be very useful for you. And I would like to see similar feature in the
> > Multiboot2 protocol [3].
> So it looks to me like setup_data is linux specific, which is fine for
> me, but would mean that the BSDs wouldn't be able to take advantage of
> some more generic bootloader <-> userspace interface (like a file in a
> ramdisk).
> I suppose for adding support to [3] the idea would be to define a new
> generic boot information structure.
> Maybe something like:
> Generic 64bit data blob:
>     +----------------------------------------------------+
> u32 | type = 22                                          |
> u32 | size = 28                                          |
> u64 | data_load_addr = <paddr of loaded data>            |
> u64 | data_len = <length of loaded data>                 |
> u32 | data_type = <Some ENUM>                            |

Why do you need data_type?

>     +----------------------------------------------------+
> From reading the multiboot spec it doesn't sound like there is a
> requirement that the boot information data-structure have all it's
> associated structures be located in a contiguous region (unlike linux's
> setup_data).

Yes, there is no such requirement.

> I think given the different possible approaches, I'll come up with
> a formal API that could have several providers (setup_indirect v.s. initramfs
> files, v.s. multiboot boot information structs), and provide an
> implementation based on setup_indirect.
> I think something like:
> struct grub_boot_data_t;
> struct grub_boot_data_t {
>     grub_addr_t addr;
>     uint64_t len;
>     grub_uint32_t type;
>     struct grub_boot_data_t* next;
> };
> struct grub_boot_data_provider_t {
>  int (*supports) (void*);
>  int (*setup) (void*, grub_boot_data_t*);
>  struct grub_boot_data_provider_t *next;
> }
> struct grub_boot_data_t* addl_data_head;
> struct grub_boot_data_provider *boot_data_providers;
> grub_boot_data_setup(void* ctx)  {
>     for (p: boot_data_providers) {
>         if (p->supports(ctx))
>             p->setup(ctx, addl_data_head);
>     }
> }
> grub_boot_data_register_provider() {
> }
> Where each backend would register a 'boot_data_provider', ctx would
> contain either a pointer to the kernel setup header/multiboot header,
> supports() would indicate whether this backend supports the loader used in
> ctx, and setup() would perform the actual business of setting up the
> correct structures etc.

So, AIUI you want to have a self-contained "log" structure which can be
pointed from setup_indirect or Multiboot2. Am I right? If this is true
then I am OK with the idea. However, I would like to ask you to involve
other interested groups and people in further discussions, e.g. relevant
Linux maintainers, BSD maintainers and Xen maintainers (yes, Xen is using
Multiboot2). If you need some email addresses I can send you them.

> > Additionally, I think you can take a look at ACPI ERST and UEFI variables.
> > Both can be interesting for you and are used in Linux kernel by something
> > called pstore (in general "grep -Ir pstore Documentation" will show you
> > some interesting things, e.g. ramoops). Though this stuff is limited in 
> > size.
> I'm weary of this approach, at least in the UEFI case I'd be weary of
> writing to NVRAM backed EFI variables, as I'm pretty sure these NVRAM
> chips have pretty low write limits (1-10k write cycles) and are meant to
> be updated pretty infrequently.


> I wouldn't want to create an interface that developers might use
> thinking that it's fine to stick stuff in there on every boot, only to
> find out their NVRAM becomes a ROM after a couple of years.

I fully agree.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]