On Friday 23 Sep 2022, at 17:34, David H. Gutteridge wrote:
> On Fri, 23 Sep 2022 at 20:14:23 +, David Holland wrote:
> > On Fri, Sep 23, 2022 at 01:39:16PM +0200, Martin Husemann wrote:
> > > Note that unlike implementations on some other operating
> > > systems, posix_openpt() does
On Fri, 23 Sep 2022, David Holland wrote:
> While my inclination would be to make it work, until someone wants to
> figure out how to do that it seems straightforward to make O_NONBLOCK
> fail:
Mostly out of curiosity and for the records, I tested the attached
patch. It enables the EINVAL error fo
> The man page says:
>
> Note that unlike implementations on some other operating systems,
> posix_openpt() does not return EINVAL if the value of oflag would
> be deemed invalid
Oh, right. I missed that...
I see that this was added 2 weeks ago and my base is from last March
only.
On Friday 23 Sep 2022, at 10:29, RVP wrote:
> So, O_NONBLOCK is, at least, _definitely_ non-portable. Best to use
> fcntl() here and not depend on a Linux-specific behaviour.
Fair enough :)
Then, shouldn't the open(2) (and posix_openpt(3)) at least fail with
EINVAL or something if other flags are
Hi,
I have a piece of software that opens a master pty non-blocking:
fd = open("/dev/ptmx", O_RDWR | O_NOCTTY | O_NONBLOCK);
The intent is to make further read(2) on the master non blocking. But
the O_NONBLOCK flag seems to be ignored. Attached is a minimal sample
C program showing the issue.
Se
[I noticed that for some reason I was not subscribed anymore to
tech-kern, so I'm manually pasting some replies read from the
mail-index web :/]
Mouse wrote:
> kexec stuff? I've occasionally wondered why more ports don't implement
> it.
Valery Ushakov wrote:
> As der Mouse mentioned upthread, kl
On Wednesday 16 Sep 2020, at 12:09, Martin Husemann wrote:
> This works fine on e.g. sparc*; I can do: shutdown -b netbsd.t -r
> now
>
> No state is modified on any disks, very convenient.
Right, not changing any state seems safer!
> I don't know if there is enough of a persistent environment for
Hi,
I own a remote amd64 machine, with no physical access at all (no
serial console either). It can be remotely power cycled,
though. Upgrading a kernel there is always a bit frightening. In case
of a boot failure, the recovery process to revert to the old kernel is
painful and a bit involved (net
On Saturday, at 19:08, Dennis Ferguson wrote:
| gcc can't correctly eliminate the comparison just because you are asking
| it to compare pointers to different structure types. No aliasing issues
| arise in any case unless you actually use the pointers to access something,
| and there are many ways
