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 separate boot info struct's for each purpose (so for my purpose a simple 'log' type struct would suffice). > > 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. Thanks! -- Max Tottenham | mtott...@akamai.com Senior Software Engineer, Server Platform Engineering /(* Akamai Technologies _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
