markjdb

6 ms·

1.
by markjdb 8mo ago
At least FreeBSD's syscall ABI is guaranteed to be stable, one can run ancient binaries on a modern kernel. I believe the same is not true of OpenBSD and maybe NetBSD however.
2.
by markjdb 10mo ago
The pf maintainer in FreeBSD has been doing a ton of work to bring more recent improvements over from OpenBSD, trying to bring them in sync as much as possible without breaking compatibility: https://cgit.freebsd.org/src&#x2
3.
by markjdb 2y ago
A design that works by default isn't automatically better either though. You have to look at the details. > I guess one might be tempted to forgive a few warts in the interface layers ... well, yeah, that's exactly my sentimen
4.
by markjdb 2y ago
The article clearly isn't talking about technical debt within the kernel implementations of epoll and kqueue, and if one wanted, it'd be easy to define fallback EVFILT_READ/WRITE filters using a device's poll implementat
5.
by markjdb 2y ago
Well, no, it's "this interface works fine for you if you implement it." The kernel doesn't magically know whether your device file has data available to read, your device file has to define what that means. That's
6.
by markjdb 2y ago
I'm not sure. Maybe it's "wait for events that aren't tied to an fd." For instance, FreeBSD (and I think other BSDs) also have EVFILT_PROC, which lets you monitor a PID (not an fd) for events. One such event is NO
7.
by markjdb 2y ago
I don't think the article does a good job of arguing its premise, which I think is that kqueue is a less general interface than epoll. When adding a new descriptor type, one can define semantics for existing filters (e.g., EVFILT_READ)
8.
by markjdb 2y ago
The same is true of kqueue/kevent though... the driver just needs to decide which filters it wants to implement. There's no need to extend kqueue when adding some custom driver or fd type. One just needs to define some semantics
9.
by markjdb 2y ago
For what it's worth, the default root shell is now /bin/sh instead of csh. I think that's true as of 14.0. /bin/sh is also a better interactive shell than it used to be, though yeah, I don't use it to do
10.
by markjdb 3y ago
CHERI does more than help eliminate security vulnerabilities. Consider that today we rely on the MMU to provide memory isolation between Unix processes; CHERI enables isolation without switching page tables, at a smaller hardware cost (thou
11.
by markjdb 4y ago
CHERI does permit tricks like storing flags in the low bits of a pointer, at least to some extent. Quite a lot of low level C code (including some in the CheriBSD kernel) needs that to work.
12.
by markjdb 5y ago
I use "ktrace -t f" once in a while for debugging and it's really handy. Output looks like 78436 cat PFLT 0x6c71f99cda8 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36c280 0
13.
by markjdb 5y ago
I'd be amazed if it isn't a configuration error of some kind.
14.
by markjdb 5y ago
How much data ends up being served from RAM? I had the impression that it was negligible and that the page cache was mostly used for file metadata and infrequently accessed data.
15.
by markjdb 5y ago
You can even send a Unix socket over itself. The kernel has to be careful to handle that correctly. :)
16.
by markjdb 5y ago
This is mostly true on FreeBSD as well. The real problem is that capability mode also disallows openat(AT_FDCWD) - there has to be an explicit directory descriptor.
17.
by markjdb 5y ago
It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap between the proxima
18.
by markjdb 6y ago
That's fair. At the time, though, it wasn't clear that the author's angle was that FreeBSD doesn't have a culture of doing code reviews. We do, and I don't think one has to look very hard to see that.
19.
by markjdb 6y ago
There's some discussion happening now and I do expect to see some process changes coming out of this. It's tricky. The review you link does nominally follow the process of creating a review and having some discussion, but there
20.
by markjdb 6y ago
> Or is this just how it is on FreeBSD? It's not. We do a lot of code review, and it's done publicly. It's easy to look at the commit logs. I find it telling that the article doesn't spend even one word trying to d
21.
by markjdb 6y ago
The notion there is that at some point in the past free memory was scarce, so the kernel swapped out some pages, and that swap space may still be in use long after the shortage is alleviated. FreeBSD won't swap anything out unless the
22.
by markjdb 6y ago
> as many of these tests show The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.
23.
by markjdb 6y ago
"paravirtualized Solaris kernel" isn't really accurate - it's a collection of kernel interface shims. The whole thing is quite small, about 4KLOC on FreeBSD.
24.
by markjdb 6y ago
A driver is in ports while the author works on getting it ready to import. Just pkg install iichid.
25.
by markjdb 6y ago
Also mentioned here: https://lwn.net/Articles/808733/
26.
by markjdb 6y ago
I was wondering how this scheme might break applications that do clever things with a SIGBUS/SIGSEGV handler. Do you happen to know of any OSS that actually does something like this?
27.
by markjdb 6y ago
> I do wonder why there isn't an API for "lazy munmap()" You don't really need a separate API. The kernel can implement munmap() lazily, it just needs to also ensure that the address range isn't reused until a T
28.
by markjdb 6y ago
If anyone is interested in their application to system software, the FreeBSD kernel uses a PID loop to regulate memory reclamation: https://svnweb.freebsd.org/base/head/sys/kern/subr_pidctrl.c... https:
29.
by markjdb 7y ago
Because there are not many people with the ability to add 802.11ac support to drivers, the resources to do so (datasheets, test hardware), and the time required. The 802.11 stack does support at least some 11ac features.
30.
by markjdb 7y ago
It implements the x86 and x86_64 Linux system call ABI. Linux ELF binaries get vectored to an alternate system call table implemented by the compatibility layer. There are some other components like an implementation of a Linux-compatible

More ›