Currently, the install-static target only installs the statically
compiled tools. However, some programs outside of btrfs-progs (for
example docker) link with the btrfs libraries. If such programs want to
link statically against the btrfs-progs library, then this library
should be installed by "install-static". Indeed, "make install" cannot
be used if the support for shared library is not enabled.
Pull-request: #211
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Gustavo: Rebase for btrfs-progs 4.7.2]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
[Vincent: Rebase for btrfs-progs 4.10]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[baruch: Rebase for btrfs-progs 4.16]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/btrfs-progs/0001-Makefile-install-static-library-and-headers-in-insta.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Avoid introducing new cases of implicit fallthrough by having this flag
always set, though a conditional check is needed to avoid build breakage
on older compilers or on CI.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Upstream commit 997fa5ba1e14b52c554fb03ce39e579e6f27b90c,
git repository: git://github.com/BLAKE2/BLAKE2
The reference implemetation added in this patch is unchanged and will be
modified only to compile in current code base and with minimal other
modifications in case of future sync with upstream code. IOW, the coding
style should stay as-is and does not conform to the other btrfs-progs
code. This is an exception for xxhash and sha256 code as well.
Signed-off-by: David Sterba <dsterba@suse.com>
Add the definition to the checksum types and let mkfs accept it.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
A simple tool to microbenchmark performance of the hashes. Uses rdtsc
for timing, so works only on x86_64.
$ make hash-speedtest
$ ./hash-speedtest [iterations]
Block size: 4096
Iterations: 100000
NULL-NOP: cycles: 56061823, c/i 560
NULL-MEMCPY: cycles: 61296469, c/i 612
CRC32C: cycles: 179961796, c/i 1799
XXHASH: cycles: 138434590, c/i 1384
Signed-off-by: David Sterba <dsterba@suse.com>
The SHA256 is going to be used in the future, so this makes it a second
user and we also have the appropriate directory now.
Signed-off-by: David Sterba <dsterba@suse.com>
With the introduction of xxhash64 to btrfs-progs we created a crypto/
directory for all the hashes used in btrfs (although no
cryptographically secure hash is there yet).
Move the crc32c implementation from kernel-lib/ to crypto/ as well so we
have all hashes consolidated.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
The libbtrfs-test simulated build happens outside of the source
repository, but sometimes the system library is used instead of the repo
one. When -rpath does not work, force the correct library by LD_PRELOAD.
Signed-off-by: David Sterba <dsterba@suse.com>
Several people reported build breakage of snapper, due to missing
symbols in libbtrfs.so. Move the objects to the library objects, now we
don't have to worry about the new exports as the libbtrfs.sym is
unchanged. And there are no new .h files being exported though there are
the .o files in the library.
Issue: #214
Link: https://github.com/openSUSE/snapper/issues/500
Signed-off-by: David Sterba <dsterba@suse.com>
The shared library exports many functions that are not supposed to be
public, like rb-tree, crc32c or internal helpers but as this has been
potentially in use we should at least make a list. There's only a
subset being used by the snapper project.
Export majority of current symbols visible in libbtrfs so any future
additions to libbtrfs objects are automatically hidden and don't pollute
the namespace further.
Note that all projects should switch to libbtrfsutil rather than
libbtrfs that exists for historical reasons and will be deprecated in
the future.
Signed-off-by: David Sterba <dsterba@suse.com>
A user reports that some symbols are missing from libbtrfs, eg.
radix_tree_init. This is correct and there are few more. The headers
exported through the library all need the respective object files.
The sources are GPL so is libbtrfs, which is known
Issue: #205
Signed-off-by: David Sterba <dsterba@suse.com>
Build several standalone tools into one binary and switch the function
by name (symlink or hardlink).
* btrfs
* mkfs.btrfs
* btrfs-image
* btrfs-convert
* btrfstune
The static target is also supported. The name of resulting boxed
binaries is btrfs.box and btrfs.box.static . All the binaries can be
built at the same time without prior configuration.
text data bss dec hex filename
822454 27000 19724 869178 d433a btrfs
927314 28816 20812 976942 ee82e btrfs.box
2067745 58004 44736 2170485 211e75 btrfs.static
2627198 61724 83800 2772722 2a4ef2 btrfs.box.static
File sizes:
857496 btrfs
968536 btrfs.box
2141400 btrfs.static
2704472 btrfs.box.static
Standalone utilities:
512504 btrfs-convert
495960 btrfs-image
471224 btrfstune
491864 mkfs.btrfs
1747720 btrfs-convert.static
1411416 btrfs-image.static
1304256 btrfstune.static
1361696 mkfs.btrfs.static
So the shared 900K binary saves ~2M, or ~5.7M for static build.
Signed-off-by: David Sterba <dsterba@suse.cz>
Add structures and API for unified output definition and multiple
formatting backends. Currently there's plain text and json.
The format of each row is defined in struct rowspec, selected using a
key and formatted according to the type. There are extended types for
eg. UUID or pretty size, while direct printf format specifiers work too.
Due to different nature of the outputs, the context structure members
are not always used.
* text output mostly uses indentation and formats the name to a given
width
* json output tracks nesting depth and keeps stack of previous groups
(list or array) and how many member have been printed, as the
separators are allowed only between values and must not preced the
group closing bracket
the nesting depth is hardcoded to 16, counting the global group
The API provides functions to print simple values and some helpers to
format more complex structures.
Signed-off-by: David Sterba <dsterba@suse.com>
Create directory for all sources that can be used by anything that's not
rellated to a relevant kernel part, all common functions, helpers,
utilities that do not fit any other specific category.
The traditional location would be probably lib/ with all things that are
statically linked to the main binaries, but we have libbtrfs and
libbtrfsutil so this would be confusing.
Signed-off-by: David Sterba <dsterba@suse.com>
This is first instance of commands files moving to a separate directory,
that will be cmds/, thus the files can drop the prefix. We can further
split files into specific parts of a given command. The quota file was
selected as the smallest.
Signed-off-by: David Sterba <dsterba@suse.com>
Our build allows easy definition of CFLAGs that apply only to a given
file, like cmds_restore_cflags and cmds-restore.c .
This is done by series of transformations that convert the file name to
a variable name, when that is defined it's used.
To support files in directories outside of the top level we need to
convert the / too. The function 'subst' supports only a single string,
so they have to be nested.
Signed-off-by: David Sterba <dsterba@suse.com>
Gcc 9 adds the flag to default warnings and this produces a lot of
warnings that don't seem to be harmful as we know the address is
aligned, but this could be hidden in the function call chain.
It's still available under W=1.
Issue: #180
Signed-off-by: David Sterba <dsterba@suse.com>
libbtrfs.so already has user's LDFLAGS applied. The change also applies
those to libbtrfsutil.so. A separate variable is used for that though it
currently only copies LDFLAGS. This is to make it obvious that
libbtrfsutils is a standalone library.
Reported-by: Michał Górny
Bug: https://bugs.gentoo.org/686284
Pull-request: #172
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
Adds Make variables EXTRA_PYTHON_CFLAGS and EXTRA_PYTHON_LDFLAGS which
can be used to pass CFLAGS and LDFLAGS respectively when building the
Python library.
This is required to support reproducible builds, as there are often
compiler and linker flags that must be passed in order to generate
reproducible output (e.g. -fdebug-prefix-map)
Pull-request: #176
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Provide an 'etags' make target to create tags in the Emacs etags
format, similar to the 'tags' target for VIM's ctags.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba