Re: [PATCH] fs: remove implicit compiler calls to memset/memcpy

[Pete Batard]

On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:

You can use asm to get around msvc limitations. Sth like

.global memcpy
memcpy:
   jmp grub_memcpy


Yes I'm well aware I could try to create my own library (or equivalent) 
that redefines memcpy/memset, using some workaround to avoid the MSVC 
compiler error (if needed, I could create a compatible aliasing lib with 
gcc). But that's something I'd prefer to avoid because it's never that 
simple in the MSVC world, and I'm also compiling for multiple archs (x86 
and ARM, possibly more in the future), which makes assembly workarounds 
an annoyance. Besides, I already have to patch the GRUB source anyway, 
with some MSVC specific quirks (some of which I doubt you guys would 
like [1]), so adding some more to my current patch series to remove the 
implicits is not exactly a big deal. But of course, I sure wouldn't mind 
minimizing the amount of code I need to patch to use GRUB in my scope, 
which is the whole point of this submission.



Where implicit memcpy is inserted is pretty much unpredictable


You're missing the purpose of my request. I'm not asking the GRUB 
project to do anything about predicting where memset/memcpy are going 
inserted, or even attempt to be preemptive about that in the future. I'm 
simply asking it to address the ones that were isolated with 100% 
accuracy (compiler flag to generate assembly with source + grep on said 
assembly) from using the current GRUB source in the specific context 
that I have.
There's no "predictive" component in what I am requesting here, not even 
an implied one.


So, in case that is the crux of the issue, should this patch be 
integrated, I am not asking any GRUB contributor to try to keep 
conscious of or try to identify potential implicits as they go about 
modifying fs or any other parts of the code. It is in fact of little 
consequence if someone comes in and breaks the applied implicits removal 
the day after it is applied, as I am using GRUB as a git submodule, 
therefore it'll remain tied to the specific git rev where it isn't 
broken. And if I try to update the submodule, and identify breakage, I 
will of course submit a new patch to this list as needed.



and we're
not going to maintain memcpy-free environment because of this


Again, this is not what I am asking. This is a simple "you scratch my 
back, I'll scratch yours" request, that, in a way, is pretty much akin 
to asking the GRUB project to add extra parenthesis in _very specific_ 
parts of source, to make it more palatable when these specific parts are 
used with compilers that are not officially supported by the project, 
and as a one-off thing (i.e. without asking for anyone to be tasked to 
maintaining that new parenthesis layout going forward).


If you want to say: "Well, we don't official support MSVC, so we're not 
going to pick a patch that is essentially aimed at improving MSVC 
support, especially if only applies to a limited set of sources", that's 
fine with me.
But please don't try to imply that the patch has a much larger scope 
than it actually does, as your justification for rejection, or that it 
is going to require any extra work/maintainance from GRUB contributors 
once applied.


Regards,

/Pete

[1] 
https://github.com/pbatard/efifs/blob/master/0001-GRUB-fixes-for-MSVC-compilation-part-1.patch#L366-L410


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] fs: remove implicit compiler calls to memset/memcpy

[Andrei Borzenkov]

On Mon, Apr 18, 2016 at 1:13 PM, Pete Batard  wrote:
> On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:
>>
>> You can use asm to get around msvc limitations. Sth like
>>
>> .global memcpy
>> memcpy:
>>jmp grub_memcpy
>
>
> Yes I'm well aware I could try to create my own library (or equivalent) that
> redefines memcpy/memset, using some workaround to avoid the MSVC compiler
> error (if needed, I could create a compatible aliasing lib with gcc). But
> that's something I'd prefer to avoid because it's never that simple in the
> MSVC world, and I'm also compiling for multiple archs (x86 and ARM, possibly
> more in the future), which makes assembly workarounds an annoyance. Besides,

grub so far was relatively good at localizing platform and compiler
specific code. It sounds like something that fits well.

> I already have to patch the GRUB source anyway, with some MSVC specific
> quirks (some of which I doubt you guys would like [1]), so adding some more
> to my current patch series to remove the implicits is not exactly a big
> deal. But of course, I sure wouldn't mind minimizing the amount of code I
> need to patch to use GRUB in my scope, which is the whole point of this
> submission.
>
>> Where implicit memcpy is inserted is pretty much unpredictable
>
>
> You're missing the purpose of my request. I'm not asking the GRUB project to
> do anything about predicting where memset/memcpy are going inserted, or even
> attempt to be preemptive about that in the future. I'm simply asking it to
> address the ones that were isolated with 100% accuracy (compiler flag to
> generate assembly with source + grep on said assembly) from using the
> current GRUB source in the specific context that I have.
> There's no "predictive" component in what I am requesting here, not even an
> implied one.
>

Compilers quite likely avoid calling external functions in this case;
so it prevents optimizing code on other platforms/compilers.

