BtrFS available in experimental

BtrFS available in experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hello, all. It seems incresingly unpractical to assume that btrfs legal
issues will be resolved. So I using this specification :
https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format
implemented a reader. I haven't used any Oracle code for this. Code is
fresh from typing fingers. It may or may not work for. I'm aware of some
possibilities the code may hang parsing an incorrect BtrFS. Currently
lacking points:
- no multidevice
- no symlinks
- no encryption, encoding or compressing
- no prealloc extents (doesn't look like we need them at all)
- grub-mkrelpath isn't adjust for /<subvolume>/ prefix

The syntax on btrfs is
/subvolume/standard_path
the root subvolume is named "default"
Due to checksumming save_env doesn't work (same problem as on ZFS)
Enjoy

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: BtrFS available in experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]


On 12/01/2010 04:51 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Hello, all. It seems incresingly unpractical to assume that btrfs legal
> issues will be resolved. So I using this specification :
> https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format
> implemented a reader. I haven't used any Oracle code for this. Code is
> fresh from typing fingers. It may or may not work for. I'm aware of some
> possibilities the code may hang parsing an incorrect BtrFS. Currently
> lacking points:
> - no multidevice
> - no symlinks
> - no encryption, encoding or compressing
> - no prealloc extents (doesn't look like we need them at all)
> - grub-mkrelpath isn't adjust for /<subvolume>/ prefix
>
>   
Several bugs fixed.
grub-mkrelpath adjust for both bindmount and btrfs subvolume mount
> The syntax on btrfs is
> /subvolume/standard_path
> the root subvolume is named "default"
>   
This part was removed. Unlike in ZFS where subvolumes and directories
are in different namespaces, in btrfs they share the same. so /default/
was removed.
> Due to checksumming save_env doesn't work (same problem as on ZFS)
> Enjoy
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Need --divide flag for assembly of startup.S on some platforms

[Seth Goldberg]

Hi,

   When assembling grub-core/kern/i386/pc/startup.S, gas on some platforms 
chokes on this line:

        movl    $((LOCAL(bypass_table_end) - LOCAL(bypass_table)) / 2), %ecx

  Because on non i386-linux targets, '/' is used as a comment delimiter for 
compatibility purposes.  This can be overridden with the --divide switch.

   Since the default for gas on these platforms is to use he division operator 
as a comment delimiter, the "-Wa,--divide" flags need to be passed on the 
gcc command line when assembling such files.

  --S

Re: Need --divide flag for assembly of startup.S on some platforms

[Colin Watson]

On Thu, Dec 02, 2010 at 01:15:10PM -0800, Seth Goldberg wrote:
>   When assembling grub-core/kern/i386/pc/startup.S, gas on some platforms 
> chokes on this line:
>
>        movl    $((LOCAL(bypass_table_end) - LOCAL(bypass_table)) / 2), %ecx
>
>  Because on non i386-linux targets, '/' is used as a comment delimiter 
> for compatibility purposes.  This can be overridden with the --divide 
> switch.
>
>   Since the default for gas on these platforms is to use he division 
> operator as a comment delimiter, the "-Wa,--divide" flags need to be 
> passed on the gcc command line when assembling such files.

Can we just use >> 1 instead?

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Need --divide flag for assembly of startup.S on some platforms

[Seth Goldberg]

On 12/ 2/10 01:29 PM, Colin Watson wrote:
> On Thu, Dec 02, 2010 at 01:15:10PM -0800, Seth Goldberg wrote:
>>    When assembling grub-core/kern/i386/pc/startup.S, gas on some platforms
>> chokes on this line:
>>
>>         movl    $((LOCAL(bypass_table_end) - LOCAL(bypass_table)) / 2), %ecx
>>
>>   Because on non i386-linux targets, '/' is used as a comment delimiter
>> for compatibility purposes.  This can be overridden with the --divide
>> switch.
>>
>>    Since the default for gas on these platforms is to use he division
>> operator as a comment delimiter, the "-Wa,--divide" flags need to be
>> passed on the gcc command line when assembling such files.
> Can we just use>>  1 instead?

   Sure, that works for me :).

  --S

