> To fully abstract /dev/ptm in libutil, the API below would have to be
> extended to have another function to open /dev/ptm in libutil as well,
> eg. (better names would be desired):
>
> fd = openptmfd()
> pledge()
> fdopenpty(fd, ...)
> fdopenpty(fd, ...)
>
> I think putting these in libutil is a good idea. tmux could use
> them. I'd like to have openptmfd() as you suggest as well - it'd be nice
> to hide PATH_PTMDEV as well as the PTMGET.
>
> Life would be a lot easier for portable if there was fdforkpty() as
> well.
I agree.
Are the -portable
Hi
I think putting these in libutil is a good idea. tmux could use
them. I'd like to have openptmfd() as you suggest as well - it'd be nice
to hide PATH_PTMDEV as well as the PTMGET.
Life would be a lot easier for portable if there was fdforkpty() as
well.
On Mon, Feb 27, 2017 at 07:00:03PM
On Mon, Feb 27, 2017 at 10:19:28AM -0700, Theo de Raadt wrote:
> > On Mon, Feb 27, 2017 at 10:55:31AM +0100, Reyk Floeter wrote:
> > > The following diff is not really needed without just yet, but:
> > > - openening /dev/ptm in advance might allow better pledge in the future
> > > - customizing
> On Mon, Feb 27, 2017 at 10:55:31AM +0100, Reyk Floeter wrote:
> > The following diff is not really needed without just yet, but:
> > - openening /dev/ptm in advance might allow better pledge in the future
> > - customizing "openpty" will allow to do what we need next
> > Since openpty(4) is
On Mon, Feb 27, 2017 at 10:55:31AM +0100, Reyk Floeter wrote:
> The following diff is not really needed without just yet, but:
> - openening /dev/ptm in advance might allow better pledge in the future
> - customizing "openpty" will allow to do what we need next
> Since openpty(4) is libutil and
The following diff is not really needed without just yet, but:
- openening /dev/ptm in advance might allow better pledge in the future
- customizing "openpty" will allow to do what we need next
Since openpty(4) is libutil and not libc, it should be fine not using it.
OK?
Replace openpty(3)
