ncurses has a configure option that adds a few more consts to its
headers by way of the NCURSES_CONST define. Starting with version
6.0, this has become the default. OpenBSD is still on ncurses 5.7,
but FreeBSD and I guess most Linux distributions have moved on.
I suggest we also enable the addit
Denis Fondras:
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with
> FreeBSD and Linux.
>
> I added aliases at the end of queue.h to avoid breaking base too much. they
> will
> be removed as soon as diff 2,3,4,5,6,7 are commited.
We'll need to run a ports bulk build wit
Theo de Raadt:
> What is lacking in this converstation is the justification.
> Why?
Providing STAILQ in OpenBSD will simplify porting to OpenBSD.
(Reality check: There is one port affected by this.)
Switching OpenBSD to STAILQ will simplify porting from OpenBSD.
(There are three or four FreeBSD
Denis Fondras:
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with
> FreeBSD and Linux.
>
> I added aliases at the end of queue.h to avoid breaking base too much. they
> will
> be removed as soon as diff 2,3,4,5,6,7 are commited.
>
> net/sniproxy has a patch to define S
Edgar Pettijohn:
> In the BUGS section for the getopt(3) manual it mentions not using
> single digits for options. I know spamd uses -4 and -6 there are
> probably others. Should they be changed? Or is the manual mistaken?
You misunderstand. The manual warns against the use of digits to
pass num
Make use of getline(3) in ftp(1).
Replace fparseln(3) with getline(3). This removes the only use
of libutil.a(fparseln.o) from the ramdisk.
Replace a complicated fgetln(3) idiom with the much simpler getline(3).
OK?
Index: distrib/special/ftp/Makefile
===
Hiltjo Posthuma:
> > @@ -75,19 +74,8 @@ cookie_load(void)
> > if (fp == NULL)
> > err(1, "cannot open cookie file %s", cookiefile);
> > date = time(NULL);
> > - lbuf = NULL;
> > - while ((line = fgetln(fp, &len)) != NULL) {
> > - if (line[len - 1] == '\n') {
> > -
Replace fgetln(3) with getline(3) in sed.
The mf_fgets() part is from Johann Oskarsson for Illumos/FreeBSD.
Passes our sed regression tests.
OK?
Index: usr.bin/sed/main.c
===
RCS file: /cvs/src/usr.bin/sed/main.c,v
retrieving revis
Fix a pointer dereference in disklabel(8).
This looks like somebody wrote *s[0] in place of (*s)[0].
Which in this case happens to be equivalent, but it still looks
wrong.
OK?
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sb
Replace fgetln(3) with getline(3).
OK?
Index: sbin/fdisk/misc.c
===
RCS file: /cvs/src/sbin/fdisk/misc.c,v
retrieving revision 1.63
diff -u -p -r1.63 misc.c
--- sbin/fdisk/misc.c 3 Jul 2019 03:24:01 - 1.63
+++ sbin/fdisk/
Replace fgetln(3) with getline(3).
Since getline() returns a C string, we don't need to carry around
the length separately.
OK?
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.36
Christian Weisgerber:
> Make use of getline(3) in ftp(1).
>
> Replace fparseln(3) with getline(3). This removes the only use
> of libutil.a(fparseln.o) from the ramdisk.
> Replace a complicated fgetln(3) idiom with the much simpler getline(3).
New diff that fixes a bug I intro
Christian Weisgerber:
> > Make use of getline(3) in ftp(1).
> >
> > Replace fparseln(3) with getline(3). This removes the only use
> > of libutil.a(fparseln.o) from the ramdisk.
> > Replace a complicated fgetln(3) idiom with the much simpler getline(3).
>
Alex Karle:
> Looking deeper, there is a bug in quiz(6) for datfiles with multi-line
> answers.
>
> Specifically, the following quiz.db line:
>
> foo:\
> bar
>
> Is parsed into "foo:bar\n", which made it impossible to get right (since
> the comparison was expecting a newline). T
Todd C. Miller:
> I don't think your use of qlen is safe since it is initialized
> to zero. Specifically, it looks like "qp->q_text[qlen - 1]"
> would be an out of bounds read. Should qlen be initialized
> to strlen(qp->q_text) if qp->q_text != NULL?
Right. Next iteration:
Index: quiz.c
=
Damien Miller:
> bash has a PROMPT_COMMAND that allows a command to be executed before
> each PS1 prompt is displayed. I've found this useful on occasion, so
> this is the same thing for ksh(1).
PS1 is evaluated each time the prompt is displayed. You can put a
command in $() in there.
PROMPT_CO
Martin Pieuchot:
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
This survived a full amd64 package build.
--
Christian "naddy" Weisgerber
Yuichiro NAITO:
> +static void
> +ixv_set_multi(struct ix_softc *sc)
> +{
[...]
> + if ((ifp->if_flags & IFF_PROMISC) == 0 && ac->ac_multirangecnt <= 0 &&
> + ac->ac_multicnt <= MAX_NUM_MULTICAST_ADDRESSES) {
> + ETHER_FIRST_MULTI(step, &sc->arpcom, enm);
> +
Klemens Nanni:
> If the root disk contains a valid CRYPTO volume, bioctl(8) by default
> unlocks that instead of creating a new one.
>
> Use `-C force' to prevent reuse of old volumes,
Yes, I like this. During testing I ran into the case where it
re-used an existing crypto volume and I thought
Alexander Bluhm:
> Variable scs_use is basically counting packet insertions to syn
> cache, so I would prefer type long to exclude overflow on fast
> machines. With the current limits int should be enough, but long
> does not hurt.
But long is the same size as int. On our 32-bit archs. Or are
etters."
Sigh. Yes, duplication is evil, yada, yada, but would it really
be so bad to also list the tracepoints directly in kdump.1 instead
of pointing to ktrace.1?
---
commit 6537a30531732808760afdc5dcd7331aeb9d7618 (local)
from: Christian Weisgerber
---
commit 44bc262d8170b10e6949c2836a820b7fee533de4 (local)
from: Christian Weisgerber
date: Tue Oct 24 14:09:57 2023 UTC
do not create /usr/local/share/nls and subdirectories by default
The share/nls/ paths are unused.
diff 85c70083e85910ddc7626ad658e5652c024b844a 44bc262d8170b10e6949c2836a820b7fee533
Tobias Heider:
> currently iked(8) supports AES-GCM only for ESP.
> The diff below adds the ENCR_AES_GCM_16 and ENCR_AES_GCM_12 variants for IKE.
> (for more information see [1] and [2]).
> Both variants support the 128, 196, and 256 bit key lengths.
>
> The new new ciphers can be configured with
On 2020-05-20, Martin Pieuchot wrote:
> - FreeBSD doesn't allow opening block devices in devfs_open(), so
> only character devices seem to support poll(2) and kqueue(2).
FreeBSD doesn't have block devices anymore.
--
Christian "naddy" Weisgerber na...@mips.inka.d
(This is in a different part of the file from Theo's current efforts.)
For large reads from /dev/random, use the arc4random_ctx_*() functions
instead of hand-rolling the same code to set up a temporary ChaCha
instance.
ok?
Index: rnd.c
===
Sebastien Marie:
> > For large reads from /dev/random, use the arc4random_ctx_*() functions
> > instead of hand-rolling the same code to set up a temporary ChaCha
> > instance.
>
> Eventually, I would get ride of myctx, initialize lctx to NULL, and use
> (lctx == NULL) to replace (myctx == 0).
R
Marc Espie:
> There are about 3 solutions to that:
> - change the bulk machines to /usr/ports/pobj
> - change the ports default to /usr/obj/ports
I don't think it's reasonable to expect everybody to use the same
path here.
--
Christian "naddy" Weisgerber na...@mips.inka
On 2020-05-31, "Theo de Raadt" wrote:
>> > particular timecounter type can be supported. My proposal would be to
>> > implement a function *on all architecture* that takes the clockid as
>> > an argument and returns a pointer to the function that implements
>> > support for that timecounter. On
Marc Espie:
> If I type 'c
>
> I get a ç in programs like firefox or chrome, BUT I get
> ć in xterm ?
>
> why are things different ? which program is right ?
GTK comes with its own compose rules that are occasionally different
from the default X11 ones.
Personally, I disable GTK's compose p
Theo de Raadt:
> > Then you still need to check on every call whether the clockid has
> > changed (because the kern.timecounter.hardware sysctl was changed)
> > and refetch the function pointer in that case.
>
> Then really, we should remove that sysctl support.
>
> Because otherwise I don't see
Here's a proposal for implementing cpu_rnd_messybits() as a read of
the cycle counter on alpha, powerpc, and sparc64. Since I don't have
those archs, the diff is not even compile-tested.
* alpha: RPCC is a 32-bit counter (in a 64-bit register)
* powerpc: TB is a 64-bit counter split into two regi
Here is a cpu_rnd_messybits() implementation for arm64.
It reads the virtual counter and xors it with a bit-reversed copy
of itself.
The virtual counter is used by the only timecounter implementation
used on arm64, so I assume it is generally available.
It's a 64-bit counter, which we reduce to 3
Mark Kettenis:
> > Here is a cpu_rnd_messybits() implementation for arm64.
> > It reads the virtual counter and xors it with a bit-reversed copy
> > of itself.
> >
> > The virtual counter is used by the only timecounter implementation
> > used on arm64, so I assume it is generally available.
> >
powerpc has byte-swapping 16 and 32-bit load/stores and we use those
in .
Starting with POWER7 (Power ISA v.2.06), there are also corresponding
64-bit instructions. Do we want to use those on powerpc64? Or do
we want to keep compatibility with older processors?
Index: arch/powerpc64/include/en
David Gwynne:
> > Starting with POWER7 (Power ISA v.2.06), there are also corresponding
> > 64-bit instructions. Do we want to use those on powerpc64? Or do
> > we want to keep compatibility with older processors?
>
> I'm ok with using the instructions. I can't think of what benefit compat in
On 2020-06-08, Christian Weisgerber wrote:
>> Did they also happen to add opcodes for doing swaps in registers?
>
> No.
> (I haven't looked at the vector instructions yet.)
PS: There's a vector permutate instruction, but AFAICT there is no
way to move data between g
enBSD$ */
+/*
+ * Written by Christian Weisgerber .
+ * Public domain.
+ */
+
+#include
+
+ENTRY(ffs)
+ RETGUARD_SETUP(ffs, x15)
+ rbitw1, w0
+ clz w1, w1
+ cmp w0, #0
+ csinc w0, wzr, w1, eq
+ RETGUARD_CHECK(ffs, x15)
+ ret
+END(ffs)
--
Chri
On 2020-06-08, Christian Weisgerber wrote:
> More archs to come...
Style question:
Since this mostly comes down to embedding a single special instruction
in between normal C operations, I wonder whether I should just do .c
with asm() instead of .S, and leave all the boilerplate to the
compi
ib/libkern/arch/arm64/ffs.c9 Jun 2020 18:09:11 -
@@ -0,0 +1,12 @@
+/* $OpenBSD$ */
+/*
+ * Written by Christian Weisgerber .
+ * Public domain.
+ */
+
+int ffs(int x)
+{
+ x = x & -x;
+ __asm volatile("clz %w0, %w0" : "+r" (x));
+ return (3
diff -N lib/libc/arch/aarch64/string/ffs.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libc/arch/aarch64/string/ffs.c 9 Jun 2020 19:54:21 -
@@ -0,0 +1,15 @@
+/* $OpenBSD$ */
+/*
+ * Written by Christian Weisgerber .
+ * Public domain.
+ */
+
+#include
+
+int
+ffs(int x)
+{
+
On 2020-06-09, Christian Weisgerber wrote:
> Here are optimized ffs(3) implementations for
> * arm64 (superseding the earlier ffs.S)
> * powerpc
> * powerpc64
> +int ffs(int x)
Oops, I'm going to change that to
int
ffs(int x)
before commit.
--
Christia
Mark Kettenis:
> Unfortunately that doesn't quite work. At least in my build it
> doesn't pick up .c files in the linker/arch directories.
>
> > Index: lib/libkern/arch/arm64/ffs.c
I was certain I had checked this, but indeed it doesn't work.
The Makefile rules are generated from sys/conf/file
/libkern/arch/arm64/ffs.S
diff -N lib/libkern/arch/arm64/ffs.S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/libkern/arch/arm64/ffs.S10 Jun 2020 17:38:50 -
@@ -0,0 +1,17 @@
+/* $OpenBSD$ */
+/*
+ * Written by Christian Weisgerber .
+ * Public domain.
+ */
+
+#include
+
+ENTRY(ffs
Paul Irofti:
> > This iteration of the diff adds bounds checking for tk_user and moves
> > the usertc.c stub to every arch in libc as recommanded by deraadt@.
> > It also fixes a gettimeofday issue reported by cheloha@ and tb@.
>
> Forgot to add armv7 tk_nclock entries. Noticed by benno@, thanks!
Paul Irofti:
> This iteration of the diff adds bounds checking for tk_user and moves
> the usertc.c stub to every arch in libc as recommanded by deraadt@.
> It also fixes a gettimeofday issue reported by cheloha@ and tb@.
Additionally, it changes struct timekeep in an incompatible way. ;-)
A user
Christian Weisgerber:
> Should we already bump major while the diff matures?
Oh, we can't quite bump yet. tk_major und tk_minor are only set
in exec_timekeep_map(), but aren't checked anywhere.
+ timekeep->tk_major = 0;
+ timekeep->tk_minor = 0;
Paul Irofti:
> > Additionally, it changes struct timekeep in an incompatible way. ;-)
> > A userland built before the addition of tk_nclocks is very unhappy
> > with a kernel built afterwards.
>
> I have not seen this problem and have not built a snapshot to update or go
> back. What do you mean
Paul Irofti:
[lib/libc/arch/*/gen/usertc.c]
> +int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL;
[lib/libc/sys/microtime.c]
> +static inline int
> +tc_delta(struct timekeep *tk, u_int *delta)
> +{
> + uint64_t tc;
> + if (delta == NULL || _tc_get_timecount(tk, &tc)
Paul Irofti:
> > Paul, that tk_nclocks addition isn't useful. You need to do the
> > bounds checking against the number of clocks you have implemented in
> > libc. How many clocks the kernel has implemented doesn't matter.
>
> What you are saying is that we could be in a situation where the ker
Theo de Raadt:
> The diff is growing complexity to support a future which wouldn't
> exist if attempts at *supporting all* architectures received priority.
Adding support for more archs is very simple, since you just need
to copy the corresponding get_timecounter function from the kernel.
Here's
Christian Weisgerber:
> This adds the optimized ffs(3) versions on aarch64 and powerpc to
> libc, for completeness' sake.
>
> Also add a brief regression test.
>
> OK?
Index: lib/libc/arch/aarch64/string/Makefile.inc
=
Here's a cpu_rnd_messybits() for hppa. This just steals from
itmr_get_timecount(). If we want to use the mfctl() macro, we need
to include into cpu.h. I don't know if we want
that, so I went with the explicit asm() instead.
Completely untested.
Index: sys/arch/hppa/hppa/machdep.c
===
On 2020-06-13, Theo Buehler wrote:
> Others have pointed out off-list that one can use __builtin_popcount(),
> but __builtin_parity() is exactly what I want. Is it available on all
> architectures?
The standard implementation will be perfectly fine, no need to resort
to magic compiler built-ins.
George Koehler:
> --- lib/libc/arch/powerpc/gen/usertc.c.before Sat Jun 13 21:28:50 2020
> +++ lib/libc/arch/powerpc/gen/usertc.cSat Jun 13 21:38:52 2020
> @@ -18,4 +18,19 @@
> #include
> #include
>
> -int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL;
> +int
> +tc
On 2020-06-18, Marc Espie wrote:
> What pkg_add does internally is a pipeline:
>
> ftp | signify|internal gunzip
>
> closing the end file handle should kill the whole chain.
> So I need to figure out where it goes wrong, what's the
> part that doesn't die "instantly".
That's ftp(1). Our SSL peo
On 2020-06-19, Mark Kettenis wrote:
> I'm talking about *skew*, not drift. If there is a significant drift
> you already knock out the TSC.
>
> What's needed is:
>
> 1. A bit of research of what an acceptable skew is. My hypothesis is
>that on many machines with a single socket the TSCs are
On 2020-06-19, "Theo de Raadt" wrote:
> Well... they something in ports might still look at them in
>
> Can someone from ports speak about this?
I have started an amd64 bulk build without .
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2020-06-19, Paul Irofti wrote:
> I have addressed your comments bellow, except for the CPU skew one. That
> code disables TSC for all CPUs, not just for PRIMARY. Would you like to
> walk and add code for every CPU to check the drift and then disable the
> TSC? It seems a little too much...
>
>
On 2020-06-20, Christian Weisgerber wrote:
> I can't get this revision of the diff to work on amd64:
> * patch source
> * build and install kernel, reboot
> * make build
> * reboot -> "Process (pid 1) got signal 11"
>
> I'm at a loss. As part of the &
Paul Irofti:
> This also handles negative skew values that my prevoius diff did not.
> --- sys/arch/amd64/amd64/tsc.c
> +++ sys/arch/amd64/amd64/tsc.c
> @@ -216,6 +217,8 @@ tsc_get_timecount(struct timecounter *tc)
> void
> tsc_timecounter_init(struct cpu_info *ci, uint64_t cpufreq)
> {
> +
Paul Irofti:
> Can't test right now, but if you enable the TSC_DEBUG in cpu.c or if you
> put a printf in the CPU_INFO_FOREACH you will probably see the correct
> skew values.
It's worse: CPU_INFO_FOREACH() only sees cpu0. The others aren't
attached yet.
--
Christian "naddy" Weisgerber
On 2020-06-20, Christian Weisgerber wrote:
>> Well... they something in ports might still look at them in
>>
>>
>> Can someone from ports speak about this?
>
> I have started an amd64 bulk build without .
There were no build failures attributable to t
Paul Irofti:
> > b) Revert _timekeep init (breaks naddy@'s machine)
>
> Robert helped properly track down this issue to a silly null-ref.
If that was indeed the problem...
> --- lib/libc/dlfcn/init.c
> +++ lib/libc/dlfcn/init.c
> @@ -105,6 +107,14 @@ _libc_preinit(int argc, char **argv, char
Paul Irofti:
[Unrelated, just to mark where we're at]
> Right. Just reproduced it here. This moves the check at the top so that
> each CPU checks its own skew and disables tc_user if necessary.
I tweaked the patch locally to make _timekeep a visible global
symbol in libc.
Printing its value has
Christian Weisgerber:
> I tweaked the patch locally to make _timekeep a visible global
> symbol in libc.
>
> Printing its value has revealed two issues:
>
> * The timekeep page is mapped to the same address for every process.
> It changes across reboots, but once running,
Paul Irofti:
> 683 /* map the process's timekeep page */
> 684 if (exec_timekeep_map(pr))
> 685 goto free_pack_abort;
> 686 /* setup new registers and do misc. setup. */
> 687 if (pack.ep_emul->e_fixup != NULL) {
> 688 if ((*pack.ep_e
Christian Weisgerber:
> If I move
>
> vaddr_t ps_timekeep;/* User pointer to timekeep */
>
> up into the zeroed area, I get a properly randomized _timekeep in
> userland.
Also note that exec_sigcode_map() has this
pr->ps_si
The freedb.org CD track database is dead. Its shutdown had already
been announced for March, and it finally disappeared.
gnudb.org, whoever they are, offers the last working alternative
that still supports the CDDB protocol. Actually, the port was dead
yesterday, but they fixed it today. I sugg
20:31:19 -
@@ -0,0 +1,18 @@
+/* $OpenBSD$ */
+/*
+ * Written by Christian Weisgerber .
+ * Public domain.
+ */
+
+#include "DEFS.h"
+
+ENTRY(ffs)
+ RETGUARD_SETUP(ffs, x15)
+ rbitw1, w0
+ clz w1, w1
+ cmp w0, wzr
+ csinc w0, w
Well, I suggested it, so here's my attempt to switch powerpc64's
libc memmove.S over to 64 bits:
* Treat length parameter as 64 bits (size_t) instead of 32 (u_int).
* Set up the main loop to copy 64-bit doublewords instead of 32-bit
words.
This definitely needs double and triple checking.
Thing
Christian Weisgerber:
> Well, I suggested it, so here's my attempt to switch powerpc64's
> libc memmove.S over to 64 bits:
Actually, on second thought:
That function simply copies as many (double)words plus a tail of
bytes as the length argument specifies. Neither source nor
Martin Pieuchot:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
>
> I'd be interested to have this tested and see how much does t
Christian Weisgerber:
> > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> > both amd64 and sparc64. That means the kernel lock will only be taken
> > for lower faults and some amap/anon code will now run without it.
>
> I ran an amd64 bulk bui
Marc Espie:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Let's start the discussion with this instead.
This puts the deprecation notice in getopt.1 in a prominent place,
and uses the same snippet in sh.1 and ksh.1.
Index: bin/ksh/ksh.1
In this auxiliary script, replace the deprecated getopt with getopts.
There is no pressing reason to do so, but let's stop perpetuating
an obsolete idiom.
ok?
Index: usr.sbin/switchd/genmap.sh
===
RCS file: /cvs/src/usr.sbin/switchd/
Jason McIntyre:
> - i'm ok with the getopt.1 and ksh.1 parts
> - i'm not ok with the addition to sh.1
>
> no one has really given a good reason why they think it should go into
> sh.1. i've given a few why i think it should not.
My understanding is that sh.1 is a subset of ksh.1, describing the
Marc Espie:
> I would also actually be fairly happy if we changed drastically the way
> sh(1) and ksh(1) look. To me, sh(1) should be the (more or less) standard
> shell documentation, AND ksh(1) should contain the differences/extensions.
I think that is a terrible idea. Historically the tcsh(1)
Visa Hankala:
> However, wouldn't it be better if the code avoided the
> situation, for example by defining ADJFREQ_MIN as the negative
> of ADJFREQ_MAX?
Indeed it would. ok naddy@
> --- kern/kern_time.c 23 Dec 2020 20:45:02 - 1.151
> +++ kern/kern_time.c 30 May 2021 15:38:09 -
>
Damien Miller:
> Just a head-up: snaps currently contain a set of changes[1] to
> make scp(1) use the SFTP protocol by default.
> Please report any incompatibilities or bugs that you encounter here
> (tech@), to bugs@ or to openssh@.
An obvious cosmetic difference is that relative paths are pref
"Theo de Raadt":
> 2) With very long names, it truncates the end of the path. This is less useful
> information. Imagine a copy operation with multiple files being transferred,
> one of them is huge and surprisingly long, but you cannot identify which one
> because all the truncated long paths ar
scp: tweak documentation and error message for -3 by default
Now that the -3 option is enabled by default, flip the documentation
and an error message from "requires -3" to "blocked by -R".
OK?
diff 453220bf36dcff10addeceb44e98f71bfeddcd53
f457be8f3b007fb662dd10fb565ab79b602109f5
blob - 97226
Ingo Schwarze:
> deraadt@ recently pointed out to me in private mail that it is good
> for usability if interactive programs providing line editing
> functionality are consistent what they do with Ctrl-C, ideally
> discard the current input line and provide a fresh prompt.
>
> So i propose to do
Since the VAX port was discontinued, all our remaining architectures
use IEEE floating point, as will any future ones.
For this reason, I would like to remove all of libm/noieee_src,
which is unused now. I don't quite know how to actually prove that
it is unused, but
* I grepped the full src tree
I noticed this curious error in a package bulk build:
Use of uninitialized value $pid in numeric eq (==) at
/usr/libdata/perl5/LT/Exec.pm line 96.
Perl's fork() wrapper returns undef rather than -1 on error.
Handle this correctly. OK?
Index: LT/Exec.pm
==
Is there a reason ssh doesn't consult services(5) for port numbers?
This has irked me forever. I'd rather write ssh -L icb:localhost:icb
instead of ssh -L 7326, wait, 7236, uhm, grep icb /etc/services...
I don't think there is any syntactic ambiguity since Unix sockets
already must contain a '/'
In the pkill man page, clarify that the patterns are EXTENDED regular
expressions. I shouldn't have to guess, try, or look at the source
for this.
ok?
Index: pkill.1
===
RCS file: /cvs/src/usr.bin/pkill/pkill.1,v
retrieving revision
There are some instances under src/gnu of Makefile.bsd-wrapper
failing to pass variables like CC to a configure script. As a
result, the configure tests are actually run with gcc (!) on amd64
and i386. The patch below fixes
lib/libiberty
usr.bin/binutils
usr.bin/binutils-2.17
usr.bin/cvs
Currently, building an amd64 or i386 kernel with lld breaks in
makegap.sh. It turns out that we already have the missing pieces
(gapdummy) on some other archs, so we can just copy them.
With this, I can successfully build and run
* amd64 kernel with ld.bfd
* i386 kernel with ld.bfd
* amd64 kerne
Some architectures generate a gapdummy.c file for kernel builds.
Add this to the "clean" target.
OK?
Index: arch/arm64/conf/Makefile.arm64
===
RCS file: /cvs/src/sys/arch/arm64/conf/Makefile.arm64,v
retrieving revision 1.28
diff -u -
The sys/arch/*/include/endian.h headers were the only place in the
whole source tree that used __statement(), and they did so to mark
statement expressions, which are a GNU extension.
With this single consumer gone, we can garbage-collect the __statement()
macro itself. I don't think this usage w
Provide an MD 64-bit byteswapping function build on 32-bit swaps
as we do on arm and i386. Copied from arm.
If there are no MD byteswapping functions, MI macros are used.
These are wrapped by static inline functions to prevent multiple
evaluation of their argument. If there are MD functions, the
Mark Kettenis:
> > Currently, building an amd64 or i386 kernel with lld breaks in
> > makegap.sh. It turns out that we already have the missing pieces
> > (gapdummy) on some other archs, so we can just copy them.
>
> Any reason why you didn't commit this yet?
Theo was concerned that this might
I ran across this:
$ readelf -h /usr/local/bin/w3m
...
readelf(71968) in free(): bogus pointer (double free?) 0x1
Abort trap (core dumped)
In readelf.c there's a static arrary:
static bfd_vma dynamic_info[DT_JMPREL + 1];
Later this array is written to like this:
switch (entry->d_ta
Move the calculation of the entry point to after the description
of the .text section. LOADADDR(.text) is not available earlier
with lld.
With this, lld builds working kernels on i386.
Also: Should this be __start_phys? It seems odd that we put a
non-reserved symbol into the kernel namespace.
Correct linker emulation name for lld when building i386 kernels
on amd64.
(Does anybody build i386 kernels on amd64? Apparently nobody has
since the lld switch.)
Index: sys/arch/i386/conf/Makefile.i386
===
RCS file: /cvs/src/sys/ar
Mark Kettenis:
> I wonder though whether we can simply replace ENTRY(start_phys) with
> ENTRY(start) like we do on amd64. The bootloader strips the high bits
> from the entry point address already, so using the virtual address as
> the entry point address should work.
/me builds & boots kernel .
The oft-copied parse.y code declares some variables as "unsigned char *"
but passes them to functions that take "char *" arguments and doesn't
make any use of the unsigned property.
For OpenBSD's clang, -Wpointer-sign has been disabled by default,
but when that code is built elsewhere, the compile
Christian Weisgerber:
> The oft-copied parse.y code declares some variables as "unsigned char *"
> but passes them to functions that take "char *" arguments and doesn't
> make any use of the unsigned property.
While I'm here...
> int
>
Todd C. Miller:
> lungetc((u_char)*p);
> ...
> c = (u_char)*--p;
>
> Since we use casts sparingly, when they are present they indicate
> something you need to pay attention to. That is not the case when
> we simply change the type.
Unfortunately that also affects the parsebuf/
Todd C. Miller:
> On Thu, 30 Sep 2021 21:37:06 +0200, Christian Weisgerber wrote:
>
> > Unfortunately that also affects the parsebuf/pushback_buffer complex
> > used in some parser.y files.
>
> That would require a few extra casts but it is straightforward.
E.g. lik
1 - 100 of 589 matches
Mail list logo