Re: Need --divide flag for assembly of startup.S on some platforms

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 12/02/2010 10:29 PM, Colin Watson wrote:
> On Thu, Dec 02, 2010 at 01:15:10PM -0800, Seth Goldberg wrote:
>   
>>   When assembling grub-core/kern/i386/pc/startup.S, gas on some platforms 
>> chokes on this line:
>>
>>        movl    $((LOCAL(bypass_table_end) - LOCAL(bypass_table)) / 2), %ecx
>>
>>  Because on non i386-linux targets, '/' is used as a comment delimiter 
>> for compatibility purposes.  This can be overridden with the --divide 
>> switch.
>>
>>   Since the default for gas on these platforms is to use he division 
>> operator as a comment delimiter, the "-Wa,--divide" flags need to be 
>> passed on the gcc command line when assembling such files.
>>     
> Can we just use >> 1 instead?
>
>   
This was my first thought. But for maintenance reasons it would be
better if we can make all platforms behave the same. Can we just
inconditionally add -Wa,--divide to TARGET_ASFLAGS ?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Error building grub-emu (gnulib/progname.c)

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1635 bytes --]

Hi,

  While trying to build grub-emu, I hit this:

/usr/gcc/4.3/bin/gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W -I../../include -I../include  -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=I386_EMU -DGRUB_FILE=\"gnulib/progname.c\" -I. -I../../grub-core -I.. -I../.. -I../../include -I../include   -I../grub-core/gnulib -I../../grub-core/gnulib  -I/usr/sfw/include -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-common -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -DUSE_ASCII_FAILBACK=1 -DHAVE_UNIFONT_WIDTHSPEC=1         -ffreestanding -fno-common -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT gnulib/kernel_exec-progname.o -MD -MP -MF gnulib/.deps-core/kernel_exec-progname.Tpo -c -o gnulib/kernel_exec-progname.o `test -f 'gnulib/progname.c' || echo '../../grub-core/'`gnulib/progname.c
In file included from ../../grub-core/gnulib/progname.c:28:
../grub-core/gnulib/string.h:456: error: expected ‘;’, ‘,’ or ‘)’ before ‘__dest’

  The offending line:
_GL_FUNCDECL_SYS (mempcpy, void *,
                   (void *restrict __dest, void const *restrict __src,
                    size_t __n)
                   _GL_ARG_NONNULL ((1, 2)));

  uses the restrict keyword, which is not enabled by default with GCC 4.3.3, 
which I'm using.  Adding -std=c99 allowed this to compile.  So, a configure 
test should be added to enable this flag for versions of GCC that we support, 
but that do not enable c99 keywords by default.

  Thanks,
  --S

Re: Error building grub-emu (gnulib/progname.c)

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1912 bytes --]


   Trying that led to a number of other build failures (in grub-core/fs), so 
this needs to be better thought out.

  --S

Quoting Seth Goldberg, who wrote the following on Thu, 2 Dec 2010:

