/dev/yes, a kernelspace version of the famous yes(1) utility

xyes(1): displays an X window with an infinite scrolling list of "y" characters

Follow

Uhh, so /dev/yes is now a thing for real too 😆

github.com/bugaevc/dev-yes

Since it's kernel-side, there has to be a separate implementation for each kernel. As of now, the following kernels are supported: Linux, GNU , XNU (Darwin), and .

Performance and supported features depends on the particular implementation and kernel, but at least on Linux and the Hurd, /dev/yes is ≈3 times faster than GNU yes(1).

· · Web · 4 · 6 · 5

Note: on the Hurd, it's no more "kernel-side" than any other device driver — everything runs as regular processes in userspace.

And yet it's 3 times after than yes(1). What gives?

Well, to pipe yes(1) output into another program's input, you use a pipe. And that means going though the pflocal server.

The /dev/yes translator, on the other hand, can be read directly, meaning less context switches, and probably less copying data.

So in the end, it's for the same reasons it's faster elsewhere.

@bugaevc This has got to be one of the silliest optimisations ever, right?

@bugaevc Out of curiosity, how faster is '/dev/yes' as a Linux device vs. a Hurd translator?

@slp great question! On my two VMs,

∙ Linux version does 13-15 GB/s (head(1) does 5-6 GB/s)
∙ Hurd version does 1.2 GB/s (head(1) does 300-400 MB/s)

(note that I got these numbers using pv(1), which might be introducing its own overhead)

@bugaevc Thanks! Seems roughly equivalent to what I saw many years ago.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!