On Thu, Mar 02, 2023 at 04:57:10PM -0500, Daniel Dickman wrote:
> 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 mentioned the python test in passing.  I only found out about it after I
wrote the /dev/full code and did a web search to see if anybody had ever
mentioned it in conjunction with OpenBSD before.

> Out of interest, what is the use case you had in mind for such a device?

I didn't have a specific use case in mind - /dev/full exists on all other
modern unix-like systems that matter, and people use it, amoungst other
things, as an easy way to test how shell scripts react when they hit an
unexpected ENOSPC error.

I don't particularly use it, (although I might start to now, since it's in
our set of local patches and therefore available to me on all of our OpenBSD
machines).

I only wrote the /dev/full code as an afterthought whilst working on something
that was related - a new device called /dev/fill, that could be used to test
Stuart's claim that MFS is slower than some SSDs and eliminate the possible
slew of the results due to SSDs treating 0x00 differently, (since previous
tests seem to have mostly used /dev/zero as input).  If you're interested in
that, please look at the article I linked in the first email.

I didn't ever bother to mention the /dev/fill stuff on the list, (except as
a link to the article), because I knew it wouldn't be popular, and anyone who
wants it knows where to find it and can complile their own kernel.

But the four line diff to add /dev/full was so trivial that it seemed useful
to post it for comments.

Which I have now received.

Hopefully the above email answers everybodys' questions about my four-line
diff to add a feature that every other OS has, and yet nobody here wants, and
the whole issue can be put to rest and forgotten about.

Reply via email to