Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On Thu, Nov 28, 2013 at 07:19:46AM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Nov 28, 2013 3:31 AM, "Colin Watson" wrote:
> > +If this option is set to @samp{countdown} or @samp{hidden}, then, before
> > +displaying the menu, GRUB will wait for the timeout set by
> > +@samp{GRUB_TIMEOUT} to expire. If @key{ESC} is pressed during that
> > time, it
> > +will display the menu and wait for input according to
> > @samp{GRUB_TIMEOUT}.
> > +If a hotkey associated with a menu entry is pressed, it will boot the
> > +associated menu entry immediately. If the timeout expires before either
> > of
> > +these happens, it will display the menu.
>
> What you describe here doesn‘t serm what code is doing. Copypaste error?
I must be missing something. What part of this doesn't agree with the
code?
... oh, right, if the timeout expires then it will boot the default
entry. I'll fix that, thanks.
> > diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
> > index ba1d4ef..50f73aa 100644
> > --- a/util/grub-mkconfig.in
> > +++ b/util/grub-mkconfig.in
> > @@ -186,6 +186,7 @@ export GRUB_DEFAULT \
> >GRUB_HIDDEN_TIMEOUT \
> >GRUB_HIDDEN_TIMEOUT_QUIET \
> >GRUB_TIMEOUT \
> > + GRUB_TIMEOUT_STYLE \
>
> you need button variant as well
Can you suggest a use case for that? I can understand why you might
want different timeouts in the button case, just about, but not why
you'd want an entirely different style of menu.
> > + fi
> > if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then
> > verbose=
> > + style="hidden"
> > else
> > verbose=" --verbose"
> > + style="countdown"
> > fi
> > cat << EOF
> > -if sleep$verbose --interruptible ${1} ; then
> > +if [ x\$feature_timeout_style = xy ] ; then
> > + set timeout_style=$style
> > + set timeout=${1}
> > +elif sleep$verbose --interruptible ${1} ; then
> >set timeout=${2}
>
> Is behaviour mismatch between both versions intentional?
> I see 2 ways of handling double timeout: either not supporting at all
> anymore or generate old code for it. This one seems to be mix of both
The code is somewhat inevitably confusing, I'll agree, but I don't see
the mismatch. Could you please give me an example?
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
Il 27/11/2013 18:35, Andrey Borzenkov ha scritto: В Wed, 27 Nov 2013 17:24:53 +0100 Fabio Fantoni пишет: Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 27.11.2013 16:59, Fabio Fantoni wrote: Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: That pretty much explains what happened: you don't have any /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB found its own memdisk and fell into recursion. I'm not sure what should be the proper way to solve this recursion. Yes, it was a bit naive on my side. Recursion in principle can be stopped by using global variable, but search is limited to the first match only anyway, so I guess it is not worth it. Anyone know how to exclude memdisk from the search please? Please look in grub2 sources at docs/osdetect.cfg. It implements advanced run-time detection of possible bootable files from various operating systems. It boils down to loop across all devices, and of course you can either limit device names (like looking for hd* only) or explicitly exclude known ones (like memdisk). Is it possible to specify a different default grub.cfg path (different from all other distributions) changing this command: ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O x86_64-xen -d grub-core/ boot/grub/grub.cfg Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set? Not really. Currently the situation is - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub - after launch grub unconditionally starts "normal" module if at all possible - normal module always tries to load and execute $prefix/grub.cfg if no explicit configuration file name is given as argument But I think that using osdetect.cfg or something based on this idea won't require changing defaults at all. Thanks for your reply. I did this script that is working about finding and include the grub.cfg of pv domUs with many cases: cat > boot/grub/grub.cfg <@xen developer: Are there other modules to insert for other partitions or file systems, other grub cfg path for other distributions or other kernel type to search that support xen pv domUs? I think is good do and post complete pvgrub2 cfg that support all pv domUs. @xen and grub developer: I'm still unable to boot any entry of Sid pv domU using official kernel: xl -vvv create -c /etc/xen/sid.cfg ... Caricamento Linux 3.11-1-amd64... Caricamento ramdisk iniziale... xc: debug: hypercall buffer: total allocations:247 total releases:247 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7 Any ideas? If you need more tests/informations tell me and I'll post them. Thanks for any reply. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] ls core command: handle listing of the root directory
В Thu, 28 Nov 2013 07:31:54 +0100
"Vladimir 'phcoder' Serbinenko" пишет:
> this very confusing with 2 opposite patches in same mail. I don't have my
> keys here. Feel free to commit documentation patch. If you commit on
> Francesco's behalf don't forget --author
Done.
> On Nov 27, 2013 7:42 PM, "Andrey Borzenkov" wrote:
>
> > What about this patch? Looks correct to me and reflects actual behavior.
> >
> >
> > В Sun, 02 Jun 2013 16:48:23 +0200
> > Francesco Lavra пишет:
> >
> > > On 05/18/2013 12:26 PM, Francesco Lavra wrote:
> > > > On 05/12/2013 12:56 PM, Francesco Lavra wrote:
> > > >> Currently, listing of the root directory of a device with the command:
> > > >> ls (device_name)
> > > >> requires the underlying filesystem driver to handle an empty path
> > > >> string as if it was the root directory path "/". This introduces
> > > >> duplicated code across the different filesystem drivers. If a given
> > > >> filesystem driver does not implement special handling of the empty
> > > >> path string, the above command gives "error: invalid file name `'."
> > > >> This error happens for instance with the ext4 filesystem.
> > > >> The best place to handle correctly the empty path string and transform
> > > >> it in "/" is the function grub_core_cmd_ls(), so that handling from
> > > >> each filesystem driver is not required anymore.
> > > >
> > > > After revision 5010, issuing the ls command with a device name as
> > > > parameter gives a response such as:
> > > > (device_name): Filesystem is .
> > > > But grub.texi says:
> > > > "
> > > > @deffn Command ls [arg @dots{}]
> > > > List devices or files.
> > > >
> > > > With no arguments, print all devices known to GRUB.
> > > >
> > > > If the argument is a device name enclosed in parentheses (@pxref{Device
> > > > syntax}), then list all files at the root directory of that device.
> > > >
> > > > If the argument is a directory given as an absolute file name
> > (@pxref{File
> > > > name syntax}), then list the contents of that directory.
> > > > @end deffn
> > > > "
> > > >
> > > > Which is the correct behavior?
> > >
> > > Depending on the answer to the above question, you might want to
> > > consider applying one of the two patches below, as you see fit.
> > >
> > > Regards,
> > > Francesco
> > >
> > > 2013-06-02 Francesco Lavra
> > >
> > > * docs/grub.texi (ls): Fix command description in case of a device
> > name
> > > passed as argument.
> > >
> > > === modified file 'docs/grub.texi'
> > > --- docs/grub.texi2013-05-11 05:23:26 +
> > > +++ docs/grub.texi2013-06-02 14:35:24 +
> > > @@ -4049,7 +4049,7 @@
> > > With no arguments, print all devices known to GRUB.
> > >
> > > If the argument is a device name enclosed in parentheses (@pxref{Device
> > > -syntax}), then list all files at the root directory of that device.
> > > +syntax}), then print the name of the filesystem of that device.
> > >
> > > If the argument is a directory given as an absolute file name
> > (@pxref{File
> > > name syntax}), then list the contents of that directory.
> > >
> > >
> > > 2013-06-02 Francesco Lavra
> > >
> > > * grub-core/kern/corecmd.c (grub_core_cmd_ls): Fix listing of root
> > > directory contents.
> > >
> > > === modified file 'grub-core/kern/corecmd.c'
> > > --- grub-core/kern/corecmd.c 2013-06-02 14:23:14 +
> > > +++ grub-core/kern/corecmd.c 2013-06-02 14:28:24 +
> > > @@ -147,13 +147,11 @@
> > >
> > >if (! *path)
> > > {
> > > - if (grub_errno == GRUB_ERR_UNKNOWN_FS)
> > > - grub_errno = GRUB_ERR_NONE;
> > > -
> > > - grub_printf ("(%s): Filesystem is %s.\n",
> > > -device_name, fs ? fs->name : "unknown");
> > > + /* The argument is a device name: list all files at the root
> > directory
> > > + of the device. */
> > > + path = (char *) "/";
> > > }
> > > - else if (fs)
> > > + if (fs)
> > > {
> > > (fs->dir) (dev, path, grub_mini_print_files, NULL);
> > > grub_xputs ("\n");
> > >
> > > ___
> > > 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
> >
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Ignore symlink traversal failures in grub-mount readdir
В Sun, 10 Mar 2013 14:01:53 +0100 Vladimir 'φ-coder/phcoder' Serbinenko пишет: > On 09.03.2013 17:47, Andrey Borzenkov wrote: > > > В Fri, 12 Oct 2012 17:09:54 +0100 > > Colin Watson пишет: > > > >> This is very much a temporary hack, so I'm sending it here for > >> discussion rather than just committing it even though it's quite simple. > >> > >> r3036.1.15 introduced support for filling in the attributes of files in > >> fuse_readdir. However, symlinks to directories are passed to call_fill > >> with info.dir unset; call_fill will then try to open them with > >> grub_file_open, and get GRUB_ERR_BAD_FILE_TYPE because it's ultimately a > >> directory not a regular file. It then causes the whole readdir call to > >> fail. The net effect is that if you, for example, have a symlink > >> anywhere in the top level of a filesystem, then the entire filesystem > >> appears empty in grub-mount. This is the root cause of > >> https://bugs.launchpad.net/bugs/1051306. > >> > >> I think that the proper solution is to pass the full > >> grub_fshelp_filetype to dirhook functions, which would permit > >> implementing true symlink support in grub-mount. That would be a fairly > >> large change that I don't have time for at the moment. As a stopgap, I > >> suggest that we ignore errors from individual grub_file_open calls > >> during fuse_readdir. How does this patch look? > >> > > > > The only reason to call grub_file_open() is to fetch file size, and file > > size is already available when hooks are called. So what about patch > > below? It fixes problem for me, and it trivial enough. This allows > > directory listing to work again. I can extend it with info.is_link to > > return proper filetype to FUSE, but implementing full support needs > > adding readlink that is a separate topic. > > > > I tested it with ext4 and cpio and it works. Testing on more systems > > (in particular, NTFS, which is the only one with non-trivial change) is > > appreciated. > > > > Some time ago I made a similar patch but for another motivation: current > code is way too inefficient for large directories as you have to rescan > directory for every file. The problem with this patch is 10 bytes > increase of core.img. This may be acceptable given this problem (it > happens in ls on runtime as well) and inefficency of scanning. > Any thoughts on it? I'm fine with either approach; there was some reduction of core size in the meantime so may be slight increase is acceptable? signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Xen-devel] pvgrub2 is merged
On 28.11.2013 14:07, Fabio Fantoni wrote: > Il 27/11/2013 18:35, Andrey Borzenkov ha scritto: >> В Wed, 27 Nov 2013 17:24:53 +0100 >> Fabio Fantoni пишет: >> >>> Il 27/11/2013 17:03, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: On 27.11.2013 16:59, Fabio Fantoni wrote: > Il 27/11/2013 12:50, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto: >> That pretty much explains what happened: you don't have any >> /boot/grub2/grub.cfg and when looking for /boot/grub/grub.cfg GRUB >> found >> its own memdisk and fell into recursion. I'm not sure what should >> be the >> proper way to solve this recursion. >> Yes, it was a bit naive on my side. Recursion in principle can be >> stopped by using global variable, but search is limited to the first >> match only anyway, so I guess it is not worth it. >> > Anyone know how to exclude memdisk from the search please? >> Please look in grub2 sources at docs/osdetect.cfg. It implements >> advanced run-time detection of possible bootable files from >> various operating systems. It boils down to loop across all devices, >> and of course you can either limit device names (like looking for hd* >> only) or explicitly exclude known ones (like memdisk). >> >>> Is it possible to specify a different default grub.cfg path (different >>> from all other distributions) changing this command: >>> ./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O >>> x86_64-xen -d grub-core/ boot/grub/grub.cfg >>> Is it hardcoded as /boot/grub/grub.cfg for grub memdisk or can be set? >>> >> Not really. Currently the situation is >> >> - grub-mkstandalone hardcodes $prefix as (memdisk)/boot/grub >> - after launch grub unconditionally starts "normal" module if at all >>possible >> - normal module always tries to load and execute $prefix/grub.cfg if no >>explicit configuration file name is given as argument >> >> But I think that using osdetect.cfg or something based on this idea >> won't require changing defaults at all. > > Thanks for your reply. > > I did this script that is working about finding and include the grub.cfg > of pv domUs with many cases: > > cat > boot/grub/grub.cfg < insmod lvm > insmod ext2 > insmod part_msdos > insmod part_gpt > insmod btrfs > > insmod regexp > for dev in (*); do > # $device: parenthesis removed from $dev > regexp -s device '\((.*)\)' $dev > set root=$device > for file in /boot/vmlinuz-* /boot/linux-*; do > if test -f $file; then > set saved_root=$root > fi > done > done > set root=$saved_root > > if test -f /boot/grub2/grub.cfg ; then > configfile /boot/grub2/grub.cfg > elif test -f /boot/grub/grub.cfg ; then > configfile /boot/grub/grub.cfg > fi > EOF > > @xen developer: Are there other modules to insert for other partitions > or file systems, other grub cfg path for other distributions or other > kernel type to search that support xen pv domUs? > I think is good do and post complete pvgrub2 cfg that support all pv domUs. > > @xen and grub developer: I'm still unable to boot any entry of Sid pv > domU using official kernel: > xl -vvv create -c /etc/xen/sid.cfg > ... > Caricamento Linux 3.11-1-amd64... > Caricamento ramdisk iniziale... > xc: debug: hypercall buffer: total allocations:247 total releases:247 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 > xc: debug: hypercall buffer: cache current size:4 > xc: debug: hypercall buffer: cache hits:236 misses:4 toobig:7 > > Any ideas? > Ah I forgot: you need to "insmod xzio" since debian ones are compressed. > If you need more tests/informations tell me and I'll post them. > > Thanks for any reply. > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On 28.11.2013 12:04, Colin Watson wrote:
> On Thu, Nov 28, 2013 at 07:19:46AM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> On Nov 28, 2013 3:31 AM, "Colin Watson" wrote:
>>> +If this option is set to @samp{countdown} or @samp{hidden}, then, before
>>> +displaying the menu, GRUB will wait for the timeout set by
>>> +@samp{GRUB_TIMEOUT} to expire. If @key{ESC} is pressed during that
>>> time, it
>>> +will display the menu and wait for input according to
>>> @samp{GRUB_TIMEOUT}.
>>> +If a hotkey associated with a menu entry is pressed, it will boot the
>>> +associated menu entry immediately. If the timeout expires before either
>>> of
>>> +these happens, it will display the menu.
>>
>> What you describe here doesn‘t serm what code is doing. Copypaste error?
>
> I must be missing something. What part of this doesn't agree with the
> code?
>
> ... oh, right, if the timeout expires then it will boot the default
> entry. I'll fix that, thanks.
>
>>> diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
>>> index ba1d4ef..50f73aa 100644
>>> --- a/util/grub-mkconfig.in
>>> +++ b/util/grub-mkconfig.in
>>> @@ -186,6 +186,7 @@ export GRUB_DEFAULT \
>>>GRUB_HIDDEN_TIMEOUT \
>>>GRUB_HIDDEN_TIMEOUT_QUIET \
>>>GRUB_TIMEOUT \
>>> + GRUB_TIMEOUT_STYLE \
>>
>> you need button variant as well
>
> Can you suggest a use case for that? I can understand why you might
> want different timeouts in the button case, just about, but not why
> you'd want an entirely different style of menu.
>
Normal button: normal start, hidden menu
Second button: diagnostic, show menu
>>> + fi
>>> if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then
>>> verbose=
>>> + style="hidden"
>>> else
>>> verbose=" --verbose"
>>> + style="countdown"
>>> fi
>>> cat << EOF
>>> -if sleep$verbose --interruptible ${1} ; then
>>> +if [ x\$feature_timeout_style = xy ] ; then
>>> + set timeout_style=$style
>>> + set timeout=${1}
>>> +elif sleep$verbose --interruptible ${1} ; then
>>>set timeout=${2}
>>
>> Is behaviour mismatch between both versions intentional?
>> I see 2 ways of handling double timeout: either not supporting at all
>> anymore or generate old code for it. This one seems to be mix of both
>
> The code is somewhat inevitably confusing, I'll agree, but I don't see
> the mismatch. Could you please give me an example?
>
if both GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT are set the part for old
GRUB will replicate old behaviour while part for new GRUB would make
only one timeout. To make them align it would need set timeout=-1 at
last line.
> Thanks,
>
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: PATCH: added GRUB command to get and set (U)EFI firmware variables
On Wednesday, November 27, 2013, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 27.11.2013 19:57, Andrey Borzenkov wrote: > > В Wed, 27 Nov 2013 13:44:41 -0500 > > SevenBits > пишет: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > > > >> On 11/25/2013 07:22 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > >>> On 25.11.2013 23:28, SevenBits wrote: > > On 11/25/2013 05:07 PM, Vladimir '?-coder/phcoder' Serbinenko > wrote: > > On 25.11.2013 23:03, SevenBits wrote: > >> > >> Thanks for your quick reply. > >> > >> I just have a couple of questions. How do you prefer I allow > >> the user to specify the vendor UUID? By typing it in via the > >> keyboard? And secondly, by saying it needs "readable aliases > >> for known types" do you mean that there should be a function > >> to set an integer, one to set a boolean, etc? > >> > > I meant for UUIDs. E.g. one alias "efi" for shared space, > > "apple" for apple and so on. > So other than a generic variable UUID and Apple, are there others > that you think might be necessary? I can try and put in some > common ones but manufacturers may not disclose what their > specific UUIDs are. > > >>> I'd include a command to list variables (interactively). We would > >>> pretty quickly collect most common UUIDs this way. > > > >> So, I've got a command written to print out the system's firmware > >> variables. Trouble is I'm not sure what the best way would be to print > >> or otherwise display the UUIDs gathered so that we can collect them. > > > > > > I think it is rather premature at this point. > Agreed. I wasn't clear enough that I meant that in the first > implementation we need to put just few UUIDs we already know about as > aliases and expand them with the time. Okay, sounds okay to me. I'll be occupied because of the holidays here in the United States but I can get on it as soon as I can. > > What is needed first is > > sane framework for handling EFI variables, which means - handling GUID, > > options (during set or as filter in listing variables) and conversion of > > arbitrary binary data from/to external printable representation. I think I get what you mean. I'll focus on this area then. > > > > > > But type of variable is also an issue and there should be at > > least following available: hex - transform all in hex utf16 - > > decode utf16 into utf8 Probably more, didn't really look into > > issue > I see, okay, I'll add some in. > > > > > > > Yes, please. Adding aliases for GUID can always come later and is not > > really that important. Alright. Any specific ideas of where I should put the code? In with the other UEFI handling stuff or in the code for the module I'm writing? > > ___ > > 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: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
В Thu, 28 Nov 2013 11:04:28 +
Colin Watson пишет:
> On Thu, Nov 28, 2013 at 07:19:46AM +0100, Vladimir 'phcoder' Serbinenko wrote:
> > On Nov 28, 2013 3:31 AM, "Colin Watson" wrote:
> > > +If this option is set to @samp{countdown} or @samp{hidden}, then, before
> > > +displaying the menu, GRUB will wait for the timeout set by
> > > +@samp{GRUB_TIMEOUT} to expire. If @key{ESC} is pressed during that
> > > time, it
> > > +will display the menu and wait for input according to
> > > @samp{GRUB_TIMEOUT}.
> > > +If a hotkey associated with a menu entry is pressed, it will boot the
> > > +associated menu entry immediately. If the timeout expires before either
> > > of
> > > +these happens, it will display the menu.
> >
> > What you describe here doesn‘t serm what code is doing. Copypaste error?
>
> I must be missing something. What part of this doesn't agree with the
> code?
>
> ... oh, right, if the timeout expires then it will boot the default
> entry. I'll fix that, thanks.
>
Not only. If you hit ESC it will not "wait for input according to
GRUB_TIMEOUT" - it will stop displaying menu.
I'm not sure whether exposing menu but continuing count down is useful.
We could let any other key (or specific key - SPACE?) do it.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
В Thu, 28 Nov 2013 02:30:56 +
Colin Watson пишет:
> @item GRUB_HIDDEN_TIMEOUT
> @item GRUB_HIDDEN_TIMEOUT_QUIET
I suggest removing them from user visible documentation and leaving
only as compatibility options in grub-mkconfig. No reason do endorse
their usage ("deprecated" is usually was nobody pays attention to).
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GIT workflow
В Thu, 28 Nov 2013 07:45:00 +0100 "Vladimir 'phcoder' Serbinenko" пишет: > I don't like the idea of double work to essentially have 2 commit messages. > But it's possible to remove Changelog file. I'd like to know if any other > major gnu projects made the move. Oh, I did not dare to ask but if you mention it :) Yes, ChangeLog is the major source of merge conflicts and makes it impossible to cleanly cherry-pick patches for package maintenance. So please ... > On Nov 25, 2013 7:27 PM, "Andrey Borzenkov" wrote: > > > В Thu, 14 Nov 2013 15:20:10 +0200 > > Mikko Rantalainen пишет: > > > > > Vladimir 'φ-coder/phcoder' Serbinenko, 2013-11-10 19:01 > > (Europe/Helsinki): > > > > Hello, all. We've switched to git some time ago, now we should have > > some > > > > kind of workflow documents. In particular I think of following points: > > > > - Developpers with commit access can create branches as they see fit as > > > > long as it's prefixed by their name and they don't do sth nasty like > > > > storing binary or unrelated files. > > > > - When committing bigger work should we merge or squash? I think that > > > > squash should be possible if developper desires. Is there any reason to > > > > use merges? > > > > > > Squashed merge is identical to rebase && merge --no-ff except for the > > > detail that squashing loses any meaningful history for the patch series. > > > I'd seriously suggest rebase followed by merge --no-ff over squashed > > > merges. The only exception is the case where commits in the original > > > work are not logical patches but instead random snapshots of the > > > directory tree during development of the patch. In that case, squashing > > > the patch series loses no valuable information. > > > > > > The reason to keep patch series: git bisect > > > > > > > Also squash is losing individual contribution. > > > > I think it really depends. For simple patches that are self-contained > > squash is actually better; that is basically what TopGIT does to > > maintain patches. For anything developed over long time history should > > be preserved (a.k.a. merge). > > > > > > - Which commits should we sign? All? Some? Official releases? > > > > > > Depends on what you mean by "sign". If you mean > > > > > >Signed-off-by: A U Thor > > > > > > that's the "Developer Certificate Of Origin": > > > http://elinux.org/Developer_Certificate_Of_Origin > > > > > > Other projects (e.g Grub) can decide their own policy for such metadata. > > > Additional info is available at > > > > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for > > > > > > If you mean digitally signed, the correct method is to use signed tags > > > for all the releases meant for non-developers. See "git help tag" and > > > look for "--sign". > > > > > > > Release tags should better be signed; is there official key to be used > > in this case? > > > > I have additional topic > > > > - format of commit message > > > > Established GIT commit message is single summary line followed by more > > extensive description if necessary. Quite a number of git commands and > > wrappers around git assume that the summary line is present. Currently > > commit message format is near to useless. Half of the first line is > > lost for file name; the second half is partial sentence, often > > meaningless. > > > > Could we break with tradition "commit message" == "ChangeLog entry"? > > > > ___ > > 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 v0] Require human interaction to go to normal shell if grub.cfg has a problem
В Mon, 25 Nov 2013 15:46:48 -0800
Jon McCune пишет:
> The rescue prompt is very useful for human operators, but not so
> useful in unattended environments. Add a facility for rebooting
> after a delay, so that, e.g., the system can still PXE boot if
> there is no console attached.
>
> Signed-off-by: Jon McCune
> ---
> grub-core/normal/main.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
You get rescue prompt when you can *not* launch normal.mod.
> index ad36273..f8953d5 100644
> --- a/grub-core/normal/main.c
> +++ b/grub-core/normal/main.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> GRUB_MOD_LICENSE ("GPLv3+");
>
> @@ -333,6 +334,21 @@ grub_normal_execute (const char *config, int nested, int
> batch)
> }
> }
>
> +/* Copied from grub-core/commands/sleep.c. */
> +static int
> +grub_interruptible_millisleep (grub_uint32_t ms)
> +{
> + grub_uint64_t start;
> +
> + start = grub_get_time_ms ();
> +
> + while (grub_get_time_ms () - start < ms)
> +if (grub_getkey_noblock () == GRUB_TERM_ESC)
> + return 1;
> +
> + return 0;
> +}
> +
> /* This starts the normal mode. */
> void
> grub_enter_normal_mode (const char *config)
> @@ -340,6 +356,15 @@ grub_enter_normal_mode (const char *config)
>grub_boot_time ("Entering normal mode");
>nested_level++;
>grub_normal_execute (config, 0, 0);
> + /* Control only returns from grub_normal_execute() if there is some kind of
> + * problem with grub.cfg, like it does not exist. Reboot by default unless
> + * ESC is pressed within 5 seconds. */
grub-mkrescue creates CD that starts normal CLI without grub.cfg. So
please - not as default. You can make it dependent on variable which
can be set in embedded grub.cfg for the cases when you really need it.
> + grub_printf ("Press ESC in 5 seconds for a rescue shell.\n");
"for a command line". This is not rescue shell.
> + if (!grub_interruptible_millisleep (5000))
> +{
> + grub_printf ("Rebooting instead of going to rescue shell.\n");
Ditto.
> + grub_reboot ();
> +}
>grub_boot_time ("Entering shell");
>grub_cmdline_run (0);
>nested_level--;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On Thu, Nov 28, 2013 at 09:20:17PM +0400, Andrey Borzenkov wrote: > Not only. If you hit ESC it will not "wait for input according to > GRUB_TIMEOUT" - it will stop displaying menu. No, that's not true in my tests. If you hit Escape while a hidden timeout is active and GRUB_TIMEOUT is non-zero, it'll display the menu. If you can make this happen, please post a detailed test case. > I'm not sure whether exposing menu but continuing count down is useful. > We could let any other key (or specific key - SPACE?) do it. I don't think it's very useful, which is why it isn't available in the new GRUB_TIMEOUT + GRUB_TIMEOUT_STYLE interface; but it was exposed in the old GRUB_HIDDEN_TIMEOUT + GRUB_TIMEOUT interface so I don't want to break it entirely. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
On Thu, Nov 28, 2013 at 09:22:49PM +0400, Andrey Borzenkov wrote:
> В Thu, 28 Nov 2013 02:30:56 +
> Colin Watson пишет:
> > @item GRUB_HIDDEN_TIMEOUT
> > @item GRUB_HIDDEN_TIMEOUT_QUIET
>
> I suggest removing them from user visible documentation and leaving
> only as compatibility options in grub-mkconfig. No reason do endorse
> their usage ("deprecated" is usually was nobody pays attention to).
My concern is that they will probably hang around in people's
configurations for some time and I would like the documentation to tell
users what these mysterious things mean.
As a compromise, perhaps we could move them to a separate page?
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] fix using grub device name as install device
Shell version of grub-install called grub-setup which resolved
install device name and called main setup routine. C version of
grub-install calls main setup routine directly, which leads
to the error:
grub2-install: info: grub-bios-setup --verbose --force --skip-fs-probe
--directory='/boot/grub2/i386-pc' --device-map='/boot/grub2/device.map' '(hd2)'.
grub2-install: info: reading /boot/grub2/i386-pc/boot.img.
grub2-install: info: reading /boot/grub2/i386-pc/core.img.
grub2-install: info: root is `(null)', dest is `(hd2)'.
grub2-install: info: Opening dest.
grub2-install: info: drive = -1.
grub2-install: error: disk `(hd2)' not found.
Move resolving of destination device name into main setup routine
so it is done consistently in both cases.
---
util/grub-setup.c | 41 +
util/setup.c | 26 +-
2 files changed, 26 insertions(+), 41 deletions(-)
diff --git a/util/grub-setup.c b/util/grub-setup.c
index 90b9de0..cc3af5d 100644
--- a/util/grub-setup.c
+++ b/util/grub-setup.c
@@ -209,23 +209,9 @@ DEVICE must be an OS device (e.g. /dev/sda)."),
NULL, help_filter, NULL
};
-static char *
-get_device_name (char *dev)
-{
- size_t len = strlen (dev);
-
- if (dev[0] != '(' || dev[len - 1] != ')')
-return 0;
-
- dev[len - 1] = '\0';
- return dev + 1;
-}
-
int
main (int argc, char *argv[])
{
- char *root_dev = NULL;
- char *dest_dev = NULL;
struct arguments arguments;
grub_util_host_init (&argc, &argv);
@@ -264,34 +250,11 @@ main (int argc, char *argv[])
grub_mdraid1x_init ();
grub_lvm_init ();
- dest_dev = get_device_name (arguments.device);
- if (! dest_dev)
-{
- /* Possibly, the user specified an OS device file. */
- dest_dev = grub_util_get_grub_dev (arguments.device);
- if (! dest_dev)
-{
- char *program = xstrdup(program_name);
- fprintf (stderr, _("Invalid device `%s'.\n"), arguments.device);
- argp_help (&argp, stderr, ARGP_HELP_STD_USAGE, program);
- free(program);
- exit(1);
-}
- grub_util_info ("transformed OS device `%s' into GRUB device `%s'",
- arguments.device, dest_dev);
-}
- else
-{
- /* For simplicity. */
- dest_dev = xstrdup (dest_dev);
- grub_util_info ("Using `%s' as GRUB device", dest_dev);
-}
-
/* Do the real work. */
GRUB_SETUP_FUNC (arguments.dir ? : DEFAULT_DIRECTORY,
arguments.boot_file ? : DEFAULT_BOOT_FILE,
arguments.core_file ? : DEFAULT_CORE_FILE,
- dest_dev, arguments.force,
+ arguments.device, arguments.force,
arguments.fs_probe, arguments.allow_floppy);
/* Free resources. */
@@ -303,8 +266,6 @@ main (int argc, char *argv[])
free (arguments.dir);
free (arguments.dev_map);
free (arguments.device);
- free (root_dev);
- free (dest_dev);
return 0;
}
diff --git a/util/setup.c b/util/setup.c
index 337c304..c1de3d2 100644
--- a/util/setup.c
+++ b/util/setup.c
@@ -247,12 +247,13 @@ identify_partmap (grub_disk_t disk __attribute__
((unused)),
void
SETUP (const char *dir,
const char *boot_file, const char *core_file,
- const char *dest, int force,
+ const char *dev, int force,
int fs_probe, int allow_floppy)
{
char *core_path;
char *boot_img, *core_img, *boot_path;
char *root = 0;
+ char *dest = 0;
size_t boot_size, core_size;
#ifdef GRUB_SETUP_BIOS
grub_uint16_t core_sectors;
@@ -269,6 +270,28 @@ SETUP (const char *dir,
#endif
bl.last_length = 0;
+ {
+size_t len = strlen (dev);
+
+if (len > 2 && dev[0] == '(' && dev[len - 1] == ')')
+ {
+ dest = xmalloc (len - 1);
+ strncpy (dest, dev + 1, len - 2);
+ dest[len - 2] = '\0';
+ }
+ }
+
+ if (! dest)
+{
+ /* Possibly, the user specified an OS device file. */
+ dest = grub_util_get_grub_dev (dev);
+ if (! dest)
+ grub_util_error (_("Invalid device `%s'.\n"), dev);
+ grub_util_info ("transformed OS device `%s' into GRUB device `%s'",
+ dev, dest);
+}
+
+
/* Read the boot image by the OS service. */
boot_path = grub_util_get_path (dir, boot_file);
boot_size = grub_util_get_image_size (boot_path);
@@ -303,6 +326,7 @@ SETUP (const char *dir,
dest_dev = grub_device_open (dest);
if (! dest_dev)
grub_util_error ("%s", grub_errmsg);
+ free (dest);
core_dev = dest_dev;
--
tg: (b67422d..) u/grub-setup-device (depends on: master)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
В Thu, 28 Nov 2013 18:05:37 + Colin Watson пишет: > On Thu, Nov 28, 2013 at 09:20:17PM +0400, Andrey Borzenkov wrote: > > Not only. If you hit ESC it will not "wait for input according to > > GRUB_TIMEOUT" - it will stop displaying menu. > > No, that's not true in my tests. If you hit Escape while a hidden > timeout is active and GRUB_TIMEOUT is non-zero, it'll display the menu. > Oh, sorry for my English, I see where confusion is. I meant "it will display menu and stay there indefinitely". But documentation says "it will display the menu and wait for input according to `GRUB_TIMEOUT'" which is wrong because timeout is already canceled at this point. > If you can make this happen, please post a detailed test case. > > > I'm not sure whether exposing menu but continuing count down is useful. > > We could let any other key (or specific key - SPACE?) do it. > > I don't think it's very useful, which is why it isn't available in the > new GRUB_TIMEOUT + GRUB_TIMEOUT_STYLE interface; but it was exposed in > the old GRUB_HIDDEN_TIMEOUT + GRUB_TIMEOUT interface so I don't want to > break it entirely. > Anyway it is trivial to add if anyone complaints. Thank you! ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC][PATCH] Allow hotkeys to interrupt hidden menu
В Thu, 28 Nov 2013 18:06:44 +
Colin Watson пишет:
> On Thu, Nov 28, 2013 at 09:22:49PM +0400, Andrey Borzenkov wrote:
> > В Thu, 28 Nov 2013 02:30:56 +
> > Colin Watson пишет:
> > > @item GRUB_HIDDEN_TIMEOUT
> > > @item GRUB_HIDDEN_TIMEOUT_QUIET
> >
> > I suggest removing them from user visible documentation and leaving
> > only as compatibility options in grub-mkconfig. No reason do endorse
> > their usage ("deprecated" is usually was nobody pays attention to).
>
> My concern is that they will probably hang around in people's
> configurations for some time and I would like the documentation to tell
> users what these mysterious things mean.
>
> As a compromise, perhaps we could move them to a separate page?
>
May be collect all deprecated options at the end of list with heading
like "The following options are still accepted for compatibility with
existing configurations but should not be used in new setup anymore" or
similar.
And BTW, we probably need to start collecting NEWS topics - this is
excellent candidate for inclusion :)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] fix using grub device name as install device
On 28.11.2013 22:11, Andrey Borzenkov wrote:
> Shell version of grub-install called grub-setup which resolved
> install device name and called main setup routine. C version of
> grub-install calls main setup routine directly, which leads
> to the error:
>
Do you have a reason for continuing accepting such input? It was
considered wrong way of doing things for quite some while.
> grub2-install: info: grub-bios-setup --verbose --force --skip-fs-probe
> --directory='/boot/grub2/i386-pc' --device-map='/boot/grub2/device.map'
> '(hd2)'.
> grub2-install: info: reading /boot/grub2/i386-pc/boot.img.
> grub2-install: info: reading /boot/grub2/i386-pc/core.img.
> grub2-install: info: root is `(null)', dest is `(hd2)'.
> grub2-install: info: Opening dest.
> grub2-install: info: drive = -1.
> grub2-install: error: disk `(hd2)' not found.
>
> Move resolving of destination device name into main setup routine
> so it is done consistently in both cases.
>
> ---
> util/grub-setup.c | 41 +
> util/setup.c | 26 +-
> 2 files changed, 26 insertions(+), 41 deletions(-)
>
> diff --git a/util/grub-setup.c b/util/grub-setup.c
> index 90b9de0..cc3af5d 100644
> --- a/util/grub-setup.c
> +++ b/util/grub-setup.c
> @@ -209,23 +209,9 @@ DEVICE must be an OS device (e.g. /dev/sda)."),
>NULL, help_filter, NULL
> };
>
> -static char *
> -get_device_name (char *dev)
> -{
> - size_t len = strlen (dev);
> -
> - if (dev[0] != '(' || dev[len - 1] != ')')
> -return 0;
> -
> - dev[len - 1] = '\0';
> - return dev + 1;
> -}
> -
> int
> main (int argc, char *argv[])
> {
> - char *root_dev = NULL;
> - char *dest_dev = NULL;
>struct arguments arguments;
>
>grub_util_host_init (&argc, &argv);
> @@ -264,34 +250,11 @@ main (int argc, char *argv[])
>grub_mdraid1x_init ();
>grub_lvm_init ();
>
> - dest_dev = get_device_name (arguments.device);
> - if (! dest_dev)
> -{
> - /* Possibly, the user specified an OS device file. */
> - dest_dev = grub_util_get_grub_dev (arguments.device);
> - if (! dest_dev)
> -{
> - char *program = xstrdup(program_name);
> - fprintf (stderr, _("Invalid device `%s'.\n"), arguments.device);
> - argp_help (&argp, stderr, ARGP_HELP_STD_USAGE, program);
> - free(program);
> - exit(1);
> -}
> - grub_util_info ("transformed OS device `%s' into GRUB device `%s'",
> - arguments.device, dest_dev);
> -}
> - else
> -{
> - /* For simplicity. */
> - dest_dev = xstrdup (dest_dev);
> - grub_util_info ("Using `%s' as GRUB device", dest_dev);
> -}
> -
>/* Do the real work. */
>GRUB_SETUP_FUNC (arguments.dir ? : DEFAULT_DIRECTORY,
> arguments.boot_file ? : DEFAULT_BOOT_FILE,
> arguments.core_file ? : DEFAULT_CORE_FILE,
> -dest_dev, arguments.force,
> +arguments.device, arguments.force,
> arguments.fs_probe, arguments.allow_floppy);
>
>/* Free resources. */
> @@ -303,8 +266,6 @@ main (int argc, char *argv[])
>free (arguments.dir);
>free (arguments.dev_map);
>free (arguments.device);
> - free (root_dev);
> - free (dest_dev);
>
>return 0;
> }
> diff --git a/util/setup.c b/util/setup.c
> index 337c304..c1de3d2 100644
> --- a/util/setup.c
> +++ b/util/setup.c
> @@ -247,12 +247,13 @@ identify_partmap (grub_disk_t disk __attribute__
> ((unused)),
> void
> SETUP (const char *dir,
> const char *boot_file, const char *core_file,
> - const char *dest, int force,
> + const char *dev, int force,
> int fs_probe, int allow_floppy)
> {
>char *core_path;
>char *boot_img, *core_img, *boot_path;
>char *root = 0;
> + char *dest = 0;
>size_t boot_size, core_size;
> #ifdef GRUB_SETUP_BIOS
>grub_uint16_t core_sectors;
> @@ -269,6 +270,28 @@ SETUP (const char *dir,
> #endif
>bl.last_length = 0;
>
> + {
> +size_t len = strlen (dev);
> +
> +if (len > 2 && dev[0] == '(' && dev[len - 1] == ')')
> + {
> + dest = xmalloc (len - 1);
> + strncpy (dest, dev + 1, len - 2);
> + dest[len - 2] = '\0';
> + }
> + }
> +
> + if (! dest)
> +{
> + /* Possibly, the user specified an OS device file. */
> + dest = grub_util_get_grub_dev (dev);
> + if (! dest)
> + grub_util_error (_("Invalid device `%s'.\n"), dev);
> + grub_util_info ("transformed OS device `%s' into GRUB device `%s'",
> + dev, dest);
> +}
> +
> +
>/* Read the boot image by the OS service. */
>boot_path = grub_util_get_path (dir, boot_file);
>boot_size = grub_util_get_image_size (boot_path);
> @@ -303,6 +326,7 @@ SETUP (const char *dir,
>dest_dev = grub_device_open (dest);
>if (! dest_dev)
> grub_util_error ("%s", grub_errmsg);
> + free (dest);
>
>core_dev = dest_dev;
>
>
Re: [PATCH] fix using grub device name as install device
В Fri, 29 Nov 2013 07:27:06 +0100 Vladimir 'φ-coder/phcoder' Serbinenko пишет: > On 28.11.2013 22:11, Andrey Borzenkov wrote: > > Shell version of grub-install called grub-setup which resolved > > install device name and called main setup routine. C version of > > grub-install calls main setup routine directly, which leads > > to the error: > > > Do you have a reason for continuing accepting such input? It was > considered wrong way of doing things for quite some while. Yes - compatibility. At least openSUSE used this syntax during bootloader configuration (together with maintaining device.map) in past releases, so anyone updating will inherit it. How do you think I hit it in the first place? :) And I do not know how many other distros are affected. Patch does not add any new feature - it is plain regression fix. signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[RFT] LUA build system adjustments
Current LUA status for non-x86 is pretty horrible. Attached is a patch
which fixes some of issues. Could someone test it? Testing on x86 should
be enough.
Could someone propose a test for LUA which could be run as part of
all_functional_test if lua is compiled to avoid regressions in LUA.
diff --git a/lua/Makefile.core.def b/lua/Makefile.core.def
index f646046..416d41f 100644
--- a/lua/Makefile.core.def
+++ b/lua/Makefile.core.def
@@ -28,7 +28,6 @@ module = {
common = contrib/lua/lstrlib.c;
common = contrib/lua/grub_main.c;
common = contrib/lua/grub_lib.c;
- cflags = -Wno-error;
cflags = '$(CFLAGS_POSIX)';
cppflags = '$(CPPFLAGS_POSIX)';
diff --git a/lua/lauxlib.c b/lua/lauxlib.c
index e7e0f47..ab3c869 100644
--- a/lua/lauxlib.c
+++ b/lua/lauxlib.c
@@ -598,12 +598,14 @@ LUALIB_API int luaL_loadfile (lua_State *L, const char *filename) {
c = grub_getc(lf.f);
if (c == '#') { /* Unix exec. file? */
lf.extraline = 1;
-while ((c = grub_getc(lf.f)) != GRUB_EOF && c != '\n') ; /* skip first line */
+while ((c = grub_getc(lf.f)) != GRUB_EOF && c != '\n')
+ ; /* skip first line */
if (c == '\n') c = grub_getc(lf.f);
}
if (c == LUA_SIGNATURE[0] && filename) { /* binary file? */
/* skip eventual `#!...' */
- while ((c = grub_getc(lf.f)) != GRUB_EOF && c != LUA_SIGNATURE[0]) ;
+ while ((c = grub_getc(lf.f)) != GRUB_EOF && c != LUA_SIGNATURE[0])
+ ;
lf.extraline = 0;
}
lf.ungetc = c;
diff --git a/lua/lcode.c b/lua/lcode.c
index 64f726b..05dc3bf 100644
--- a/lua/lcode.c
+++ b/lua/lcode.c
@@ -834,8 +834,12 @@ int luaK_codeABx (FuncState *fs, OpCode o, int a, unsigned int bc) {
void luaK_setlist (FuncState *fs, int base, int nelems, int tostore) {
- int c = (nelems - 1)/LFIELDS_PER_FLUSH + 1;
+ int c;
int b = (tostore == LUA_MULTRET) ? 0 : tostore;
+ if (nelems == 0)
+c = 1;
+ else
+c = ((unsigned) nelems + LFIELDS_PER_FLUSH - 1)/LFIELDS_PER_FLUSH;
lua_assert(tostore != 0);
if (c <= MAXARG_C)
luaK_codeABC(fs, OP_SETLIST, base, b, c);
diff --git a/lua/ldo.h b/lua/ldo.h
index 98fddac..abd0b84 100644
--- a/lua/ldo.h
+++ b/lua/ldo.h
@@ -21,11 +21,11 @@
#define incr_top(L) {luaD_checkstack(L,1); L->top++;}
-#define savestack(L,p) ((char *)(p) - (char *)L->stack)
-#define restorestack(L,n) ((TValue *)((char *)L->stack + (n)))
+#define savestack(L,p) ((TValue *)(p) - (TValue *)L->stack)
+#define restorestack(L,n) ((TValue *)((TValue *)L->stack + (n)))
-#define saveci(L,p) ((char *)(p) - (char *)L->base_ci)
-#define restoreci(L,n) ((CallInfo *)((char *)L->base_ci + (n)))
+#define saveci(L,p) ((CallInfo *)(p) - (CallInfo *)L->base_ci)
+#define restoreci(L,n) ((CallInfo *)((CallInfo *)L->base_ci + (n)))
/* results from luaD_precall */
diff --git a/lua/lobject.h b/lua/lobject.h
index 6234d50..8dd3600 100644
--- a/lua/lobject.h
+++ b/lua/lobject.h
@@ -40,7 +40,7 @@ typedef union GCObject GCObject;
** Common Header for all collectable objects (in macro form, to be
** included in other objects)
*/
-#define CommonHeader GCObject *next; lu_byte tt; lu_byte marked
+#define CommonHeader GCObject __attribute__ ((aligned)) *next; lu_byte tt; lu_byte marked
/*
diff --git a/lua/lstate.c b/lua/lstate.c
index 0c1b97f..2a7964a 100644
--- a/lua/lstate.c
+++ b/lua/lstate.c
@@ -24,9 +24,9 @@
#include "ltm.h"
-#define state_size(x) (sizeof(x) + LUAI_EXTRASPACE)
-#define fromstate(l) (cast(lu_byte *, (l)) - LUAI_EXTRASPACE)
-#define tostate(l) (cast(lua_State *, cast(lu_byte *, l) + LUAI_EXTRASPACE))
+#define state_size(x) (sizeof(x) + LUAI_EXTRASPACE * sizeof (lua_State))
+#define fromstate(l) (cast(lua_State *, (l)) - LUAI_EXTRASPACE)
+#define tostate(l) (cast(lua_State *, cast(lua_State *, l) + LUAI_EXTRASPACE))
/*
diff --git a/lua/luaconf.h b/lua/luaconf.h
index 77e6c19..652e8d1 100644
--- a/lua/luaconf.h
+++ b/lua/luaconf.h
@@ -554,13 +554,48 @@
#define luai_numadd(a,b) ((a)+(b))
#define luai_numsub(a,b) ((a)-(b))
#define luai_nummul(a,b) ((a)*(b))
-#define luai_numdiv(a,b) ((a)/(b))
#if 0
#define luai_nummod(a,b) ((a) - floor((a)/(b))*(b))
#define luai_numpow(a,b) (pow(a,b))
#else
-#define luai_nummod(a,b) ((a) % (b))
+static inline LUA_NUMBER
+luai_numdiv (LUA_NUMBER a, LUA_NUMBER b)
+{
+ int neg = 0;
+ unsigned res;
+ if (a < 0)
+{
+ a = -a;
+ neg = !neg;
+}
+ if (b < 0)
+{
+ b = -b;
+ neg = !neg;
+}
+ res = (unsigned) a / (unsigned) b;
+ return neg ? -res : res;
+}
+
+static inline LUA_NUMBER
+luai_nummod (LUA_NUMBER a, LUA_NUMBER b)
+{
+ int neg = 0;
+ unsigned res;
+ if (a < 0)
+{
+ a = -a;
+ neg = !neg;
+}
+ if (b < 0)
+{
+ b = -b;
+ neg = !neg;
+}
+ res = (unsigned) a % (unsigned) b;
+ return neg ? -res : res;
+}
static inline LUA_NUMBER
luai_numpow (LUA_NUMBER a, LUA_NUMBER b)
@@ -640,7 +675,7 @@ union luai_Cast { double l_d; long l_l; };
** aligned in 16-byte boundaries, then you should add
[RFT] Fix build problems in ntldr-img
Currently ntldr-img build fails on anything else than the most plain
compile on i386 system. Attached patch improves the situation a tiny bit
but build system for ntldr-img stays horrible, the worst being including
of target binary in the host tool. Could someon test that this patch
didn't break anything?
diff --git a/ntldr-img/Makefile.core.common b/ntldr-img/Makefile.core.common
index f46acd5..f5c0c60 100644
--- a/ntldr-img/Makefile.core.common
+++ b/ntldr-img/Makefile.core.common
@@ -6,32 +6,33 @@ g2hdr.bin: g2hdr.img
platform_DATA += g2hdr.bin
CLEANFILES += g2hdr.bin
+g2ldr.mbr: g2ldr.img
+ head -c 8192 $< > $@
+platform_DATA += g2ldr.mbr
+CLEANFILES += g2ldr.mbr
+
grldr.mbr: grldr.img
head -c 8192 $< > $@
CLEANFILES += grldr.mbr
bin2h: contrib/ntldr-img/bin2h.c
- $(CC) $^ -o $@
+ $(BUILD_CC) $(BUILD_CFLAGS) $(BUILD_CPPFLAGS) $(BUILD_LDFLAGS) $^ -o $@
CLEANFILES += bin2h
grub_mbr.h: grldr.mbr bin2h
./bin2h grub_mbr 8192 < $< > $@
CLEANFILES += grub_mbr.h
-grub-ntldr-img: contrib/ntldr-img/grubinst.c contrib/ntldr-img/utils.c grub_mbr.h
- $(CC) -I. -I$(srcdir)/contrib/ntldr-img -DLINUX -o $@ $(srcdir)/contrib/ntldr-img/grubinst.c $(srcdir)/contrib/ntldr-img/utils.c
+grub-ntldr-img$(EXEEXT): contrib/ntldr-img/grubinst.c contrib/ntldr-img/utils.c grub_mbr.h
+ $(HOST_CC) $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(HOST_LDFLAGS) -DGRUB_UTIL=1 -I. -I$(srcdir)/contrib/ntldr-img -DLINUX -o $@ $(srcdir)/contrib/ntldr-img/grubinst.c $(srcdir)/contrib/ntldr-img/utils.c
bin_PROGRAMS += grub-ntldr-img
CLEANFILES += grub-ntldr-img
# Compatibility symlink.
-grubinst: grub-ntldr-img
+grubinst$(EXEEXT): grub-ntldr-img$(EXEEXT)
rm -f $@
$(LN_S) $< $@
noinst_PROGRAMS += grubinst
CLEANFILES += grubinst
-g2ldr.mbr: grub-ntldr-img
- ./grub-ntldr-img --grub2 -o $@
-platform_DATA += g2ldr.mbr
-CLEANFILES += g2ldr.mbr
endif
diff --git a/ntldr-img/Makefile.core.def b/ntldr-img/Makefile.core.def
index a41f4cc..59dd44b 100644
--- a/ntldr-img/Makefile.core.def
+++ b/ntldr-img/Makefile.core.def
@@ -19,3 +19,14 @@ image = {
objcopyflags = '-O binary';
enable = i386_pc;
};
+
+image = {
+ name = g2ldr;
+ i386_pc = contrib/ntldr-img/grldrstart.S;
+ i386_pc = contrib/ntldr-img/ntfsbs.S;
+ i386_pc_ccasflags = '-DGRLDR_MBR -DBOOTGRUB2';
+ i386_pc_ldflags = '$(TARGET_IMG_LDFLAGS)';
+ i386_pc_ldflags = '$(TARGET_IMG_BASE_LDOPT),0x7c00';
+ objcopyflags = '-O binary';
+ enable = i386_pc;
+};
diff --git a/ntldr-img/grldrstart.S b/ntldr-img/grldrstart.S
index 6553926..2f523f9 100644
--- a/ntldr-img/grldrstart.S
+++ b/ntldr-img/grldrstart.S
@@ -1302,7 +1302,7 @@ Entry_32:
. = Entry_32 + 0x03
-#ifdef BOOTGRUB
+#if defined (BOOTGRUB)
.ascii "GRLDR " /* OEM name string (of OS which formatted the disk). */
#endif
@@ -1830,7 +1830,9 @@ msg_BootError_32:
filename_32:
-#ifdef BOOTGRUB
+#ifdef BOOTGRUB2
+ .ascii "G2LDR \0"
+#elif defined (BOOTGRUB)
.ascii "GRLDR \0"
#else
.ascii "KERNEL SYS\0"
@@ -2002,7 +2004,7 @@ Entry_12_16:
. = Entry_12_16 + 0x03
-#ifdef BOOTGRUB
+#ifdef BOOTGRUB
.ascii "GRLDR "
#endif
@@ -2555,7 +2557,9 @@ msg_BootError_12_16:
filename_12_16:
-#ifdef BOOTGRUB
+#ifdef BOOTGRUB2
+ .ascii "G2LDR \0"
+#elif defined (BOOTGRUB)
.ascii "GRLDR \0"
#else
.ascii "KERNEL SYS\0"
@@ -3378,8 +3382,11 @@ msg_No_grldr_ext2:
.ascii "No "
filename_ext2:
+#ifdef BOOTGRUB2
+ .ascii "g2ldr\0"
+#else
.ascii "grldr\0"
-
+#endif
. = Entry_ext2 + 0x1ee
filename_end_ext2:
@@ -3426,9 +3433,7 @@ boot_error_ext2:
. = Entry_ext2 + 0x1fe
.word 0xAA55
-
. = _start1 + 0xA00
-
#define INSIDE_GRLDR
#include "ntfsbs.S"
@@ -5783,4 +5788,3 @@ grldr_signature:
pre_stage2_start:
-
diff --git a/ntldr-img/grubinst.c b/ntldr-img/grubinst.c
index 5989da9..f6a4d84 100644
--- a/ntldr-img/grubinst.c
+++ b/ntldr-img/grubinst.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#ifndef WIN32
@@ -146,7 +147,9 @@ void help(void)
int afg,gfg,def_drive,def_part,time_out,hot_key,part_num;
int def_spt,def_hds,def_ssc,def_tsc;
-char *save_fn,*restore_fn,*boot_file,boot_file_83[12],*key_name;
+char *save_fn,*restore_fn,boot_file_83[12];
+const char *key_name;
+const char *boot_file;
unsigned short load_seg;
static char fn_buf[24];
@@ -284,10 +287,13 @@ void list(int hd)
xe.cur=xe.nxt=0xFF;
fprintf(stderr," # idbaseleng\n");
while (! xd_enum(hd,&xe))
-fprintf(stderr,"%2d %02X%8X%8X\n",xe.cur,xe.dfs,xe.bse,xe.len);
+fprintf(stderr,"%2d %02llX%8llX%8llX\n",xe.cur,
+ (unsigned long long) xe.dfs,
+ (unsigned long long) xe.bse,
+ (unsigned long long) xe.len);
}
-int is_grldr_mbr(char* buf)
+int is_grldr_mbr(unsigned char* buf)
{
int i,n;
@@ -296,13 +302,13 @@ int is_grldr_mbr(char* buf)
while ((i>n) && (buf[i]==0))
i--;
- return (! strcmp(&buf[i-n+1],"Missing MBR-helper."));
+ return (! memcmp(&buf[i-n+1],"Missing MBR-helper.", sizeof("Missing MBR-helpe
Re: [PATCH] fix using grub device name as install device
On 29.11.2013 07:52, Andrey Borzenkov wrote: > В Fri, 29 Nov 2013 07:27:06 +0100 > Vladimir 'φ-coder/phcoder' Serbinenko пишет: > >> On 28.11.2013 22:11, Andrey Borzenkov wrote: >>> Shell version of grub-install called grub-setup which resolved >>> install device name and called main setup routine. C version of >>> grub-install calls main setup routine directly, which leads >>> to the error: >>> >> Do you have a reason for continuing accepting such input? It was >> considered wrong way of doing things for quite some while. > > Yes - compatibility. At least openSUSE used this syntax during > bootloader configuration (together with maintaining device.map) in past > releases, so anyone updating will inherit it. How do you think I hit it > in the first place? :) And I do not know how many other distros are > affected. > You're right. And as much as I hate this syntax, we're stuck with it. Go ahead signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
