Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/compat/linux/common



    Date:        Mon, 30 Sep 2024 09:09:04 -0400
    From:        Christos Zoulas <christos%zoulas.com@localhost>
    Message-ID:  <2F4EC894-D66F-4608-84B1-7DD8433EB9FA%zoulas.com@localhost>

  | [quoting mrg@]
  | > this looks like it should use NETBSD32IPTR64(),

No, that would be wrong (even if it happened to work), it is expecting
to be given a 32 bit pointer (as an int) and converts that to a regular
pointer for 64 bit arch's.   Here we have 64 bit pointers (as integers)
to be treated as 32 bit pointers (when built on a 32 bit arch).

  | See the comment in /usr/src/sys/compat/netbsd32/netbsd32.h:
  |
  |  *      NETBSD32_POINTER_TYPE
  |  *              - 32-bit pointer type, normally uint32_t but can be int32_t
  |  *                for platforms which rely on sign-extension of pointers
  |  *                such as SH-5.
  |  *                eg:   #define NETBSD32_POINTER_TYPE uint32_t

All of this is more or less assuming that the desire is to run 32 bit
applications on a 64 bit system, which is no surprise, as that's what
it is all for.

What's happening in the file in question (linux compat mode) when running
(or building) on i386 is taking a linux defined interface, defined to work
for 64 bit systems (even when used on a 32 bit host), and running it on a
32 bit system.   This is all more or less the direct opposite of what
the netbsd32 compat stiff is designed for.

It is even more messed up, as the code is trying to implement a new
interface in terms of the older one it is to replace, which isn't
something that is normally done.

When an interface is enhanced, the usual practice is to redefine the
older version in terms of the newer, with some form of default settings
for the new features, so the new interface behaves the same way as the
more limited older one would have.

This code could have done that - implemented linux's clone3() and then
redefined clone() to be a particular way of calling clone3() (which is
what I'd guess linux implementations might do, if they don't just have
both versions in full).   That would have worked, but requires updating
the clone() implementation to be clone3() (even if on NetBSD lots of the
added stuff is simply meaningless).

kre



Home | Main Index | Thread Index | Old Index