Re: [PATCH 1/4] Add new "version" command
On Wed, Mar 28, Hans de Goede wrote:
> + grub_printf ("%s, build %s %s\n", PACKAGE_STRING, __DATE__, __TIME__);
NACK.
Debian sells something what they call "reproducible build". Check their
website why usage of __DATE__ and __TIME__ is a bad thing.
SUSE does not want to republish an otherwise unchanged grub2 package
just because there was a need to rebuild the package.
Olaf
signature.asc
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/4] Add new "version" command
Hi,
Hans de Goede wrote:
> > + grub_printf ("%s, build %s %s\n", PACKAGE_STRING, __DATE__, __TIME__);
Olaf Hering wrote:
> Debian sells something what they call "reproducible build".
It's not actually a Debian thing, although some Debian Developers seem to
have initiated it and urge people to make binary production deterministic
and reproducible.
https://reproducible-builds.org/
> Check their website why usage of __DATE__ and __TIME__ is a bad thing.
They offer a solution for the problem of timestamps by the definition
of an environment variable SOURCE_DATE_EPOCH, which shall override the
current time.
https://reproducible-builds.org/docs/timestamps/
In the libraries underneath xorriso i based all timestamps and pseudo-random
data fields on this user-set timestamp, if it is present.
So if you set the variable SOURCE_DATE_EPOCH to the same value before runs
of grub-mkrescue, and if all GRUB tools underneath grub-mkrescue build
reproducible binaries and xorriso options, and if the other input files
are still the same (*), then the resulting ISO images of two runs will be
identical. (Needs xorriso-1.4.6 or younger.)
(*) Some attributes of input files do not matter in this case.
A good tar copy of the input tree should be sufficiently similar.
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote:
> A GPU inserted into a PCIe I/O slot disappears during system startup.
> The problem centers around GRUB and a specific VGA init function in
> efi_uga.c. This causes an LER (link error recorvery) because the MMIO
> memory has not been enabled before attempting access.
>
> The fix is to add the same coding used in other VGA drivers, specifically
> to add a check to insure that it is indeed a VGA controller. And then
> enable the MMIO address space with the specific bits.
>
> Signed-off-by: Mike Travis
> Reviewed-by: Michael Chang
> Reviewed-by: Daniel Kiper
Well, please do not add somebody RB tag if he/she did not explicitly
asked you to do that. And even in that case I was not able to look at
this patch in advance. So, my RB should not be here. Additionally, in
this situation I would like to ask if Michael approved his RB?
Anyway, patch LGTM except one nitpick. I will apply the patch, in a week or
so, with Michael's RB if I get confirmation that he approved it earlier.
> ---
> v1:change class to subclass, remove parens around "enable mem" code
> ---
> grub-2.02/grub-core/video/efi_uga.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> Index: grub-2.02/grub-core/video/efi_uga.c
> ===
> --- grub-2.02.orig/grub-core/video/efi_uga.c
> +++ grub-2.02/grub-core/video/efi_uga.c
> @@ -95,9 +95,18 @@ find_card (grub_pci_device_t dev, grub_p
> {
>struct find_framebuf_ctx *ctx = data;
>grub_pci_address_t addr;
> + grub_pci_address_t rcaddr;
This line should be together with the addr. I will fix it before
committing the patch.
Thank you for doing the work.
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
On Thu, Mar 29, 2018 at 11:02:51AM +0200, Daniel Kiper wrote:
> On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote:
> > A GPU inserted into a PCIe I/O slot disappears during system startup.
> > The problem centers around GRUB and a specific VGA init function in
> > efi_uga.c. This causes an LER (link error recorvery) because the MMIO
> > memory has not been enabled before attempting access.
> >
> > The fix is to add the same coding used in other VGA drivers, specifically
> > to add a check to insure that it is indeed a VGA controller. And then
> > enable the MMIO address space with the specific bits.
> >
> > Signed-off-by: Mike Travis
> > Reviewed-by: Michael Chang
> > Reviewed-by: Daniel Kiper
>
> Well, please do not add somebody RB tag if he/she did not explicitly
> asked you to do that. And even in that case I was not able to look at
> this patch in advance. So, my RB should not be here. Additionally, in
> this situation I would like to ask if Michael approved his RB?
We did have discussion about the patch before it was submitted upstream but I
did not ask for RB as well.
>
> Anyway, patch LGTM except one nitpick. I will apply the patch, in a week or
> so, with Michael's RB if I get confirmation that he approved it earlier.
As I did not ask for it, it has to be removed.
Thanks for notifying this.
Michael
>
> > ---
> > v1:change class to subclass, remove parens around "enable mem" code
> > ---
> > grub-2.02/grub-core/video/efi_uga.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > Index: grub-2.02/grub-core/video/efi_uga.c
> > ===
> > --- grub-2.02.orig/grub-core/video/efi_uga.c
> > +++ grub-2.02/grub-core/video/efi_uga.c
> > @@ -95,9 +95,18 @@ find_card (grub_pci_device_t dev, grub_p
> > {
> >struct find_framebuf_ctx *ctx = data;
> >grub_pci_address_t addr;
> > + grub_pci_address_t rcaddr;
>
> This line should be together with the addr. I will fix it before
> committing the patch.
>
> Thank you for doing the work.
>
> Daniel
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
On Thu, Mar 29, 2018 at 05:29:01PM +0800, Michael Chang wrote: > On Thu, Mar 29, 2018 at 11:02:51AM +0200, Daniel Kiper wrote: > > On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote: > > > A GPU inserted into a PCIe I/O slot disappears during system startup. > > > The problem centers around GRUB and a specific VGA init function in > > > efi_uga.c. This causes an LER (link error recorvery) because the MMIO > > > memory has not been enabled before attempting access. > > > > > > The fix is to add the same coding used in other VGA drivers, specifically > > > to add a check to insure that it is indeed a VGA controller. And then > > > enable the MMIO address space with the specific bits. > > > > > > Signed-off-by: Mike Travis > > > Reviewed-by: Michael Chang > > > Reviewed-by: Daniel Kiper > > > > Well, please do not add somebody RB tag if he/she did not explicitly > > asked you to do that. And even in that case I was not able to look at > > this patch in advance. So, my RB should not be here. Additionally, in > > this situation I would like to ask if Michael approved his RB? > > We did have discussion about the patch before it was submitted upstream but I > did not ask for RB as well. > > > Anyway, patch LGTM except one nitpick. I will apply the patch, in a week or > > so, with Michael's RB if I get confirmation that he approved it earlier. > > As I did not ask for it, it has to be removed. OK, I will commit this patch without your RB. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Multiboot ELF segment handling patch
Hello,
our project uses various (micro)kernels booted via GRUB2 using the
Multiboot & Multiboot2 protocol. Some of the kernels have several ELF
segments which are not necessarily placed close together.
When booting such kernels with GRUB2 in BIOS legacy mode we observed
that the screen shows colored blinking scrambled output, until the
graphic drivers takes over. (Looks very fancy, but our customers don't
like it ;-) ). We could track down the issue and have a fix for GRUB2,
which is attached.
Can you please have a look and check regarding what should/could be
changed to get it upstream? We did not test the dynamic relocation part,
since we have no such (kernel) setup. Thanks in advance.
Regards,
Alex.
--
Alexander Boettcher
Genode Labs
http://www.genode-labs.com - http://www.genode.org -
https://github.com/genodelabs/genode
Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
From 605ca41045f97f92fb698ea49d7267e1cb29f40c Mon Sep 17 00:00:00 2001
From: Alexander Boettcher
Date: Tue, 20 Mar 2018 09:21:06 +0100
Subject: [PATCH] multiboot: use per segment a separate relocator chunk
If the segments are not dense packed, the original code set up a huge
relocator chunk comprising all segments.
During the final relocation in grub_relocator_prepare_relocs, the chunk
is moved to its desired place and overrides memory which are actually not
covered/touched by the specified segments.
The overridden memory may contain reserved memory
(vga text mode, acpi tables e.g.), which leads to strange boot behaviour.
---
grub-core/loader/multiboot_elfxx.c | 59 +++---
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/grub-core/loader/multiboot_elfxx.c b/grub-core/loader/multiboot_elfxx.c
index 67daf59..0d10c64 100644
--- a/grub-core/loader/multiboot_elfxx.c
+++ b/grub-core/loader/multiboot_elfxx.c
@@ -57,7 +57,7 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
char *phdr_base;
grub_err_t err;
grub_relocator_chunk_t ch;
- grub_uint32_t load_offset, load_size;
+ grub_uint32_t load_size;
int i;
void *source;
@@ -99,29 +99,6 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
load_size = highest_load - mld->link_base_addr;
- if (mld->relocatable)
-{
- if (load_size > mld->max_addr || mld->min_addr > mld->max_addr - load_size)
- return grub_error (GRUB_ERR_BAD_OS, "invalid min/max address and/or load size");
-
- err = grub_relocator_alloc_chunk_align (GRUB_MULTIBOOT (relocator), &ch,
- mld->min_addr, mld->max_addr - load_size,
- load_size, mld->align ? mld->align : 1,
- mld->preference, mld->avoid_efi_boot_services);
-}
- else
-err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT (relocator), &ch,
- mld->link_base_addr, load_size);
-
- if (err)
-{
- grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
- return err;
-}
-
- mld->load_base_addr = get_physical_target_address (ch);
- source = get_virtual_current_address (ch);
-
grub_dprintf ("multiboot_loader", "link_base_addr=0x%x, load_base_addr=0x%x, "
"load_size=0x%x, relocatable=%d\n", mld->link_base_addr,
mld->load_base_addr, load_size, mld->relocatable);
@@ -133,21 +110,44 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
/* Load every loadable segment in memory. */
for (i = 0; i < ehdr->e_phnum; i++)
{
- if (phdr(i)->p_type == PT_LOAD)
+ if (phdr(i)->p_type != PT_LOAD)
+continue;
+
+ if (mld->relocatable)
{
+ if (load_size > mld->max_addr || mld->min_addr > mld->max_addr - load_size)
+return grub_error (GRUB_ERR_BAD_OS, "invalid min/max address and/or load size");
+
+ err = grub_relocator_alloc_chunk_align (GRUB_MULTIBOOT (relocator), &ch,
+ mld->min_addr, mld->max_addr - load_size,
+ phdr(i)->p_memsz, mld->align ? mld->align : 1,
+ mld->preference, mld->avoid_efi_boot_services);
+} else {
+ err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT (relocator), &ch,
+ phdr(i)->p_paddr, phdr(i)->p_memsz);
+}
+
+ if (err)
+{
+ grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
+ return err;
+}
+
+ if (mld->load_base_addr > get_physical_target_address (ch))
+mld->load_base_addr = get_physical_target_address (ch);
+
+ source = get_virtual_current_address (ch);
grub_dprintf ("multiboot_loader", "segment %d: paddr=0x%lx, memsz=0x%lx, vaddr=0x%lx\n",
i, (long) phdr(i)->p_paddr, (long) phdr(i)->p_memsz, (long) phdr(i)->p_vaddr);
- load_offset = phdr(i)->p_paddr - mld->link_base_addr;
-
if (phdr(i)->p_file
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
On 3/29/2018 2:36 AM, Daniel Kiper wrote: On Thu, Mar 29, 2018 at 05:29:01PM +0800, Michael Chang wrote: On Thu, Mar 29, 2018 at 11:02:51AM +0200, Daniel Kiper wrote: On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote: A GPU inserted into a PCIe I/O slot disappears during system startup. The problem centers around GRUB and a specific VGA init function in efi_uga.c. This causes an LER (link error recorvery) because the MMIO memory has not been enabled before attempting access. The fix is to add the same coding used in other VGA drivers, specifically to add a check to insure that it is indeed a VGA controller. And then enable the MMIO address space with the specific bits. Signed-off-by: Mike Travis Reviewed-by: Michael Chang Reviewed-by: Daniel Kiper Well, please do not add somebody RB tag if he/she did not explicitly asked you to do that. And even in that case I was not able to look at this patch in advance. So, my RB should not be here. Additionally, in this situation I would like to ask if Michael approved his RB? We did have discussion about the patch before it was submitted upstream but I did not ask for RB as well. Anyway, patch LGTM except one nitpick. I will apply the patch, in a week or so, with Michael's RB if I get confirmation that he approved it earlier. As I did not ask for it, it has to be removed. OK, I will commit this patch without your RB. Daniel Sorry, I was not aware of this custom. I thought that if someone reviewed the code then that was an indication that it should be noted. I am aware of the more restrictive Acked-by which is normally sent by the "acker" to the submitter. I will be more mindful of this in the future. (This is my first posting to any of the GNU mail lists). Thanks, Mike ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/4] Add new "version" command
Hi,
On 29-03-18 09:53, Olaf Hering wrote:
On Wed, Mar 28, Hans de Goede wrote:
+ grub_printf ("%s, build %s %s\n", PACKAGE_STRING, __DATE__, __TIME__);
NACK.
Debian sells something what they call "reproducible build". Check their
website why usage of __DATE__ and __TIME__ is a bad thing.
SUSE does not want to republish an otherwise unchanged grub2 package
just because there was a need to rebuild the package.
Good point, lets drop this patch then, as without the date
I don't think there is much value in it and I don't feel
like spending time on this to come up with another solution.
Regards,
Hans
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
Hi, On 29-03-18 16:27, Mike Travis wrote: On 3/29/2018 2:36 AM, Daniel Kiper wrote: On Thu, Mar 29, 2018 at 05:29:01PM +0800, Michael Chang wrote: On Thu, Mar 29, 2018 at 11:02:51AM +0200, Daniel Kiper wrote: On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote: A GPU inserted into a PCIe I/O slot disappears during system startup. The problem centers around GRUB and a specific VGA init function in efi_uga.c. This causes an LER (link error recorvery) because the MMIO memory has not been enabled before attempting access. The fix is to add the same coding used in other VGA drivers, specifically to add a check to insure that it is indeed a VGA controller. And then enable the MMIO address space with the specific bits. Signed-off-by: Mike Travis Reviewed-by: Michael Chang Reviewed-by: Daniel Kiper Well, please do not add somebody RB tag if he/she did not explicitly asked you to do that. And even in that case I was not able to look at this patch in advance. So, my RB should not be here. Additionally, in this situation I would like to ask if Michael approved his RB? We did have discussion about the patch before it was submitted upstream but I did not ask for RB as well. Anyway, patch LGTM except one nitpick. I will apply the patch, in a week or so, with Michael's RB if I get confirmation that he approved it earlier. As I did not ask for it, it has to be removed. OK, I will commit this patch without your RB. Daniel Sorry, I was not aware of this custom. I thought that if someone reviewed the code then that was an indication that it should be noted. I am aware of the more restrictive Acked-by which is normally sent by the "acker" to the submitter. I will be more mindful of this in the future. (This is my first posting to any of the GNU mail lists). Reviewed-by actually is stronger then Acked-by at least that is what I believe, I've always interpreted these 2 as: Acked-by: foo: Foo took a quick glance at the proposed changes and thinks this is a sensible change Reviewed-by: foo: Foo did a detailed review of the code and did not find any issues Regards, Hans ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/4] Add new "version" command
On Thu, Mar 29, Hans de Goede wrote: > I don't think there is much value in it and I don't feel > like spending time on this to come up with another solution. Not sure what you are trying to fix. At least for me the version is shown all the time at the top. And the buildtime does not add any value. Unclear why gcc still supports these two tags these days. Olaf signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] Fix PCIe LER when GRUB2 accesses non-enabled MMIO data from VGA
On Thu, Mar 29, 2018 at 05:00:56PM +0200, Hans de Goede wrote: > Hi, > > On 29-03-18 16:27, Mike Travis wrote: > > > > > >On 3/29/2018 2:36 AM, Daniel Kiper wrote: > >>On Thu, Mar 29, 2018 at 05:29:01PM +0800, Michael Chang wrote: > >>>On Thu, Mar 29, 2018 at 11:02:51AM +0200, Daniel Kiper wrote: > On Wed, Mar 28, 2018 at 11:42:18AM -0500, mike.tra...@hpe.com wrote: > >A GPU inserted into a PCIe I/O slot disappears during system startup. > >The problem centers around GRUB and a specific VGA init function in > >efi_uga.c.?? This causes an LER (link error recorvery) because the MMIO > >memory has not been enabled before attempting access. > > > >The fix is to add the same coding used in other VGA drivers, > >specifically > >to add a check to insure that it is indeed a VGA controller.?? And then > >enable the MMIO address space with the specific bits. > > > >Signed-off-by: Mike Travis > >Reviewed-by: Michael Chang > >Reviewed-by: Daniel Kiper > > Well, please do not add somebody RB tag if he/she did not explicitly > asked you to do that. And even in that case I was not able to look at > this patch in advance. So, my RB should not be here. Additionally, in > this situation I would like to ask if Michael approved his RB? > >>> > >>>We did have discussion about the patch before it was submitted upstream > >>>but I > >>>did not ask for RB as well. > >>> > Anyway, patch LGTM except one nitpick. I will apply the patch, in a > week or > so, with Michael's RB if I get confirmation that he approved it earlier. > >>> > >>>As I did not ask for it, it has to be removed. > >> > >>OK, I will commit this patch without your RB. > >> > >>Daniel > >> > > > >Sorry, I was not aware of this custom.?? I thought that if someone > >reviewed the code then that was an indication that it should be noted. I > >am aware of the more restrictive Acked-by which is normally sent by the > >"acker" to the submitter.?? I will be more mindful of this in the > >future.?? (This is my first posting to any of the GNU mail lists). No problem. > Reviewed-by actually is stronger then Acked-by at least that is > what I believe, I've always interpreted these 2 as: > > Acked-by: foo: Foo took a quick glance at the proposed changes and > thinks this is a sensible change > Reviewed-by: foo: Foo did a detailed review of the code and did not find > any issues I think that you can take look at Documentation/process/submitting-patches.rst in Linux kernel source. Most of us more or less adhere to this. Well, I think that I should put something similar into GRUB2 tree. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] F2FS support
Hi Daniel,
Thanks for reviewing the patch.
Here's a v2 that takes your comments into account.
Regards,
/Pete
On 2018.03.28 13:04, Daniel Kiper wrote:
On Thu, Mar 22, 2018 at 04:47:47PM +, Pete Batard wrote:
From 40030514e682191281e8ddba8d1e0835e6b685dc Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Thu, 4 May 2017 19:12:00 +0100
Subject: [PATCH] F2FS support
"F2FS (Flash-Friendly File System) is flash-friendly file system which was
merged
into Linux kernel v3.8 in 2013.
The motive for F2FS was to build a file system that from the start, takes into
account the characteristics of NAND flash memory-based storage devices (such as
solid-state disks, eMMC, and SD cards).
F2FS was designed on a basis of a log-structured file system approach, which
remedies some known issues of the older log structured file systems, such as
the snowball effect of wandering trees and high cleaning overhead. In addition,
since a NAND-based storage device shows different characteristics according to
its internal geometry or flash memory management scheme (such as the Flash
Translation Layer or FTL), it supports various parameters not only for
configuring on-disk layout, but also for selecting allocation and cleaning
algorithm.", quote by https://en.wikipedia.org/wiki/F2FS.
The source codes for F2FS are available from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git
Update:
- This patch has been integrated in OpenMandriva Lx 3.
https://www.openmandriva.org/
Acked-by: Andrei Borzenkov
Please drop this Acked-by. I will ask you to do some changes, mostly
nitpicks, and this means that it is no longer valid.
Signed-off-by: Jaegeuk Kim
Lack of your SOB.
[...]
diff --git a/docs/grub.texi b/docs/grub.texi
index 65b4bbe..5afdc5a 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -360,7 +360,8 @@ blocklist notation. The currently supported filesystem
types are @dfn{Amiga
Fast FileSystem (AFFS)}, @dfn{AtheOS fs}, @dfn{BeFS},
@dfn{BtrFS} (including raid0, raid1, raid10, gzip and lzo),
@dfn{cpio} (little- and big-endian bin, odc and newc variants),
-@dfn{Linux ext2/ext3/ext4}, @dfn{DOS FAT12/FAT16/FAT32}, @dfn{exFAT},
@dfn{HFS},
+@dfn{Linux ext2/ext3/ext4}, @dfn{DOS FAT12/FAT16/FAT32}, @dfn{exFAT},
+@dfn{f2fs}, @dfn{HFS},
@dfn{HFS+}, @dfn{ISO9660} (including Joliet, Rock-ridge and multi-chunk
files),
I would like to see this in one line:
@dfn{exFAT}, @dfn{f2fs}, @dfn{HFS}, @dfn{HFS+},
Hmmm... s/f2fs/F2FS/?
@dfn{JFS}, @dfn{Minix fs} (versions 1, 2 and 3), @dfn{nilfs2},
@dfn{NTFS} (including compression), @dfn{ReiserFS}, @dfn{ROMFS},
@@ -5375,7 +5376,7 @@ NTFS, JFS, UDF, HFS+, exFAT, long filenames in FAT,
Joliet part of
ISO9660 are treated as UTF-16 as per specification. AFS and BFS are read
as UTF-8, again according to specification. BtrFS, cpio, tar, squash4, minix,
minix2, minix3, ROMFS, ReiserFS, XFS, ext2, ext3, ext4, FAT (short names),
-RockRidge part of ISO9660, nilfs2, UFS1, UFS2 and ZFS are assumed
+f2fs, RockRidge part of ISO9660, nilfs2, UFS1, UFS2 and ZFS are assumed
s/f2fs/F2FS/?
to be UTF-8. This might be false on systems configured with legacy charset
but as long as the charset used is superset of ASCII you should be able to
access ASCII-named files. And it's recommended to configure your system to use
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 2c1d62c..fc4767f 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1315,6 +1315,11 @@ module = {
};
module = {
+ name = f2fs;
+ common = fs/f2fs.c;
+};
+
+module = {
name = fshelp;
common = fs/fshelp.c;
};
diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
new file mode 100644
index 000..7fb256f
--- /dev/null
+++ b/grub-core/fs/f2fs.c
@@ -0,0 +1,1289 @@
+/*
+ * f2fs.c - Flash-Friendly File System
+ *
+ * Written by Jaegeuk Kim
+ *
+ * Copyright (C) 2015 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see
