grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v6 6/6] disk: Implement support for LUKS2


From: Daniel Kiper
Subject: Re: [PATCH v6 6/6] disk: Implement support for LUKS2
Date: Mon, 16 Dec 2019 14:15:20 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Dec 16, 2019 at 02:10:55PM +0100, Patrick Steinhardt wrote:
> On Mon, Dec 16, 2019 at 02:05:00PM +0100, Daniel Kiper wrote:
> > On Mon, Dec 16, 2019 at 01:37:33PM +0100, Patrick Steinhardt wrote:
> > > On Mon, Dec 16, 2019 at 01:25:01PM +0100, Daniel Kiper wrote:
> > > > On Tue, Dec 10, 2019 at 10:26:21AM +0100, Patrick Steinhardt wrote:
> > > [snip]
> > > > > +  /* Get the passphrase from the user. */
> > > > > +  if (disk->partition)
> > > > > +    part = grub_partition_get_name (disk->partition);
> > > > > +  grub_printf_ (N_("Enter passphrase for %s%s%s (%s): "), disk->name,
> > > > > +             disk->partition ? "," : "", part ? : "",
> > > > > +             crypt->uuid);
> > > >
> > > > Why do you use grub_printf() instead of grub_printf()?
> > >
> > > I guess you mean grub_printf_() instead of grub_printf(). The
> >
> > Err... Right...
> >
> > > answer to that is simple: I copied it from "luks.c", and I saw it
> > > being used in various other modules for output that is
> > > user-facing and should thus be translated. Is there are more
> > > modern alternative that should be used instead? If so then I'm
> > > happy to use it instead.
> >
> > I am not sure about this underscore at the end. And there is no good
> > explanation around grub_printf_() and grub_printf() why they are both
> > different. So, if you copied this from "luks.c" let's leave it as is
> > for time being.
> >
> > Anyway, if there are no objections I will push this patch series by the
> > end of this week.
> >
> > Thank you for doing the work!
> >
> > Daniel
>
> Cool, great news. Thanks a lot for your reviews!

You are welcome!

> When this is merged I plan to tackle Argon2 support to make this
> more useful in the future. I guess we need support for this in

That would be nice.

> libgcrypt first, though, so it will probably take some more time.

Sure thing. If you could update libgcrypt to latest and greatest by the
way that would be perfect.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]