Re: Can version bump up to 9.99.100?
On Sat, 2022-09-17 at 02:50 +0700, Robert Elz wrote: > Date: Fri, 16 Sep 2022 12:59:24 -0400 > From: "David H. Gutteridge" > Message-ID: > > | So there will be information loss there, at minimum. Whether that > ends > | up being significant at some point, I guess we can't say. > > I would hope not. That is, I am assuming (but don't know pkgsrc well > enough to be sure) that OPSYS_VERSION gets used for some kind of > feature > test. That's OK (not the ideal method - but sometimes it is the only > practical one) for major, or even minor version comparisons. It isn't > for > the 3rd field (xx) in N.99.xx for NetBSD. That field is not changed > for feature additions, so some N.99.xx may have a particular feature, > and others not, but is changed for internal ABI alterations (which > don't > necessarily affect what is visible by applications in any way at all). > > Note also that this value is never changed (in the NetBSD N.99.xx > case) > because of changes that occur to anything outside the kernel - so it > can > never safely be used to test what version of some application or > library > function might be installed. Never. > > If pkgsrc (or pkgsrc packages) are using this sensibly, then limiting > OPSYS_VERSION at 09 for all future __NetBSD_Version__ values > 9.99.x > where x >= 100 should be safe, as nothing should ever care about those > final 2 digits. > > That's "if". Sometimes it's necessary to test for when a feature was added in a -current release, and there's no simple or precise way to do it, as you've noted. If a feature was added sometime in xx.yy.zz, then a test might (retroactively) be expressed with zz+1 as the floor. (An example is some of the ARM compatibility handling in mk/java-vm.mk.) That's not perfect, but it's the reality of pkgsrc. > > kre > > ps: the issue I was concerned about more would occur when the kernel > version info gets embedded in a package version, and other similar > things. Yes, well, there's pkgtools/osabi, for example, which is all about that, and is arguably abused to conflate both kernel and userland (including X11) state at present. This is a bit of a mess in pkgsrc, IMO. It uses a different variable (OS_VERSION), which is expressed as a string output of uname -r, and so shouldn't be impacted here (I haven't checked). Regards, Dave
Re: Open master pty (/dev/ptmx) non blocking
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:
> > Then, shouldn't the open(2) (and posix_openpt(3)) at least fail with
> > EINVAL or something if other flags are specified?
>
> 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, instead it is simply ignored. This means it is not
> possible to dynamically test which open(2) flags are possible to set, and
> apply a fallback if EINVAL is received.
That is, however, kind of a feeble excuse :-)
Agreed. But I inferred this was perhaps done this way on purpose, and
could be controversial to change. (Would also then mean downstream code
would have to special-case NetBSD releases and/or add tests which could
be cumbersome.) I hadn't got around to asking, I was dealing with
documenting the reality and working with the vte project so that NetBSD
support for gnome-terminal/mate-terminal/xfce4-terminal/et al. was
accepted.
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:
Index: tty_ptm.c
===
RCS file: /cvsroot/src/sys/kern/tty_ptm.c,v
retrieving revision 1.43
diff -u -p -r1.43 tty_ptm.c
--- tty_ptm.c 29 Jun 2021 22:40:53 - 1.43
+++ tty_ptm.c 23 Sep 2022 20:12:07 -
@@ -338,6 +338,10 @@ ptmopen(dev_t dev, int flag, int mode, s
dev_t ttydev;
struct mount *mp;
+ if (flag & O_NONBLOCK) {
+ return EINVAL;
+ }
+
switch(minor(dev)) {
case 0: /* /dev/ptmx */
case 2: /* /emul/linux/dev/ptmx */
It's not just O_NONBLOCK that can be expected/desired, vte wants to set
O_CLOEXEC as well. The Linux kernel accepts and applies both of those
flags in a posix_openpt(3) call.
OpenBSD does this validation in posix_openpt(3) directly:
/* User must specify O_RDWR in oflag. */
if ((oflag & O_ACCMODE) != O_RDWR ||
(oflag & ~(O_ACCMODE | O_NOCTTY)) != 0) {
errno = EINVAL;
return -1;
}
Now, that doesn't cover the case that someone simply calls open(2) on
the ptmx cloning device directly, so safer to be placed where you're
suggesting. (And I make no claims to being an authority on any of
this, I've simply looked at it a bit, and may well have missed
something.)
Regards,
Dave
Re: Open master pty (/dev/ptmx) non blocking
On Fri, 23 Sep 2022 at 11:49:32 + (UTC), RVP wrote: On Fri, 23 Sep 2022, Anthony Mallet wrote: Then, shouldn't the open(2) (and posix_openpt(3)) at least fail with EINVAL or something if other flags are specified? Yes, this was noticed recently by gutteridge@ (I think) who also amended the manpage to what Martin just quoted (and which may not have been pulled up to -9.x) The other BSDs validate the oflag argument and return EINVAL if anything supplied is inapplicable. This is also the case with recent Solaris derivates (my test reference being OmniOS). What they accept and where they validate varies, with OpenBSD doing so in the posix_openpt function, and FreeBSD doing so in a lower layer (not that that really matters here). This came up recently as I was reviewing issues with vte support of NetBSD. The upstream was expecting to be able to test for flag support via EINVAL responses, but that didn't work for NetBSD, which instead would simply return an FD that was stuck in an unusable state for their purposes and expectations. It was on my (long) list of things to do to either mention this on a mailing list like this or file a PR. It's not wrong from a POSIX perspective as I read it. I'm not sure if there would be an appetite to change it now -- consider this my question to the list. :) I hadn't submitted a pullup request to update the man pages on stable releases, as I wanted to ask about it first, and it seemed kind of obscure (this is an unexpected coincidence). I can certainly do so. Regards, Dave
Re: Can version bump up to 9.99.100?
On Fri, 16 Sep 2022 at 19:00:23 +0700, Robert Elz wrote:
[...] That is, except for in pkgsrc, which is why I still
have a (very mild) concern about that one - it actually compares the
version numbers using its (until it gets changed) "Dewey" comparison
routines, and for those, 9.99.100 is uncharted territory.
One wrinkle is that the current definition of OPSYS_VERSION (in
pkgsrc/mk/bsd.prefs.mk) does this (wrapped for formatting):
_OPSYS_VERSION_CMD= ${UNAME} -r | \
awk -F. '{major=int($$1); minor=int($$2);
if (minor>=100) minor=99; patch=int($$3);
if (patch>=100) patch=99; printf "%02d%02d%02d",
major, minor, patch}'
So there will be information loss there, at minimum. Whether that ends
up being significant at some point, I guess we can't say. Someone could
always re-implement something different for NetBSD (meaning all the
existing NetBSD-specific uses of OPSYS_VERSION would be adjusted).
(There are 135 instances of OPSYS_VERSION in pkgsrc presently. I don't
know offhand how many are NetBSD-specific, that's harder to count, but
it's a significant subset, I believe.)
Regards,
Dave
