[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry [and 1 more messages]



Steven Haigh writes ("Re: [Xen-devel] [PATCH] read grubenv and set default from 
saved_entry or next_entry"):
> Just wanted to give this a quick followup... Did this end up 
> progressing?

Hi.  I'm a tools maintainer and probably your best bet for a review
etc of this patch.  If, next time, you use add_maintainers.pl or
something, you'll end up CCing the maintainer and your mail won't get
dropped.  Anyway, thanks for chasing it up through a back channel :-).

Michael Young <m.a.young@xxxxxxxxxxxx>:
> From 51a9dce9de3ea159011928e2db8541f3c7e8383a Mon Sep 17 00:00:00 2001
> From: Michael Young <m.a.young@xxxxxxxxxxxx>
> Date: Thu, 15 Aug 2019 19:55:30 +0100
> Subject: [PATCH] read grubenv and set default from saved_entry or next_entry
> 
> This patch looks for a grubenv file in the same directory as the
> grub.cfg file and includes it at front of the grub.cfg file when passed
> to parse()

Thanks for the contribution.  I reviewed the patch and I have some
comments.

I think this patch would be less confusing if it were two patches.
One which does the saved/next entry, and one which reads grubenv.  Do
you think that would make sense ?  If so I would appreciate it if you
would split it up (and write a nice explanatory commit message about
the saved_entry stuff).

> As the grubenv file consists of variable=value lines padded by hashes these
> are treated as commands in parse() where it uses the value of saved_entry
> or next_entry (if set) to set the default entry if a title matches or is
> a number.

I like reusing the parser.

> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> index ce7ab0eb8c..267788795b 100755
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -454,8 +454,19 @@ class Grub:
>          if self.__dict__.get('cf', None) is None:
>              raise RuntimeError("couldn't find bootloader config file in the 
> image provided.")
>          f = fs.open_file(self.cf.filename)
> +        fenv = self.cf.filename.replace("grub.cfg","grubenv")

I find this filename hackery rather unprincipled.  I'm not entirely
sure I can see a better way, given the way cfg_list is constructed.
Can you think of a less hacky approach ?

What would happen in future if we provided a way to control the
grub.cfg read by pygrub and a user configured it to (say)
`grub.cfg.old' ?  Would we really want it to read `grubenv.old' ?

> +        if fenv != self.cf.filename and fs.file_exists(fenv):
> +            # if grubenv file exists next to grub.cfg prepend it
> +            fenvf = fs.open_file(fenv)
> +            if sys.version_info[0] < 3:
> +                fsep = "\n"
> +            else:
> +                fsep = b"\n"
> +            buf = fsep.join((fenvf.read(FS_READ_MAX),f.read(FS_READ_MAX)))
> +            del fenvf
>          # limit read size to avoid pathological cases
> -        buf = f.read(FS_READ_MAX)
> +        else:
> +            buf = f.read(FS_READ_MAX)
>          del f
>          if sys.version_info[0] < 3:
>              self.cf.parse(buf)

Can we instead make the parser take a list ?  This business of
constructing a concatenated string is not very nice.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.