| Date | Commit message (Collapse) |
|---|
|
While syscall symbols (e.g. SYS_*) have changed on us in FreeBSD
during the history of Sys::Syscall and this project and did bite
us in some cases; the actual numbers don't get recycled for new
syscalls. We're also fortunate that sendmsg and recvmsg syscalls
and associated msghdr and cmsg structs predate the BSD forks and
are compatible across all the BSDs I've tried.
OpenBSD routes Perl `syscall' through libc; while NetBSD + FreeBSD
document procedures for maintaining backwards compatibility.
It looks like Dragonfly follows FreeBSD, here.
Tested on i386 OpenBSD, and amd64 {Free,Net,Open,Dragonfly}BSD
This enables *BSD users to use lei, -cindex and future SCM_RIGHTS-only
features without needing Inline::C.
[1] https://cvsweb.openbsd.org/src/gnu/usr.bin/perl/gen_syscall_emulator.pl
[2] https://www.netbsd.org/docs/internals/en/chap-processes.html#syscall_versioning
[3] https://wiki.freebsd.org/AddingSyscalls#Backward_compatibily
|
|
This is a step towards improving the out-of-the-box experience
in achieving notifications without XS, extra downloads, and .so
loading + runtime mmap overhead.
This also fixes loongarch support of all Linux syscalls due to
a bad regexp :x
All the reachable Linux architectures listed at
<https://portal.cfarm.net/machines/list/> should be supported.
At the moment, there appears to be no reachable sparc* Linux
machines available to cfarm users.
Fixes: b0e5093aa3572a86 (syscall: add support for riscv64, 2022-08-11)
|
|
We'll show SO_ACCEPTFILTER since it's supported on three
of the BSDs we support.
|
|
It's stdout can now be placed into a Perl hash, now.
The MAYBE pseudo-macro can now emit hex as well as decimal
output to make some constants look nicer and eliminate some
special cases.
Constants for _SC_AVPHYS_PAGES and _SC_PAGE*SIZE have also been
added in case we dynamically generate BATCH_SIZE for search
indexing
I'm not sure how far I want to go down this route, but it could
open the door to us supporting more things on platforms with
unstable syscall numbers with only a C compiler, but without
relying on needing Inline::C (nor XS and difficult-to-audit
binaries). This is because a C compiler is readily installed on
more systems than Inline::C (even if packaged) requires an
additional installation step.
|
|
MboxLock already supported it since it locked the whole file,
but POP3D requires more fine-grained locking at file offsets.
I wonder if "struct flock" is old enough for it to be the same
across all the BSDs, it certainly seems so.
I originally considered using C11 `_Generic' support for the
struct offset/type dumping as I have in other projects, but
I am not ready to depend on C11 for this project, yet.
While we're modifying devel/sysdefs-list, add some Linux-only
structs to verify our `pack' templates are correct and remain
so when we encounter new architectures.
|
|
We use it to dump SIGWINCH and _SC_NPROCESSORS_ONLN, so
"sysdefs" is a more appropriate list for *BSD users.
|
|
|
|
t/run.perl now prints slowest 10 tests at startup, and I've
added ./devel/longest-tests to print all tests sorted by
elapsed time.
This should allow us to notice outliers more quickly in the
future.
|
|
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.
|