Re: [PATCH v3 0/2] btrfs: Add zstd support to grub btrfs
> On Oct 10, 2018, at 12:34 AM, Paul Menzel wrote: > > Sorry for being ignorant, but you explain, why the library needs to be > imported and it is not enough to use that library as an external dependency? > > Importing the library means, it has to be maintained in the GRUB repository, > which will result in some maintenance burden. I've imported zstd because thats the way the rest of the decompressors are imported. We could potentially use libzstd as an external dependency, since its only dependency is libc and GRUB provides the definitions of the libc functions that zstd needs to decompress (memcpy, and memmove). Theres some other stuff in the library that requires libc functionality that GRUB doesn't provide, but that isn't used during decompression. We strip those files out in the import. Let me know if you want me to switch to an external dependency. Best, Nick ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] [PATCH v2 00/18] xen: add pvh guest support
On 09/10/2018 13:02, Juergen Gross wrote: > This patch series adds support for booting Linux as PVH guest. > > Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh > platform grub is booted as a standalone image directly by Xen. > > For booting Linux kernel it is using the standard linux kernel > loader. The only modification of the linux loader is to pass the > ACPI RSDP address via boot parameters to the kernel, as that table > might not be located at the usual physical address just below 1MB. > > As the related Linux kernel patches are not yet accepted please > wait for this to happen before applying the series. This Linux kernel > series is available under: > > https://lists.xen.org/archives/html/xen-devel/2018-10/msg00776.html The Linux kernel series is now available under: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/grub2 This means the series has been accepted and is kept pending until this grub2 series has been accepted. Juergen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 7/9] btrfs: Add support for recovery for a RAID 5 btrfs profiles.
On 09/10/2018 20.20, Daniel Kiper wrote:
> On Thu, Sep 27, 2018 at 08:35:02PM +0200, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli
>>
>> Add support for recovery for a RAID 5 btrfs profile. In addition
>> it is added some code as preparatory work for RAID 6 recovery code.
>>
>> Signed-off-by: Goffredo Baroncelli
>> ---
>> grub-core/fs/btrfs.c | 160 +--
>> 1 file changed, 155 insertions(+), 5 deletions(-)
>>
>> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
>> index 554f350c5..db8df0eea 100644
>> --- a/grub-core/fs/btrfs.c
>> +++ b/grub-core/fs/btrfs.c
>> @@ -29,6 +29,7 @@
[...]
>> +
>> + stripe = (struct grub_btrfs_chunk_stripe *) (chunk + 1) + i;
>
> I think that "chunk + 1" requires short comment why...
This is a quite common pattern (a struct followed by an array of struct).
However I added a short comment like
/* after the struct grub_btrfs_chunk_item, there is an array of
struct grub_btrfs_chunk_stripe */
stripe = (struct grub_btrfs_chunk_stripe *) (chunk + 1) + i;
[...]
>> -for (i = 0; i < redundancy; i++)
>> +if (!is_raid56)
>
> Why not "if (is_raid56)"? This looks more natural here.
I think that it was due to the fact than before it was only the not "raid5/6"
profiles.
Then it was added the "raid5/6" profiles, so I added this case after.
What I dislike is not the order, but the fact that in one case (not raid5), the
same function is called several time until it found valid data. In the other
case, it is called only the first time, then a completely different path is
called
I am trying a different solution, but in any case the result is a bit ugly
>
>> + for (i = 0; i < redundancy; i++)
>> +{
>> + err = btrfs_read_from_chunk (data, chunk, stripen,
>> + stripe_offset,
>> + i, /* redundancy */
>> + csize, buf);
>> + if (!err)
>> +break;
>> + grub_errno = GRUB_ERR_NONE;
>> +}
>> +else
>>{
>> err = btrfs_read_from_chunk (data, chunk, stripen,
>> stripe_offset,
>> - i, /* redundancy */
>> + 0, /* no mirror */
>> csize, buf);
>> -if (!err)
>> - break;
>> grub_errno = GRUB_ERR_NONE;
>> +if (err != GRUB_ERR_NONE)
>
> Please be consistent and use "if (err)" here.
ok
>
>> + err = raid56_read_retry (data, chunk, stripe_offset,
>> + csize, buf);
>>}
>> -if (i != redundancy)
>> +if (err == GRUB_ERR_NONE)
>
> if (!err) please...
ok
>
> Daniel
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/2] btrfs: Add zstd support to grub btrfs
Dear Nick,
Thank you very much for your patches.
Am 10.10.2018 um 01:21 schrieb Nick Terrell:
This patch set imports the upstream zstd library, adds zstd support to the
btrfs module, and adds a test case. I've also tested the patch set by storing
my boot partition in btrfs with and without zstd compression and rebooting.
The fist patch imports the files needed to support zstd decompression from
zstd-1.3.6 as-is. It is a very large patch. In case it doesn't make it,
I've included the commit hash and the script I used to download the files.
Upstream zstd commit hash: 4fa456d7f12f8b27bd3b2f5dfd4f46898cb31c24
Upstream zstd commit name: Merge pull request #1354 from facebook/dev
---
#!/bin/sh -e
curl -L -O
https://github.com/facebook/zstd/releases/download/v1.3.6/zstd-1.3.6.tar.gz
curl -L -O
https://github.com/facebook/zstd/releases/download/v1.3.6/zstd-1.3.6.tar.gz.sha256
sha256sum --check zstd-1.3.6.tar.gz.sha256
tar xzf zstd-1.3.6.tar.gz
SRC_LIB="zstd-1.3.6/lib"
DST_LIB="grub-core/lib/zstd"
rm -rf $DST_LIB
mkdir -p $DST_LIB
cp $SRC_LIB/zstd.h $DST_LIB/
cp $SRC_LIB/common/*.[hc] $DST_LIB/
cp $SRC_LIB/decompress/*.[hc] $DST_LIB/
rm $DST_LIB/{pool.[hc],threading.[hc]}
rm -rf zstd-1.3.6*
echo SUCCESS!
---
Sorry for being ignorant, but you explain, why the library needs to be
imported and it is not enough to use that library as an external dependency?
Importing the library means, it has to be maintained in the GRUB
repository, which will result in some maintenance burden.
Kind regards,
Paul
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
