Crystal Kolipe <kolip...@exoticsilicon.com> writes:
> We currently don't implement the /dev/full device, which is present in > NetBSD, FreeBSD, and Linux. > > For those who haven't heard of it, it's basically the same as /dev/zero, but > writes to it always return ENOSPC. > > The lack of /dev/full on OpenBSD has previously caused minor issues with > third party software, for example: > > https://bugs.python.org/issue21934 > Is this really a problem with ports? That Python issue was related to a Python 2.7 unit test and from 2014. > Adding support for /dev/full is trivial. I've attached a patch for amd64, > if there is interest I can easily produce a set of patches for other archs. > > To create the device file, you'll need to do: > > # mknod -m 666 /dev/full c 2 5 > > For those who are interested, I've written a more in-depth discussion about > memory special devices, including a proposal for another such new device, > /dev/fill: > > https://research.exoticsilicon.com/articles/memory_special_devices > > --- arch/amd64/amd64/mem.c.dist Wed Mar 24 11:26:39 2021 > +++ arch/amd64/amd64/mem.c Thu Mar 2 11:10:30 2023 > @@ -88,6 +88,7 @@ > break; > return (EPERM); > case 2: > + case 5: > case 12: > break; > #ifdef APERTURE > @@ -165,9 +166,13 @@ > uio->uio_resid = 0; > return (0); > > + /* minor device 5 is /dev/full */ > /* minor device 12 is /dev/zero */ > + case 5: > case 12: > if (uio->uio_rw == UIO_WRITE) { > + if (minor(dev)==5) > + return (ENOSPC); > c = iov->iov_len; > break; > }
