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.