On Thu, 6 Nov 2025, H. Peter Anvin wrote:

It seems to me that this may very well be a problem beyond ttys, in which case
a new open flag to request to a driver that the configuration and (observable)
state of the underlying hardware device -- whatever it may be -- should not be
disturbed by calling open(). This is of course already the case for many
devices, not to mention block and non-devices, in which case this flag is a
don't care.

 FWIW I find using an open flag the most natural way to solve this problem 
and I disagree with a view that a 50+ year old standard has to prevent us 
from handling new use cases found as the world has changed.  We do need to 
comply with the standard for the devices that use it, but I think a flag 
to opt out is a perfectly sane approach.

 Yes, some hardware has limitations and may have to conclude we can't do 
anything about it.  Just as, say, we can't choose an arbitrary baud rate 
with the dz.c driver, because the hardware handled has a 4-bit selector 
for a set of predefined rates (to stay remotely on topic).  That does not 
prevent us from handling more flexible hardware in a way that makes full 
use of its features.

The best name I came up with was O_NRESETDEV, but it's not something I'm
particularly attached to.

 I'd suggest a generic name such as O_RAW for an agnostic way to express a 
request not to fiddle with the device in any way regardless of its kind, 
i.e. for possible reuse with anything.

If the opinion is that this *doesn't* have a scope beyond ttys, then perhaps
abusing the O_DIRECT flag for this purpose would be an alternative.

 It seems like a hack to me, but if carefully evaluated we could reuse the 
bit encoding.  Either way I'd encourage defining a new meaningful name for 
the new application of the flag, such as one proposed above.

  Maciej