> Hi,
>
> While trying to build grub-emu, I hit this:
>
> /usr/gcc/4.3/bin/gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W 
> -I../../include -I../include  -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=I386_EMU 
> -DGRUB_FILE=\"gnulib/progname.c\" -I. -I../../grub-core -I.. -I../.. 
> -I../../include -I../include   -I../grub-core/gnulib -I../../grub-core/gnulib 
> -I/usr/sfw/include -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes 
> -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 
> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-common -m32 
> -fno-stack-protector -mno-stack-arg-probe -Werror -DUSE_ASCII_FAILBACK=1 
> -DHAVE_UNIFONT_WIDTHSPEC=1         -ffreestanding -fno-common -Wno-undef 
> -Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT 
> gnulib/kernel_exec-progname.o -MD -MP -MF 
> gnulib/.deps-core/kernel_exec-progname.Tpo -c -o 
> gnulib/kernel_exec-progname.o `test -f 'gnulib/progname.c' || echo 
> '../../grub-core/'`gnulib/progname.c
> In file included from ../../grub-core/gnulib/progname.c:28:
> ../grub-core/gnulib/string.h:456: error: expected ‘;’, ‘,’ or ‘)’ before 
> ‘__dest’
>
> The offending line:
> _GL_FUNCDECL_SYS (mempcpy, void *,
>                  (void *restrict __dest, void const *restrict __src,
>                   size_t __n)
>                  _GL_ARG_NONNULL ((1, 2)));
>
> uses the restrict keyword, which is not enabled by default with GCC 4.3.3, 
> which I'm using.  Adding -std=c99 allowed this to compile.  So, a configure 
> test should be added to enable this flag for versions of GCC that we support, 
> but that do not enable c99 keywords by default.
>
> Thanks,
> --S
>

Re: Error building grub-emu (gnulib/progname.c)

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2729 bytes --]


Adding:

#if __STDC_VERSION__ >= 199901L
_GL_FUNCDECL_SYS (mempcpy, void *,
                   (void *restrict __dest, void const *restrict __src,
                    size_t __n)
                   _GL_ARG_NONNULL ((1, 2)));
#else
_GL_FUNCDECL_SYS (mempcpy, void *,
                   (void *__dest, void const *__src,
                    size_t __n)
                   _GL_ARG_NONNULL ((1, 2)));
#endif


  Seems to get me around it, but it's a bit of a hack (since it doesn't 
address other declarations in the same file that include restrict)  #defining 
restrict won't work either because the restrict text is inside a parameter to 
another macro expansion.

  --S

Quoting Seth Goldberg, who wrote the following on Thu, 2 Dec 2010:

>
>  Trying that led to a number of other build failures (in grub-core/fs), so 
> this needs to be better thought out.
>
> --S
>
> Quoting Seth Goldberg, who wrote the following on Thu, 2 Dec 2010:
>
>> Hi,
>> 
>> While trying to build grub-emu, I hit this:
>> 
>> /usr/gcc/4.3/bin/gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W 
>> -I../../include -I../include  -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=I386_EMU 
>> -DGRUB_FILE=\"gnulib/progname.c\" -I. -I../../grub-core -I.. -I../.. 
>> -I../../include -I../include   -I../grub-core/gnulib 
>> -I../../grub-core/gnulib -I/usr/sfw/include -Os -Wall -W -Wshadow 
>> -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g 
>> -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse 
>> -mno-sse2 -mno-3dnow -fno-common -m32 -fno-stack-protector 
>> -mno-stack-arg-probe -Werror -DUSE_ASCII_FAILBACK=1 
>> -DHAVE_UNIFONT_WIDTHSPEC=1         -ffreestanding -fno-common -Wno-undef 
>> -Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT 
>> gnulib/kernel_exec-progname.o -MD -MP -MF 
>> gnulib/.deps-core/kernel_exec-progname.Tpo -c -o 
>> gnulib/kernel_exec-progname.o `test -f 'gnulib/progname.c' || echo 
>> '../../grub-core/'`gnulib/progname.c
>> In file included from ../../grub-core/gnulib/progname.c:28:
>> ../grub-core/gnulib/string.h:456: error: expected ‘;’, ‘,’ or ‘)’ before 
>> ‘__dest’
>> 
>> The offending line:
>> _GL_FUNCDECL_SYS (mempcpy, void *,
>>                  (void *restrict __dest, void const *restrict __src,
>>                   size_t __n)
>>                  _GL_ARG_NONNULL ((1, 2)));
>> 
>> uses the restrict keyword, which is not enabled by default with GCC 4.3.3, 
>> which I'm using.  Adding -std=c99 allowed this to compile.  So, a configure 
>> test should be added to enable this flag for versions of GCC that we 
>> support, but that do not enable c99 keywords by default.
>> 
>> Thanks,
>> --S
>

