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/