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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
