grub-devel
[Top][All Lists]
Advanced

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

Re: Transfering Data from GRUB to userspace?


From: Toomas Soome
Subject: Re: Transfering Data from GRUB to userspace?
Date: Thu, 14 Nov 2019 12:56:25 +0200


> On 14. Nov 2019, at 12:27, Max Tottenham via Grub-devel <address@hidden> 
> 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
>> 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).
> 


multiboot2 already does have modules mechanism, which is pretty generic because 
the identification can be done via module command line.

For example, for illumos we are providing boot loader environment variables as 
module (commandline) type=environment, console font as type=console-font and so 
on.

rgds,
toomas


> 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>                            |
>    +----------------------------------------------------+
> 
> 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).
> 
> 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.
> 
>> 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.
> 
>> 
>> Daniel
>> 
>> [1] https://lkml.org/lkml/2019/10/24/378
>> [2] https://lkml.org/lkml/2019/10/24/387
>> [3] https://www.gnu.org/software/grub/manual/multiboot2/
> 
> -- 
> Max Tottenham       | address@hidden
> Senior Software Engineer, Server Platform Engineering
> /(* Akamai Technologies
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel




reply via email to

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