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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I shall not use alloca() within loops
I shall not use alloca() within loops
I shall not use alloca() within loops
I shall not use alloca() within loops
...
* kill unnecessary {}
* add newlines where appropriate
* remove dead code
* reorder variable declarations
* fix more return code logic
* pass O_CLOEXEC to all open*() calles
* use safe_close() where possible
Retrieve the handle to procfs in main(), and pass it functions
that need it. Kill the global variables.
Also, refactor lots of code in svg_title(). There's no need to access any
global variables from there either, and we really should return proper
errors from there as well.
Don't blindly exit() from random functions, but return a proper error
and upchain error conditions.
squash! bootchart: clean up control flow logic
When pread() returns "0", it's a read failure, so don't make the caller think
log_sample() was successful, return meaningful error code instead of 0.
We support /var, /tmp and /var/tmp on NFS. NFS shares however are by
default ordered only before remote-fs.target which is a late-boot
service. /var, /tmp, /var/tmp need to be around earlier though, hence
explicitly order them before basic.target.
Note that this change simply makes explicit what was implicit before,
since many early-boot services pulled in parts of /var anyway early.
- print runtime warnings with log_warning()
- save and restore $TZ properly
- Get rid of exit() pseudo error handling
- Using time() is OK when connecting to a local container or when
showing data about local host, but certainly not for remote hosts.
This provides equivalent functionality to libudev-device, but in the
systemd style. The public API only caters to creating sd_device objects
from for devices that already exist in /sys, there is no support for
listening for monitoring events or creating devices received over
the udev netlink protocol.
The private API contains the necessary functionality to make sd-device
a drop-in replacement for libudev-device, but which we would not
otherwise want to export.
If you have for example ext4 on iscsi devices it is possible to setup
qoutas there. Unfortunately, because such fstab entry contains _netdev,
systemd will not add dependency to quotaon.service.
Some systems abusively restrict mknod, even when the device node already
exists in /dev. This is unfortunate because it prevents systemd-nspawn
from creating the basic devices in /dev in the container.
This patch implements a workaround: when mknod fails, fallback on bind
mounts.
Additionally, /dev/console was created with a mknod with the same
major/minor as /dev/null before bind mounting a pts on it. This patch
removes the mknod and creates an empty regular file instead.
In order to test this patch, I used the following configuration, which I
think should replicate the system with the abusive restriction on mknod:
# grep devices /proc/self/cgroup
4:devices:/user.slice/restrict
# cat /sys/fs/cgroup/devices/user.slice/restrict/devices.list
c 1:9 r
c 5:2 rw
c 136:* rw
# systemd-nspawn --register=false -D .
v2:
- remove "bind", it is not needed since there is already MS_BIND
v3:
- fix error management when calling touch()
- fix lowercase in error message
We have no such check in any of the other tools, hence don't have one in
nspawn either.
(This should make things nicer for Rocket, among other things)
Note: removing this check does not mean that we support running nspawn
on non-systemd. We explicitly don't. It just means that we remove the
check for running it like that. You are still on your own if you do...
QEMU/KVM guests do not have hypervisor nodes, but they do have
fw-cfg nodes (since qemu v2.3.0-rc0). fw-cfg nodes are documented,
see kernel doc Documentation/devicetree/bindings/arm/fw-cfg.txt,
and therefore we should be able to rely on it in this detection.
Unfortunately, we currently don't have enough information in the
DT, or elsewhere, to determine if we're using KVM acceleration
with QEMU or not, so we can only report 'qemu' at this time, even
if KVM is in use. This shouldn't really matter in practice though,
because if detect-virt is used interactively it will be clear to
the user whether or not KVM acceleration is present by the overall
speed of the guest. If used by a script, then the script's behavior
should not change whether it's 'qemu' or 'kvm'. QEMU emulated
guests and QEMU/KVM guests of the same type should behave
identically, only the speed at which they run should differ.
