[PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####

[Ilias Apalodimas]

Hi Heinrich,

[...]
> >> No, the structure is added in cmd/efidebug.c code.
> >> It's created with efi_dp_append_instance() on
> >> - const struct efi_initrd_dp id_dp
> >> - file path of initrd
> >>
> >> which will create:
> >> kernel path,end(0xff),
> >> VenMedia(), end(0x01),
> 
> This end node is superfluous.

Why?i It's not defined in any standard (in fact these patches will be used for
the USWG proposal), it's making our lives a lot easier during parsing, since
you only need to get the next instance for the *entire* device path.
On the other hand if you mix and match them, you'll have to skip the first
entry with dp->len and then start using code to get the next instance. Similar
logic applies to appending the instance obviously. Since you now how have to
account for your 'special' first node, which isn't that special to begin with.

So why exactly is it superflous? Because you can get the next initrd without
having to parse an end of instace? Well that's the case for the initrd's as
well then .... 
On the contrary I think it makes the entire device path look more generic, 
since each node is separated by an end of instance, no matter what the
contents are.

Thanks
/Ilias

> 
> Best regards
> 
> Heinrich
> 
> >> initrd1, end(0x01),
> >> initrd2, end(0xff)
> >>
> >> I know I originally proposed the one you have, but it seemed cleaner
> >> adding
> >> an extra instance between VenMedia and the first initrd.
> >>
> >>>
> >>> Please, document the structure.
> >>>
> >>
> >> Sure
> >>
> >>> Best regards
> >>>
> >>> Heinrich
> >>
> >> Thanks
> >> /Ilias
> >
>