similar to: core/fs/btrfs/btrfs.h correction

gcc complains about the size of the constant of BTRFS_MAGIC_N. It is a 64bit value, so it needs the ULL suffix. Signed-off-by: MartinS <ams at ludd.ltu.se> --- diff --git a/core/fs/btrfs/btrfs.h b/core/fs/btrfs/btrfs.h index 1568e4d..8f519a9 100644 --- a/core/fs/btrfs/btrfs.h +++ b/core/fs/btrfs/btrfs.h @@ -32,7 +32,7 @@ typedef u64 __le64; #define BTRFS_MAGIC "_BHRfS_M"

Hi, As I use btrfs as root FS, I wanted fstype to be able to recognize it. The following patch add support for this FS. Regards, benjamin Signed-off-by: Benjamin Cama <benoar at free.fr> --- diff --git a/usr/kinit/fstype/btrfs_fs.h b/usr/kinit/fstype/btrfs_fs.h new file mode 100644 index 0000000..e1f933e --- /dev/null +++ b/usr/kinit/fstype/btrfs_fs.h @@ -0,0 +1,51 @@ +#ifndef

X-Original-In-Reply-To: <CAD0Rxe=5uLCWQ+jfj1J6zepDzqx0vAiBREiwiKOih59MKgBDHg at mail.gmail.com> X-Previous: http://www.syslinux.org/archives/2015-January/023070.html On Mon, Jan 05, 2015 at 08:59:57PM -0500, Gene Cumm wrote: > On Sat, Jan 3, 2015 at 1:21 PM, Geert Stappers wrote: > > On Thu, Jan 01, 2015 at 09:48:16AM -0500, Gene Cumm wrote: > > >> I'm planning on

hello hpa, current patch queue for review, please pull: git pull git://git.debian.org/users/maks/klibc.git maks Aurelien Jarno (1): [klibc] sh4: syscalls fixes Benjamin Cama (1): [klibc] fstype: btrfs size endianness fix Thorsten Glaser (1): [klibc] add getrusage() maximilian attems (3): [klibc] resume: silence warning on resume try [klibc] bootp_packet.h minor

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

So both Liu and I made huge messes of find_lock_delalloc_range trying to fix stuff, me first by fixing extent size, then him by fixing something I broke and then me again telling him to fix it a different way. So this is obviously a candidate for some testing. This patch adds a pseudo fs so we can allocate fake inodes for tests that need an inode or pages. Then it addes a bunch of tests to make

hello hpa, here my birthday submission :) please pull: git pull git://git.debian.org/users/maks/klibc.git maks Sam fixed a longstanding x86_32 build bug, thus it seems a good time to flush the queue of the piled up patches, the shortlog tells it: Aurelien Jarno (1): [klibc] sh4: syscalls fixes Benjamin Cama (1): [klibc] fstype: btrfs size endianness fix Mike Waychison (2):

In trying to track down a weird tree log problem I wanted to make sure that the free space cache was actually valid, which we currently have no way of doing. So this patch adds a bunch of support for the free space cache code and then a checker to fsck. Basically we go through and if we can actually load the free space cache then we will walk the extent tree and verify that the free space cache

Hi, I've some troubles setting up the dict based quota plugin for mdbox, it always returns a error when lmtp tries to deliver an e-mail: Apr 8 12:40:16 mb07 dovecot: lmtp(3001, asmarre at ull.es): Error: fstat(/sharedfs/10.4.1.107/ull.es/54/asmarre/dovecot-quota.lock) failed: No such file or directory Apr 8 12:40:16 mb07 dovecot: lmtp(3001, asmarre at ull.es): Error: file dict commit:

I just compiled the two attached files in 32-bit mode and ran it. It printed efcdab8967452301. I verified via objdump that the my_bswap function contains the follow assembly which I believe matches the assembly you linked to on godbolt. _my_bswap: 1f70: 55 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8

share/compat.h contains the following code: /* adjust for compilers that can't understand using LLU suffix for uint64_t literals */ #ifdef _MSC_VER #define FLAC__U64L(x) x #else #define FLAC__U64L(x) x##LLU #endif I tested MSVS 2005 and indeed it doesn't support LLU suffix, but it can compile a code with ULL suffix. Also, http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html mentions ?ULL?

Some programs like btrfsck should not be run on a mounted filesystem. This patch adds a check in btrfs_open_devices() for the mount status of every device belonging to the filesystem. The function check_mount() gets improved support for loopback devices. It now detects if the program is run on the file that is being used by the loopback device. Signed-off-by: Andi Drebes

Hi @ll, targetting i386, LLVM/clang generates wrong code for the following functions: unsigned long __bswapsi2 (unsigned long ul) { return (((ul) & 0xff000000ul) >> 3 * 8) | (((ul) & 0x00ff0000ul) >> 8) | (((ul) & 0x0000ff00ul) << 8) | (((ul) & 0x000000fful) << 3 * 8); } unsigned long long __bswapdi2(unsigned long

Hi gang, I was a little surprised to see that patch go by recently which fixed an endian bug. I went to see how sparse checking looked and it was.. broken. I got it going again in my Fedora environment. Most of the patches are just cleanups, but there *were* three real bugs lurking in all that sparse warning spam. So I maintain that it''s worth our time to keep it going and fix

Hi All, I've been building and testing FLAC and have run a problem. I get a number of 'integer constant out of range' warnings during the make, and these give rise to failures in the test suite: testing zeroes, raw_uint32*... FAILED pattern match testing process_until_end_of_stream()... 0... 1... 2... ERROR: metadata block mismatch for example. The problem is that gcc

bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using

Yeah I had a think about it, and I think intrinsics are the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the

On 12 June 2010 00:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: >> Hi Eli, >> >> On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote: