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: Daniel Kiper
Subject: Re: Transfering Data from GRUB to userspace?
Date: Tue, 19 Nov 2019 13:47:57 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Nov 19, 2019 at 02:01:11AM +0000, Tottenham, Max via Grub-devel wrote:
> Original mail seems to have been eaten again, apologies if you already 
> received this.
>
> On 11/15, Daniel Kiper wrote:
> > On Thu, Nov 14, 2019 at 10:27:10AM +0000, Max Tottenham via Grub-devel 
> > wrote:
> > > On 10/28, Daniel Kiper wrote:
> > > > Hi Max,
> > >
> > > ...
> > > 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?
> >
> > >     +----------------------------------------------------+
>
> My initial thought was that it would be an easy way to create a
> 'generic' boot info struct where 'type' defines that it's a generic
> type, and 'data_type' is a separate type field that is interpreted by
> defined by the loaded OS, I suppose the alternative would be to declare

This is more or less what I expected. I do not want that because it will
make confusion and may encourage people to interpret data_type as they
want to without obeying the spec.

> separate boot info struct's for each purpose (so for my purpose a simple
> 'log' type struct would suffice).

I am OK with that. And this log may define various log types and formats
in own header.

> > 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.
>
> Correct.
>
> > 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.
> >
>
> I'd greatly appreciate it if you'd be able to send me over the relevant
> maintainers/mailing list addresses.

Will do.

Daniel



reply via email to

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