Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR kern/51700; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Mon, 16 Jan 2017 05:27:13 +0100

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe
 Content-Type: multipart/mixed; boundary="RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <35787b2b-f28b-cf89-9b07-1d54c5efc710%gmx.com@localhost>
 Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
 References: <pr-kern-51700%gnats.netbsd.org@localhost>
  <20161209063718.626CA7A364%mollari.NetBSD.org@localhost>
  <20170116042001.59CEB7A1AF%mollari.NetBSD.org@localhost>
 In-Reply-To: <20170116042001.59CEB7A1AF%mollari.NetBSD.org@localhost>
 
 --RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 
 
 
 On 16.01.2017 05:20, David Holland wrote:
 > The following reply was made to PR kern/51700; it has been noted by GNA=
 TS.
 >=20
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
 > Date: Mon, 16 Jan 2017 04:15:28 +0000
 >=20
 >  On Sun, Dec 11, 2016 at 09:40:01AM +0000, Kamil Rytarowski wrote:
 >   >>  I'd argue that it should just be removed.
 >   > =20
 >   >  I concur it, how to do it cleanly? Set backwards compatible link
 >   >  exect(3) to execve(2) and add a note that it should be removed on =
 major
 >   >  libc bump?
 > =20
 >  No, if it's never going to work replace it with a stub that returns -1=
 
 >  with errno EOPNOTSUPP, one in the kernel and one in libc. Then remove
 >  the libc stub when the mythical version bump happens.
 > =20
 
 It's broken since day0. No need to add a stub in the kernel, it's only
 in libc.
 
 >  exect is historical, but I don't think that means we need to keep it;
 >  any vintage debugger that someone might dig up in a basement will need=
 
 >  a lot of porting work anyway, and it's not like there have ever been a=
 
 >  lot of unix debuggers around.
 > =20
 
 Current execve(2) has the close meaning of legacy exect(3) anyway. For
 that legacy debugger just replace exect(3) with execve(2) call. We
 generate SIGTRAP & TRAP_EXEC unconditionally from exec() inside the
 kernel under a debugger.
 
 The original meaning of exect(3) was to enable vax-specific (and on
 386bsd 80386-specific) PT_STEP bit for a process and call execve(2). It
 was questionable because:
 
 1. enabling it without attached debugger is insane
 2. very MD-specific implementation
 3. it need to perform steps hundreds of steps before switch to a new proc=
 ess
 
 It's also not that useful, as there are more convenient replacements of
 the execve(2) semantics, like execlp(3) and others.
 
 >  --=20
 >  David A. Holland
 >  dholland%netbsd.org@localhost
 > =20
 >=20
 
 
 --RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm--
 
 --rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJYfEuxAAoJEEuzCOmwLnZsfbwQAJzDtcvvv7PE2K+FMJhs5fPS
 t7Cp9XjoOOA/CvDhbPKlcRqAB3QHr1SbVssoTKfbI80javSCIDPFedqPa5+Qvqrb
 5W3fb7RECxkV5sUzCjKIDdqgrJk8lxyFI8BdUwab0ZYGZrHByzMSseTvlGwjbn/F
 P5wlvLiEG9HreFhGRlRBkLNhBq/HSQjeBhtGDKtypESl9+LbNQ7WaTd6rGPCNUwk
 lWCKpi09V3zvFaDt98XeZpluwpl2Cl2AlOaxAS4UaDQzifvy30ZWwxicWoptnBxn
 vtwWUHxoxDqChYm0qLTF3FOQNb91D7iHd2CSidbdMlVRG1ZVRzU16BOgHUyyLGUz
 pGNGpQpWSzoiCHgmPcyvHKed5P1YhVgMcHeEbeOf7Vq7433Wf7ZTnb0RiW38t1te
 xt7oudgAoWUhUn+HI52RUdmEVTtKBJZDXeod1k5bMmjYVDlvu2RirbXuRBvPGa1C
 T2Lq/3OWt9v/k34uQ7joqB+xDwwgoSdK/QEZbJgu286jDAR7dW/0wmyvkT9JUqEG
 lYyFljVac+FzdzumsGGxkD6nvP+9fvRnZzxb5TGsFP0YV/tvK+2HhM4ADjXm45d2
 JYotltsmk+dD0TK4xgfhLD2PVksicmrvyG3b3ccnq2GvTeQRvtlWyZfejnr0PSUk
 zzfCypQSBILiU+tKD4po
 =T5VM
 -----END PGP SIGNATURE-----
 
 --rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe--