Re: [PATCH v9 0/9] Input/Output Terminal Abstraction
Grant Erickson <[email protected]> Wed, 28 May 2025 07:34:23 -0700
| Newsgroups | dev.linux.lists.ell |
|---|---|
| Message-ID | <[email protected]> |
On May 27, 2025, at 11:08=E2=80=AFAM, Grant Erickson = <[email protected]> wrote: > On May 27, 2025, at 10:20=E2=80=AFAM, Marcel Holtmann = <[email protected]> wrote: >>> This expands on Marcel Holtman's 2023-12-22 RFCv4 patch for an >>> input/output terminal abstraction. >>>=20 >>> Substantive changes from the v7 version: >>>=20 >>> * Fixed a typo in the ASCII C0 and C1 control code mnemonics. >>>=20 >>> Grant Erickson (9): >>> term: Initial revision. >>=20 >> I actually reverted it back to my version and included printf / = vprintf helpers. >>=20 >> What is the purpose of l_term_set_bounds? Is it important for non-TTY = setups since for TTY compatible terminals, this should not be needed. >=20 > It=E2=80=99s been a year and a half since I first deploy[ed] this, so = bear with me as I attempt to clear some dust and cobwebs from some of = the details. >=20 >>=20 >>> ell/term: Do not return -EPERM for 'putnstr' and 'vprint' if not >>> running. >>=20 >> Why is that important. It seems like a hack. If you haven=E2=80=99t = successfully acquired the terminal, there is no point in writing to it = since you have no idea what termios setting are dealing with. >=20 > Per the above, regrettably, at this point I don=E2=80=99t recall the = issue that I had run into. For what they are worth, my output methods = are: >=20 > ... >=20 >>> ell/term: Return error on writes if the output descriptor is = invalid. >>=20 >> Seems like a fix for the previous change. >=20 > It might well be. Again, per the comment above about getting back into = the context of a year and a half ago, it seems like there was a desire = to be able to initialize an instance with the stdin / stdout file stream = pointers and have things work as-is and then bootstrap into / out of = those with the terminal as my line oriented UI/UX acquired / released = the terminal as UI/UX elements were pushed/popped off the stack. Thinking about this further, I suspect my original changes about = is_running (now, is_acquired) / -EPERM and -EBADF were about early = prototyping and refining my stack based, line-oriented UI/UX. I suspect if we left the code as-it was in those two regards, the stack = based, line-oriented UI/UX would work fine. If that=E2=80=99s not the = case, I can revisit that specific issue later. Best, Grant --=20 Principal Nuovations [email protected] https://www.nuovations.com/