What is with the long mail? Does anyone give a shit, besides you?
No. Noone has any space for this bullshit, or this long explanation. Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > 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. >