I don’t see the point of implementing /dev/full. The python regress test is the only time I’ve personally run into this. And I think the issue was that python’s test suite made wrong assumptions about what devices exist on a particular system. Therefore the fix needed to be on the python side.
I considered the idea of /dev/full in base. But didn’t really see the point. If you are going to do fault injection testing (a very worthy goal) then I think you’d want to go a different route than a device node for every scenario. Out of interest, what is the use case you had in mind for such a device? > On Mar 2, 2023, at 9:47 AM, Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > 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 > > 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; > }