Another error building grub-emu (gnulib/error.c)

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1233 bytes --]



/usr/gcc/4.3/bin/gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W 
-I../../include -I../include  -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=I386_EMU 
-DGRUB_FILE=\"gnulib/error.c\" -I. -I../../grub-core -I.. -I../.. 
-I../../include -I../include   -I../grub-core/gnulib -I../../grub-core/gnulib 
-I/usr/sfw/include -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes 
-Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 
-falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-common -m32 
-fno-stack-protector -mno-stack-arg-probe -Werror -DUSE_ASCII_FAILBACK=1 
-DHAVE_UNIFONT_WIDTHSPEC=1         -ffreestanding -fno-common -Wno-undef 
-Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT 
gnulib/kernel_exec-error.o -MD -MP -MF gnulib/.deps-core/kernel_exec-error.Tpo 
-c -o gnulib/kernel_exec-error.o `test -f 'gnulib/error.c' || echo 
'../../grub-core/'`gnulib/error.c
In file included from ../grub-core/gnulib/unistd.h:98,
                  from ../../grub-core/gnulib/error.c:89:
../grub-core/gnulib/getopt.h:195: error: redefinition of ‘struct option’


  Because the struct option in the GNULIB getopt.h is clashing with that 
defined in /usr/include/getopt.h.

  --S

Re: Another error building grub-emu (gnulib/error.c)

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1518 bytes --]


  This is because on Solaris, struct option cannot be conditionally excluded 
from the header.  So, on such systems, the host's getopt.h should not be 
included.

  --S

Quoting Seth Goldberg, who wrote the following on Thu, 2 Dec 2010:

>
>
> /usr/gcc/4.3/bin/gcc -DHAVE_CONFIG_H -I. -I../../grub-core -I..  -Wall -W 
> -I../../include -I../include  -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=I386_EMU 
> -DGRUB_FILE=\"gnulib/error.c\" -I. -I../../grub-core -I.. -I../.. 
> -I../../include -I../include   -I../grub-core/gnulib -I../../grub-core/gnulib 
> -I/usr/sfw/include -Os -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes 
> -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 
> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-common -m32 
> -fno-stack-protector -mno-stack-arg-probe -Werror -DUSE_ASCII_FAILBACK=1 
> -DHAVE_UNIFONT_WIDTHSPEC=1         -ffreestanding -fno-common -Wno-undef 
> -Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT 
> gnulib/kernel_exec-error.o -MD -MP -MF 
> gnulib/.deps-core/kernel_exec-error.Tpo -c -o gnulib/kernel_exec-error.o 
> `test -f 'gnulib/error.c' || echo '../../grub-core/'`gnulib/error.c
> In file included from ../grub-core/gnulib/unistd.h:98,
>                 from ../../grub-core/gnulib/error.c:89:
> ../grub-core/gnulib/getopt.h:195: error: redefinition of ‘struct option’
>
>
> Because the struct option in the GNULIB getopt.h is clashing with that 
> defined in /usr/include/getopt.h.
>
> --S

