On Wed, Nov 06, 2019 at 09:08:41PM -0800, Vladimir 'phcoder' Serbinenko wrote:
> On Wed, 6 Nov 2019, 20:55 Michael Chang, wrote:
>
> > On Wed, Nov 06, 2019 at 11:15:04AM -0800, Vladimir 'phcoder' Serbinenko
> > wrote:
> > > Please don't do it this way. The right solution is to move it to
On Wed, Nov 06, 2019 at 01:40:30PM +0100, David Sterba wrote:
> On Tue, Nov 05, 2019 at 09:19:59AM +, Michael Chang wrote:
> > The zstd support in btrfs has dependenciy to zstd module and core.img
> > grows its size significantly to 75KB on my system. The resulted image
> > cannot be installed
On Thu, Nov 07, 2019 at 02:51:30AM +, Max Tottenham via Grub-devel wrote:
> On 11/06, Patrick Steinhardt wrote:
> > On Wed, Nov 06, 2019 at 02:57:52PM +, Max Tottenham wrote:
> > > I had one more comment about this patch which I forgot to send
> > > last time:
> > >
> > > +struct
On Wed, 6 Nov 2019, 20:55 Michael Chang, wrote:
> On Wed, Nov 06, 2019 at 11:15:04AM -0800, Vladimir 'phcoder' Serbinenko
> wrote:
> > Please don't do it this way. The right solution is to move it to separate
> > module and include zstd module when needed.
>
> I fully agree to work out a proper
On Wed, Nov 06, 2019 at 11:15:04AM -0800, Vladimir 'phcoder' Serbinenko wrote:
> Please don't do it this way. The right solution is to move it to separate
> module and include zstd module when needed.
I fully agree to work out a proper solution, but before that I think it
is necessary to stop it
On Tue, Nov 05, 2019 at 11:52:44AM +0100, Paul Menzel wrote:
> Dear Michael,
>
>
> Thank you for your patch.
>
> On 2019-11-05 10:19, Michael Chang wrote:
> > The zstd support in btrfs has dependenciy to zstd module and core.img
>
> dependency
OK. The typo will be corrected next version.
>
On 11/05, Patrick Steinhardt wrote:
> While the newly added jsmn library provides the parsing interface, it
> does not provide any kind of interface to act on parsed tokens. Instead,
> the caller is expected to handle pointer arithmetics inside of the token
> array in order to extract required
On 11/06, Patrick Steinhardt wrote:
> On Wed, Nov 06, 2019 at 02:57:52PM +, Max Tottenham wrote:
> > On 11/06, Daniel Kiper wrote:
> > > On Tue, Nov 05, 2019 at 02:12:13PM +0100, Patrick Steinhardt wrote:
> > > > On Tue, Nov 05, 2019 at 12:54:38PM +, Max Tottenham via Grub-devel
> > > >
On Wed, Nov 06, 2019 at 02:57:52PM +, Max Tottenham wrote:
> On 11/06, Daniel Kiper wrote:
> > On Tue, Nov 05, 2019 at 02:12:13PM +0100, Patrick Steinhardt wrote:
> > > On Tue, Nov 05, 2019 at 12:54:38PM +, Max Tottenham via Grub-devel
> > > wrote:
> > > > On 11/05, Patrick Steinhardt
Please don't do it this way. The right solution is to move it to separate
module and include zstd module when needed. Not everybody uses btrfs
embedded area. I recommend not to use it. Using mbr gap or BBP is the
recommended way.
On Tue, 5 Nov 2019, 01:25 Michael Chang, wrote:
> The zstd
> On Nov 6, 2019, at 4:40 AM, David Sterba wrote:
>
> On Tue, Nov 05, 2019 at 09:19:59AM +, Michael Chang wrote:
>> The zstd support in btrfs has dependenciy to zstd module and core.img
>> grows its size significantly to 75KB on my system. The resulted image
>> cannot be installed into
On 11/06, Daniel Kiper wrote:
> On Tue, Nov 05, 2019 at 02:12:13PM +0100, Patrick Steinhardt wrote:
> > On Tue, Nov 05, 2019 at 12:54:38PM +, Max Tottenham via Grub-devel
> > wrote:
> > > On 11/05, Patrick Steinhardt wrote:
> > > > +grub_err_t
> > > > +grub_json_parse (grub_json_t **out,
On 11/06, Daniel Kiper wrote:
> CC-ing Matthew...
>
> On Tue, Oct 29, 2019 at 01:12:34PM +0100, Javier Martinez Canillas wrote:
> > Hello Max,
> >
> > On 10/29/19 11:49 AM, Max Tottenham via Grub-devel wrote:
> > > On 10/25, Javier Martinez Canillas wrote:
> >
> > [snip]
> >
> > >>>
> > >>
> > >>
On Tue, Nov 05, 2019 at 07:58:39AM +0100, Patrick Steinhardt wrote:
> The luks module contains quite a lot of logic to parse cipher and
> cipher-mode strings like "aes-xts-plain64" into constants to apply them
> to the `grub_cryptodisk_t` structure. This code will be required by the
> upcoming
On Wed, Nov 06, 2019 at 12:44:58PM +0100, Daniel Kiper wrote:
> On Mon, Nov 04, 2019 at 07:56:48PM +0100, Patrick Steinhardt wrote:
> > On Mon, Nov 04, 2019 at 06:42:51PM +0100, Daniel Kiper wrote:
> > > On Mon, Nov 04, 2019 at 12:00:53PM +0100, Patrick Steinhardt wrote:
> > > > On Mon, Nov 04,
On Tue, Nov 05, 2019 at 07:58:38AM +0100, Patrick Steinhardt wrote:
> While the AFSplitter code is currently used only by the luks module,
> upcoming support for luks2 will add a second module that depends on it.
> To avoid any linker errors when adding the code to both modules because
> of
On Tue, Nov 05, 2019 at 07:58:37AM +0100, Patrick Steinhardt wrote:
> The upcoming support for LUKS2 disc encryption requires us to include a
> parser for base64-encoded data, as it is used to represent salts and
> digests. As gnulib already has code to decode such data, we can just
> add it to
On Tue, Nov 05, 2019 at 02:12:13PM +0100, Patrick Steinhardt wrote:
> On Tue, Nov 05, 2019 at 12:54:38PM +, Max Tottenham via Grub-devel wrote:
> > On 11/05, Patrick Steinhardt wrote:
> > > +grub_err_t
> > > +grub_json_parse (grub_json_t **out, const char *string, grub_size_t
> > >
On Mon, Nov 04, 2019 at 07:56:48PM +0100, Patrick Steinhardt wrote:
> On Mon, Nov 04, 2019 at 06:42:51PM +0100, Daniel Kiper wrote:
> > On Mon, Nov 04, 2019 at 12:00:53PM +0100, Patrick Steinhardt wrote:
> > > On Mon, Nov 04, 2019 at 10:26:21AM +, Max Tottenham wrote:
> > > > On 11/02, Patrick
CC-ing Matthew...
On Tue, Oct 29, 2019 at 01:12:34PM +0100, Javier Martinez Canillas wrote:
> Hello Max,
>
> On 10/29/19 11:49 AM, Max Tottenham via Grub-devel wrote:
> > On 10/25, Javier Martinez Canillas wrote:
>
> [snip]
>
> >>>
> >>
> >> I think that we should go even further and make all the
On Thu, Oct 31, 2019 at 01:05:09PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> Having // at the beginning of the path may have special meaning according
> to posix. I don't know if it applies in particular case and if the special
> meaning is useful for grub to begin with, just something to
21 matches
Mail list logo
