Date | Commit message (Collapse) |
|
We use it to dump SIGWINCH and _SC_NPROCESSORS_ONLN, so
"sysdefs" is a more appropriate list for *BSD users.
|
|
SIGWINCH is actually different for these architectures on Linux
according to the signal(7) man page.
Note: AFAICS there's no parisc machine in the GCC Farm[1],
so it remains untested. I've only tested mips64 for mips,
but I expect them to both work.
OpenBSD (on gcc231) octeon defines SIGWINCH as the common `28',
so it appears Linux is the only one with arch-dependent signal
numbers (ditto with syscalls).
[1] https://cfarm.tetaneutral.net/machines/list/
|
|
While I have no intention of using syscall numbers for
non-Linux, sizeof(pid_t) was useful for OpenBSD. And maybe
Linux can have real competition from other OSes with stable
syscall numbers someday.
|
|
Socket::MsgHdr is only packaged for Debian and derivatives at
the moment, and Inline::C pulling in gcc/clang is a huge amount
of disk space and bandwidth for some users.
This enables disk space and/or bandwidth-limited users to use lei.
Only Linux guarantees a stable ABI and syscall numbers, but
that's the majority of our userbase. FreeBSD users will still
have to use Inline::C (or get Socket::MsgHdr packaged).
x86, x32, and x86-64 are all currently supported, more to be added.
|
|
btrfs is Linux-only at the moment (and likely to remain that way
for practical purposes). So rely on Linux ABI stability and use
the `syscall' and `ioctl' perlops rather than relying on Inline::C.
Inline::C (and gcc||clang) are monstrous dependencies which we
can't expect users to have.
This makes supporting new architectures more difficult, but new
architectures come along rarely and this reduces the burden for
the majority of Linux users on popular architectures (while
still avoiding the distribution of pre-built binaries).
Link: https://public-inbox.org/meta/YbCPWGaJEkV6eWfo@codewreck.org/
|
|
One syscall is better than two for atomicity in Maildirs. This
means there's no window where another process can see both the
old and new file at the same time (link && unlink), nor a window
where we might inadvertantly clobber an existing file if we were
to do `stat && rename'.
|
|
We'll be supporting inotify directly as we do with epoll so so
Linux users won't have to deal with XS, extra DSOs or install
Linux::Inotify2 (and common::sense) modules.
|