Re: BtrFS available in experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On 12/02/2010 03:41 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 12/01/2010 04:51 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> Hello, all. It seems incresingly unpractical to assume that btrfs legal
>> issues will be resolved. So I using this specification :
>> https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format
>> implemented a reader. I haven't used any Oracle code for this. Code is
>> fresh from typing fingers. It may or may not work for. I'm aware of some
>> possibilities the code may hang parsing an incorrect BtrFS. Currently
>> lacking points:
>> - no multidevice
>>     
Done. RAID0, RAID1 and RAID10 are supported. BtrFS doesn't seem to
currently support anything more.
Note that the redundancy of RAID1(0) isn't used and current code just
read the first device. Also on every mount of multi-device btrfs all the
disks are rescanned. A cache is needed.
>> - no symlinks
>>     
Implemented
>> - no encryption, encoding or compressing
>>     
ZLIB is now supported. BtrFS doesn't seem to support anything more.
>> - no prealloc extents (doesn't look like we need them at all)
>> - grub-mkrelpath isn't adjust for /<subvolume>/ prefix
>>
>>   
>>     
> Several bugs fixed.
> grub-mkrelpath adjust for both bindmount and btrfs subvolume mount
>   
As you can see it looks like all current BtrFS features are supported.
Remaining are speed optimisations (e.g. device assignment cache,
buffering,... ), robustness increase (check for faulty trees, oprionally
checksums) and of course testing, debugging and maintaining.
>> The syntax on btrfs is
>> /subvolume/standard_path
>> the root subvolume is named "default"
>>   
>>     
> This part was removed. Unlike in ZFS where subvolumes and directories
> are in different namespaces, in btrfs they share the same. so /default/
> was removed.
>   
>> Due to checksumming save_env doesn't work (same problem as on ZFS)
>> Enjoy
>>
>>   
>>     
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Need LARGEFILE_SOURCE && _FILE_OFFSET_BITS=64

[Seth Goldberg]

Hi,

   In testing grub-emu after a merge, I was getting weird behavior whereby a 
zfs volume could not be properly read.  It was failing because, after a lot of 
painful debugging, I discovered that the offsets issued to the underlying host 
disk device were wrong, because the grub-emu was not build 
largefile-aware on platform on which I was testing.  grub-emu should be built 
with -DLARGEFILE_SOURCE and _FILE_OFFSET_BITS=64 so that off_t will be defined 
as a 64-bit type and calls like lseek will work with large files (and 
devices).  So, I think a configure test for this for the emu target is 
essential.  Note that most major platforms in hostdisk.c are covered by their 
own #ifdef'ed code -- it's the common case of:

     off_t offset = (off_t) sector << GRUB_DISK_SECTOR_BITS;

     if (lseek (fd, offset, SEEK_SET) != offset)
       {
         grub_error (GRUB_ERR_BAD_DEVICE, "cannot seek `%s'", map[disk->id].device);
         close (fd);
         return -1;
       }

  that exposes the problem, since without LARGEFILE_SOURCE and 
_FILE_OFFSET_BITS, off_t defaults to a 32-bit quantity.

  --S

Re: Need LARGEFILE_SOURCE && _FILE_OFFSET_BITS=64

[Colin Watson]

On Fri, Dec 03, 2010 at 01:20:13PM -0800, Seth Goldberg wrote:
>   In testing grub-emu after a merge, I was getting weird behavior whereby 
> a zfs volume could not be properly read.  It was failing because, after a 
> lot of painful debugging, I discovered that the offsets issued to the 
> underlying host disk device were wrong, because the grub-emu was not 
> build largefile-aware on platform on which I was testing.  grub-emu 
> should be built with -DLARGEFILE_SOURCE and _FILE_OFFSET_BITS=64 so that 
> off_t will be defined as a 64-bit type and calls like lseek will work 
> with large files (and devices).  So, I think a configure test for this 
> for the emu target is essential.

We actually have AC_SYS_LARGEFILE in configure.ac already, which is
supposed to append appropriate options to (slightly oddly) CC.  Now,
hostdisk.c is built with TARGET_CC instead; but TARGET_CC should be set
to CC when building the emu target, if I'm reading this right, because
it doesn't count as cross-compilation.

Are you setting CC by hand?  Could I see the output of configure?

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Need --divide flag for assembly of startup.S on some platforms

[Colin Watson]

On Thu, Dec 02, 2010 at 10:42:10PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 12/02/2010 10:29 PM, Colin Watson wrote:
> > On Thu, Dec 02, 2010 at 01:15:10PM -0800, Seth Goldberg wrote:
> >>   Since the default for gas on these platforms is to use he division 
> >> operator as a comment delimiter, the "-Wa,--divide" flags need to be 
> >> passed on the gcc command line when assembling such files.
> >
> > Can we just use >> 1 instead?
> 
> This was my first thought. But for maintenance reasons it would be
> better if we can make all platforms behave the same. Can we just
> inconditionally add -Wa,--divide to TARGET_ASFLAGS ?

(Only on i386, since the existence of the --divide option is
machine-dependent.)

It'd be a substantial bump in our binutils requirement.  Right now,
INSTALL says that we require GNU binutils 2.9.1.0.23 or later.  As far
as I can make out from
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-i386.c?cvsroot=src,
--divide was added in binutils 2.17.  Before that, if I'm reading the
diff correctly, "/" unconditionally introduced a comment on certain
platforms.

So, is it better to require binutils 2.17, or to accept the maintenance
burden of avoiding the / operator in i386 assembly?  My instinct remains
the latter, I think - I have no idea what version of binutils is in
place on our various supported platforms, and I'm not even sure how to
go about finding out, so raising it is a bit scary for me.  I'm used to
platforms that stay pretty current on the GNU toolchain, but I know not
all platforms are like that.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Need --divide flag for assembly of startup.S on some platforms

[Colin Watson]

On Sat, Dec 04, 2010 at 03:47:53PM +0000, Colin Watson wrote:
> So, is it better to require binutils 2.17, or to accept the maintenance
> burden of avoiding the / operator in i386 assembly?  My instinct remains
> the latter, I think - I have no idea what version of binutils is in
> place on our various supported platforms, and I'm not even sure how to
> go about finding out, so raising it is a bit scary for me.  I'm used to
> platforms that stay pretty current on the GNU toolchain, but I know not
> all platforms are like that.

I've committed a change switching to >> following discussion on IRC
(summary: I grepped all our .S files and this was the only occurrence of
a division operator).

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Need LARGEFILE_SOURCE && _FILE_OFFSET_BITS=64

[Seth Goldberg]

Hi,

Quoting Colin Watson, who wrote the following on Sat, 4 Dec 2010:

> On Fri, Dec 03, 2010 at 01:20:13PM -0800, Seth Goldberg wrote:
>>   In testing grub-emu after a merge, I was getting weird behavior whereby
>> a zfs volume could not be properly read.  It was failing because, after a
>> lot of painful debugging, I discovered that the offsets issued to the
>> underlying host disk device were wrong, because the grub-emu was not
>> build largefile-aware on platform on which I was testing.  grub-emu
>> should be built with -DLARGEFILE_SOURCE and _FILE_OFFSET_BITS=64 so that
>> off_t will be defined as a 64-bit type and calls like lseek will work
>> with large files (and devices).  So, I think a configure test for this
>> for the emu target is essential.
>
> We actually have AC_SYS_LARGEFILE in configure.ac already, which is
> supposed to append appropriate options to (slightly oddly) CC.  Now,
> hostdisk.c is built with TARGET_CC instead; but TARGET_CC should be set
> to CC when building the emu target, if I'm reading this right, because
> it doesn't count as cross-compilation.
>
> Are you setting CC by hand?  Could I see the output of configure?

   Sorry about that -- I did a bit more digging and now I think I've found the 
true culprit.  When building hostdisk.c for use in grub-emu, GRUB_UTIL is not 
defined AND GRUB_MACHINE *is* defined (to I386_EMU).  This causes the config.h 
test (below) to fail, and, consequently config-util.h is not #included when 
building the actual emulator (this explains why grub-fstest continued to work 
properly, even when built while configured for an emulator build).

#if defined (GRUB_UTIL) || !defined (GRUB_MACHINE) <-- But unsatisfied
#include <config-util.h>
#define NESTED_FUNC_ATTR
#else
...

  --S