IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Those are all consumed by our parser, so they all support comments.
I was considering whether they should have a license header at all,
but in the end I decided to add it because those files are often created
by copying parts of real unit files. And if the real ones have a license,
then those might as well. It's easier to add it than to make an exception.
We also have a bunch of files that have some bytes and a lot
of text, like the journal export format. For those, it is still quite
useful when the tools try to diff them, so let's not mark those.
This version is from 2017 and should be stale enough to not cause
an outrage. All the relevant distros have it or a newer version.
We also already depend on some symbols defined in 3.0.5 anyway,
so let's take the opportunity to reduce our missing_efi.h
baggage.
The uefi_call_wrapper exists to convert to the right calling convention
and presumably predates compilers that can do so natively. The only
architecture where this is even needed is x86_64.
But because we are building with GNU_EFI_USE_MS_ABI defined, the
EFIAPI macro tells the compiler to use the right calling convention
for EFI functions. Our shim callback (which is called by EFI itself)
already relies on this.
This also adds a safety check to make se we are compiling with
GNU_EFI_USE_MS_ABI defined and also adds it to the compiler args
unconditionally. It is only used with x86_64 anyways, so it should
be fine to do so. EFI_FUNCTION_WRAPPER is unused in gnu-efi, so
it is dropped.
We are already using void in several places and having a screaming
typedef for void feels pointless. There are also CONST, IN, OUT
and OPTIONAL which we aren't using either.
This leaves missing_efi.h to keep it in line with how they are
defined in gnu-efi and/or the specs.
A little helper function and some unusual formatting makes this
whole thing a lot easier on the eyes. Also, right-aligning the
properties for better readability at runtime.
This function is a destructor, hence it should be named like one.
(We usually use xyz_free() for a destructor that frees the object passed
itself. xyz_unref() we typically use for destructors that are similar,
but ref counted. xyz_done() usually is used for destructors which free
the members of an object, but not the object itself – to allow stack
allocation of objects. We don't strictly follow this, but it's good to
stick to rules wherever we can.)
No actual code change, just renaming.
These set of functions are constructors for an object called HomeSetup,
which has a destructor home_setup_undo(), hence to be reasonably
symmetric, let's call it home_setup*() too, instead of using a new verb
"prepare" for its name.
No actual code changes, just some renaming.
We have the same code at two places, let's reuse it. Given the more
generic scope let's rename the function home_get_state() since it
retrieve the current setup state of the LUKS logic.
valgrind doesn't understand LOOP_GET_STATUS64. We already work around
this in various placed, via VALGRIND_MAKE_MEM_DEFINE(), but we forgot
three places. Let's fix that.
If an image file is actually a block device taking a lock on it doesn't
really make sense for us: it will interfere with udev's block device
probing logic, and it's not going to propagated across the network
anyway (which is what we are after here). Hence simply don't do it.
Follow-up for 2aaf565a2d
We currently call this ioctl even if we are backed by a regular file,
which is actually the common case. While this doesn't really hurt, it
does result in very confusing logs.
This adds support for dm integrity targets and an associated
/etc/integritytab file which is required as the dm integrity device
super block doesn't include all of the required metadata to bring up
the device correctly. See integritytab man page for details.
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
This is like alloca(), but does two things:
1. Verifies the allocation is smaller than ALLOCA_MAX
2. Ensures we allocate at least one byte
This was previously done manually in all invocations. This adds a handy
helper that does that implicitly.