> So, in case that is the crux of the issue, should this patch be integrated,
> I am not asking any GRUB contributor to try to keep conscious of or try to
> identify potential implicits as they go about modifying fs or any other
> parts of the code. It is in fact of little consequence if someone comes in
> and breaks the applied implicits removal the day after it is applied, as I
> am using GRUB as a git submodule, therefore it'll remain tied to the
> specific git rev where it isn't broken. And if I try to update the
> submodule, and identify breakage, I will of course submit a new patch to
> this list as needed.
>
>> and we're
>> not going to maintain memcpy-free environment because of this
>
>
> Again, this is not what I am asking. This is a simple "you scratch my back,
> I'll scratch yours" request, that, in a way, is pretty much akin to asking
> the GRUB project to add extra parenthesis in _very specific_ parts of
> source, to make it more palatable when these specific parts are used with
> compilers that are not officially supported by the project, and as a one-off
> thing (i.e. without asking for anyone to be tasked to maintaining that new
> parenthesis layout going forward).
>
> If you want to say: "Well, we don't official support MSVC, so we're not
> going to pick a patch that is essentially aimed at improving MSVC support,
> especially if only applies to a limited set of sources", that's fine with
> me.

Personally I would welcome any patch aimed at improving MSVC support
as long as it is not added at expense of another platforms. We do
support native grub on Windows so it is just logical to support native
Windows build environment. It is just that no current grub maintainers
is using MSVC so if you volunteer to step in it would be great.

> But please don't try to imply that the patch has a much larger scope than it
> actually does, as your justification for rejection, or that it is going to
> require any extra work/maintainance from GRUB contributors once applied.
>
> Regards,
>
> /Pete
>
> [1]
> https://github.com/pbatard/efifs/blob/master/0001-GRUB-fixes-for-MSVC-compilation-part-1.patch#L366-L410
>
>
> ___
> 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] fs: remove implicit compiler calls to memset/memcpy

[Vladimir 'phcoder' Serbinenko]

Le 18 avr. 2016 20:36, "Andrei Borzenkov"  a écrit :
>
> On Mon, Apr 18, 2016 at 1:13 PM, Pete Batard  wrote:
> > On 2016.04.18 07:50, Vladimir 'phcoder' Serbinenko wrote:
> >>
> >> You can use asm to get around msvc limitations. Sth like
> >>
> >> .global memcpy
> >> memcpy:
> >>jmp grub_memcpy
> >
> >
> > Yes I'm well aware I could try to create my own library (or equivalent)
that
> > redefines memcpy/memset, using some workaround to avoid the MSVC
compiler
> > error (if needed, I could create a compatible aliasing lib with gcc).
But
> > that's something I'd prefer to avoid because it's never that simple in
the
> > MSVC world, and I'm also compiling for multiple archs (x86 and ARM,
possibly
> > more in the future), which makes assembly workarounds an annoyance.
Besides,
>
> grub so far was relatively good at localizing platform and compiler
> specific code. It sounds like something that fits well.
>
> > I already have to patch the GRUB source anyway, with some MSVC specific
> > quirks (some of which I doubt you guys would like [1]), so adding some
more
> > to my current patch series to remove the implicits is not exactly a big
> > deal. But of course, I sure wouldn't mind minimizing the amount of code
I
> > need to patch to use GRUB in my scope, which is the whole point of this
> > submission.
> >
> >> Where implicit memcpy is inserted is pretty much unpredictable
> >
> >
> > You're missing the purpose of my request. I'm not asking the GRUB
project to
> > do anything about predicting where memset/memcpy are going inserted, or
even
> > attempt to be preemptive about that in the future. I'm simply asking it
to
> > address the ones that were isolated with 100% accuracy (compiler flag to
> > generate assembly with source + grep on said assembly) from using the
> > current GRUB source in the specific context that I have.
> > There's no "predictive" component in what I am requesting here, not
even an
> > implied one.
> >
>
> Compilers quite likely avoid calling external functions in this case;
> so it prevents optimizing code on other platforms/compilers.
>
> > So, in case that is the crux of the issue, should this patch be
integrated,
> > I am not asking any GRUB contributor to try to keep conscious of or try
to
> > identify potential implicits as they go about modifying fs or any other
> > parts of the code. It is in fact of little consequence if someone comes
in
> > and breaks the applied implicits removal the day after it is applied,
as I
> > am using GRUB as a git submodule, therefore it'll remain tied to the
> > specific git rev where it isn't broken. And if I try to update the
> > submodule, and identify breakage, I will of course submit a new patch to
> > this list as needed.
> >
> >> and we're
> >> not going to maintain memcpy-free environment because of this
> >
> >
> > Again, this is not what I am asking. This is a simple "you scratch my
back,
> > I'll scratch yours" request, that, in a way, is pretty much akin to
asking
> > the GRUB project to add extra parenthesis in _very specific_ parts of
> > source, to make it more palatable when these specific parts are used
with
> > compilers that are not officially supported by the project, and as a
one-off
> > thing (i.e. without asking for anyone to be tasked to maintaining that
new
> > parenthesis layout going forward).
> >
> > If you want to say: "Well, we don't official support MSVC, so we're not
> > going to pick a patch that is essentially aimed at improving MSVC
support,
> > especially if only applies to a limited set of sources", that's fine
with
> > me.
>
> Personally I would welcome any patch aimed at improving MSVC support
> as long as it is not added at expense of another platforms. We do
> support native grub on Windows so it is just logical to support native
> Windows build environment. It is just that no current grub maintainers
> is using MSVC so if you volunteer to step in it would be great.
>
Supporting MSVC would also allow compiling to EBC, even though benefits of
this are questionable.
This patch is not about full support but only about one specific folder and
doesn't give us full support.
I think we might be setting wrong expectations here. In any case it's not
2.02 material, so I put it lower in my priority list
> > But please don't try to imply that the patch has a much larger scope
than it
> > actually does, as your justification for rejection, or that it is going
to
> > require any extra work/maintainance from GRUB contributors once applied.
> >
> > Regards,
> >
> > /Pete
> >
> > [1]
> >
https://github.com/pbatard/efifs/blob/master/0001-GRUB-fixes-for-MSVC-compilation-part-1.patch#L366-L410
> >
> >
> > ___
> > 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] fs: remove implicit compiler calls to memset/memcpy

