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.
> 

Reply via email to