Re: FYI: POSIX update - SIGWINCH and 'struct winsize' (etc) to be added

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 21 Oct 2017 19:59:57 +0200
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <513a5aac-d68e-a3da-bd28-9e5cd63ab8bd%gmx.com@localhost>

  | We can follow the <sys/timespec.h> approach. Add a dedicated header for
  | a struct and include where needed.

That's what I currently have, it is easy, clean, and works.   Unfortunately
it is also costly - it slows compiles, consumes a file system block, and
an inode (plus more of each in cvs, and /usr/src), and means more to maintain.

If I can find a (relatively) clean way to avoid it, I shall (which means
not simply having the structure duplicated in 2 different .h files, which
also works (would work), and is cheap, but is filthy...)

dholland-tech%netbsd.org@localhost said [about tty(4) and its ancient content]:

  | That can be changed. In fact, tty.4 should be updated to refer to the new
  | functions the same way it refers to tcgetattr/tcsetattr.

Yes, agreed, and once the rest of this is actually committed, I'll take
a look at doing some updates there (unless you beat me to it - hint, hint ...)

  | There is really not very much software that manipulates the window size
  | without also manipulating the terminal settings, and therefore already
  | includes termios.h, 
[...]
  | I think we can tolerate this, but it might be a good idea to run a bulk
  | build to see just how much, if anything, breaks. 

I am not set up to run pkgsrc bulk builds (barely set up to build anything
from pkgsrc right now - I am just using what I built ages ago) but if
someone else wants to try, I can certainly send them what I have done so far -
not that my stuff is really needed, how the new functions work isn't material
(and they are trivial anyway - the only real work in any of this is the new
man page!) just the effect of simply moving struct winsize from sys/ttycom.h
to sys/termios.h and anyone with an editor can do that locally in about 30
seconds...  (You can just do it on what is installed in /usr/include, and
then try pkg building.)

(quoting me...)
  | > If that happens, would it be reasonable to make the new header #error
then:
  | Yes, although I tend to think that the setup required to cause #error is not
  | worthwhile and that it's sufficient to put a notice 

It is actually trivial, the whole thing (as I have it now) is just 3 lines
(one of which is the #error).   It is by no means foolproof (what is?) but
will catch cases where someone just does #include <sys/new-file.h>

If <termios.h> or <sys/ioctl.h> (or even <sys/ttycom.h> but I don't think
anyone ever includes that directly, or at least I have never seen  it)
before they #include <sys/new-file.h> then my check won't detect it, but
I cannot think of a reason anyone would be tempted to do that, the others
already include it, and adding the extra #include would just make code less
portable (no other system is going to have an include file with the name I
really picked - deliberately chosen to make it unattractive to include,
while not just being gibberish - so code including it wouldn't compile
anyplace else.)

I'd still prefer not to have the new include file if we can get away without
it, and if people generally believe that's reasonable.

Maybe I should just try committing the changes, with the simple movement of
struct winsize (no new header) and then see what happens?   This is -current
after all, it breaks from time to time, and the breakage here would just
be that (perhaps) a few dozen (guessing, and hoping that's the worst case)
packages might not compile for a day or two.

We can always add a new header (takes just minutes, and I know the
system builds and works with it, done that already) if it turns out that
not doing it causes too much pkgsrc breakage to tolerate.

Obviously I will make sure that NetBSD builds properly with struct winsize
just moved, and fix anything I find that fails before I commit (if it builds,
it will work as well as it does now - there are no operational changes here,
just stuff to scramble compiles, potentially).

So, are there any objections to that cause of action, that is, committing
the new stuff, with struct winsize in <termios.h>  and no longer in
<sys/ttycom.h> so it will no longer be visible from <sys.ioctl.h> ?

Or would people prefer to wait for someone to do a tailored pkgsrc bulk-build
to test the effect of those changes, before committing them?

kre