[Pete Batard]

On 2016.04.18 12:49, Vladimir 'phcoder' Serbinenko wrote:

In any case it's
not 2.02 material, so I put it lower in my priority list


Thanks for considering it further - much appreciated.

I should point out that there's obviously nothing blocking for me, so 
I'm fine with any delay.


On 2016.04.18 12:36, Andrei Borzenkov wrote:
>   It is just that no current grub maintainers
> is using MSVC so if you volunteer to step in it would be great.

I wouldn't mind, and that is something I have done before with libcdio 
-- sadly that effort was stopped short of adding full Visual Studio 
support (i.e. with with project files), but at least now the libcdio 
codebase is fully compatible with MS compilers. My only issue is that 
I'm very busy with various projects, so time constraints are a major factor.


Still, I have been benefiting greatly from GRUB and I do have additional 
MSVC compatibility patches, especially the ones that have to do struct 
packing, that I wouldn't mind seeing integrated in the source. So if it 
can help, I'll see if I can take a stab at providing MSVC support for 
the whole project. Overall, short of very specific quirks, I haven't 
found much in the way of compiling the GRUB code with MSVC, so maybe the 
effort required won't be that bad...

I'll keep you posted.

Regards,

/Pete




___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

GRUB and File System consistency check.

[gatis paeglis]

Hello,

I have one mystery that I can't find an answer to. I see that most distros
keep kernel/initramfs images on the same partition as the root file system.
Isn't this unsafe in a scenario where there is a power cut and then next
time when booting, GRUB will be reading kernel/initramfs from an
inconsistent file system?

Is it FS drivers in GRUB that are responsible to replay that FS journal or
a system builder should provide its own ad-hoc solution for ensuring FS
consistency before GRUB attempts to read from it?
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] build: Use AC_HEADER_MAJOR to find device macros

[Mike Gilbert]

On Sun, Apr 17, 2016 at 2:27 PM, Mike Gilbert  wrote:
> Depending on the OS/libc, device macros are defined in different
> headers.
>
> sys/mkdev.h - BSD, Sun
> sys/sysmacros.h - glibc (Linux)

It seems I was wrong about BSD; it is defined directly in sys/types.h
on FreeBSD at least.

https://svnweb.freebsd.org/base/stable/10/sys/sys/types.h?revision=289107&view=markup#l360

Would you like me to revise the commit message again?

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Is objconv a requirement for building Grub?

[Andrei Borzenkov]

That's more in place on grub-devel.

19.04.2016 03:27, Eric Andrew Lewis пишет:
> I'm trying to build a patched version of Grub from source on a Mac. I've
> installed all the requirements in the INSTALL file, but got an error while
> running ./configure
> 
> configure: error: objconv not found which is required when building with
> apple compiler

obconv is used when using Apple linker instead of GNU ld (mesage is
misleading here). If you installed all requirements, you should also
have binutils which includes GNU ld and GCC. In this case any reason you
do not use them?

I suppose it is possible to build grub using native Apple cc/ld, in
which case it probably becomes relevant.

> I assume I should install objconv ?
> If so, can we add this to the Requirements list?
> 

Sure, I just wonder if someone can name more specific version requirements.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel