El vie, 19-10-2018 a las 12:12 +0200, Wolfgang Denk escribió:
> Dear Alexander,
>
> In message <118460556.a0Y5euKZZ7@ada> you wrote:
> > > 864 /*
> > > 865 * Keywords recognized.
> > > 866 */
> > > 867 static const struct token keywords[] = {
> > > 868 {"menu", T_MENU},
> > > 869 {"title", T_TITLE},
> > > 870 {"timeout", T_TIMEOUT},
> > > 871 {"default", T_DEFAULT},
> > > 872 {"prompt", T_PROMPT},
> > > 873 {"label", T_LABEL},
> > > 874 {"kernel", T_KERNEL},
> > > 875 {"linux", T_LINUX},
> > > 876 {"localboot", T_LOCALBOOT},
> > > 877 {"append", T_APPEND},
> > > 878 {"initrd", T_INITRD},
> > > 879 {"include", T_INCLUDE},
> > > 880 {"devicetree", T_FDT},
> > > 881 {"fdt", T_FDT},
> > > 882 {"devicetreedir", T_FDTDIR},
> > > 883 {"fdtdir", T_FDTDIR},
> > > 884 {"ontimeout", T_ONTIMEOUT,},
> > > 885 {"ipappend", T_IPAPPEND,},
> > > 886 {NULL, T_INVALID}
> > > 887 };
> > >
> > > This does not fit with your description, as you list:
> > > > Ignoring unknown command: title
> > > > Ignoring unknown command: version
> > > > Ignoring unknown command: options
> > > > Ignoring unknown command: linux
> > > > Ignoring unknown command: devicetree
> > >
> > > OK, "version" and "options" are not implemented, but the other
> > > keywords are, so you must be doing something else wrong.
> >
> > That's what I was saying. I suppose the handling of label and title
> > is
> > different, so the entry group I had below 'title' was not
> > recognized as group
> > of options for one entry, like it was when replacing title with
> > label. I can
> > write an actually working extlinux.conf file (as showed in my last
> > mail), but
> > that was not the question I had in the first place.
>
> Well, what confuses me here is that you cleanly show error messages
> for example for title, linux, and devicetree, even though these
> should be recognized as valid keywords.
>
> I think there are sublte imcompatibilities in your config file
> (and/or bugs in the code). See also this comment (same file):
>
> 440 * A note on the pxe file parser.
> 441 *
> 442 * We're parsing files that use syslinux grammar, which has a
> few quirks.
> 443 * String literals must be recognized based on context - there
> is no
> 444 * quoting or escaping support. There's also nothing to
> explicitly indicate
> 445 * when a label section completes. We deal with that by ending a
> label
> 446 * section whenever we see a line that doesn't include.
> 447 *
> 448 * As with the syslinux family, this same file format could be
> reused in the
> 449 * future for non pxe purposes. The only action it takes during
> parsing that
> 450 * would throw this off is handling of include files. It assumes
> we're using
> 451 * pxe, and does a tftp download of a file listed as an include
> file in the
> 452 * middle of the parsing operation. That could be handled by
> refactoring it to
> 453 * take a 'include file getter' function.
>
> > The U-Boot documentation in the file 'doc/README.distro' could lead
> > to the
> > impression as if U-Boot would support the BootLoaderSpec and even
> > links to it:
> > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> >
> > That spec says basically, in my own words: "put one conf file for
> > each boot
> > menu item in the directory /boot/loader/entries and let it have the
> > following
> > format."
> >
> > The keywords differ from the ones used by extlinux/U-Boot, in my
> > opinion the
> > U-Boot documentation in 'doc/README.distro' however is not very
> > clear about
> > that.
>
> I'm adding Dennis on Cc: who submitted the doc; I hope he has a
> better understanding of the state of things.
Sorry for the slow response, I have been travelling, currently u-boot
does not support the boot loader spec, it was a goal that no-one found
the time to solve, the main issue being how to we traverse the
directories to parse all the snippets.
> > Is U-Boot supposed to honour that Boot Loader Specification?
>
> I think it should, if possible.
>
> > If yes: then it does not work as specified. Is anybody working on
> > making U-
> > Boot comply?
>
> None that I know of.
There is no one working on it, I should remove the link to
BootLoaderSpec
> > If no: would anybody mind changing the documentation to better
> > reflect what U-
> > Boot actually does and not mislead people into thinking U-Boot
> > would be
> > compliant to that specification (like it was the case for me)? I
> > would send a
> > patch if nobody objects.
>
> Can we not do it the other way round, and fix the code that it
> improves and conforms (better) to the spec?
We could, I have not yet found a way to solve the problems. It would be
nice to solve them
Dennis
> Best regards,
>
> Wolfgang Denk
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
