The following diff constifies the strings in cnames[]. No functional
change.
Index: cname.h
===
RCS file: /OpenBSD/src/lib/libc/regex/cname.h,v
retrieving revision 1.5
diff -u -p -r1.5 cname.h
--- cname.h 2 Jun 2003 20:18:36 -
cclasses[] multis field is always an empty string. Remove it and code
dealing with it. This code was incomplete anyway.
Index: cclass.h
===
RCS file: /OpenBSD/src/lib/libc/regex/cclass.h,v
retrieving revision 1.6
diff -u -p -r1.6 ccla
The following diff constifies the strings in regerror.c and also makes
use of the strlcpy() return value to avoid a redundant strlen() call.
Index: regerror.c
===
RCS file: /OpenBSD/src/lib/libc/regex/regerror.c,v
retrieving revision
regcomp.c uses the "start + count < end" idiom to check that there are
"count" bytes available in an array of char "start" and "end" both point
to.
This is fine, unless "start + count" goes beyond the last element of the
array. In this case, pedantic interpretation of the C standard makes
the comp
Up until 6.5, sparc64 bsd.rd were gzipped kernels. This got lost during
the Great Installation Media Unification of the 6.6 release cycle, and
since then bsd.rd are uncompressed.
The following diff ought to fix this and bring back sparc64 netboot
times down to acceptable times.
Index: miniroot/Ma
Spencer's code was written before const was a thing, but we can do
better. Neither regcomp(3) nor regex(3) modify the strings they are
being passed, so we can keep internal pointers as const as well and
avoid {dub,spur}ious casts.
While there, the temporary array in nonnewline() can be made static
re_guts catspace[] is only written to (via categories[]), and never used
for anything, so don't bother keeping that.
Index: lib/libc/regex/regcomp.c
===
RCS file: /OpenBSD/src/lib/libc/regex/regcomp.c,v
retrieving revision 1.38
diff -
The REQUIRE macro is used to check for a condition, and set an error in
the parse struct if it is not satisfied.
This changes it from ((condition) || function call) to a, IMHO more
readable, if() test.
Index: regcomp.c
===
RCS file:
That code was written before inline functions were supported by
compilers; now that they are even part of the language standard, turn
macros into inline functions so that there is no need to document in
comments that they will evaluate their arguments multiple times.
(one may consider switching th
The removal of the categories code made these two functions unused, so
remove them as well.
Index: regcomp.c
===
RCS file: /OpenBSD/src/lib/libc/regex/regcomp.c,v
retrieving revision 1.41
diff -u -p -r1.41 regcomp.c
--- regcomp.c 31
> Is there a reason not to do
>
> return (cs->ptr[(uch)c] & cs->mask) != 0;
>
> This would allow us to get rid of the !! construct in regcomp.c
Why not. What about that?
Index: regcomp.c
===
RCS file: /OpenBSD/src/lib/libc/re
regex(3) documents non-standard extensions REG_ITOA and REG_ATOI to
regerror(). In the OpenBSD tree, the only use of them is by the regress
test, so why not move that specific code to the regress test and shrink
libc a bit - remember that this code is present in the installation
media through grep(
> Since this change went in, bsd.rd doesn't boot unless I uncompress it first.
>
> upgrade detected: switching to /bsd.upgrade
> Trying /bsd.upgrade...
> NOTE: random seed is being reused.
> Booting /pci@400/pci@2/pci@0/pci@c/nvme@0/disk@1:a/bsd.upgrade
> 4246528@0x100+5120@0x140cc00+3248796@0
> > Rebooting with command: boot bsd.rd.gz
>
> This is interesting. The change has it just being named bsd.rd, without the
> .gz.
That's just me testing a compressed bsd.rd.
> regcomp.c uses the "start + count < end" idiom to check that there are
> "count" bytes available in an array of char "start" and "end" both point
> to.
>
> This is fine, unless "start + count" goes beyond the last element of the
> array. In this case, pedantic interpretation of the C standard m
> My understanding is that HZ=100 was a practical choice because the
> machines of the day could not reliably drive a faster clock interrupt.
The VAX architecture defines a 100Hz timer, which is the only timer you
can be sure will be available to the kernel. A few of the later models
(VAXstation 4
When asking for the backtrace of a secondary processor in ddb, if that
backtrace reaches the secondary cpu startup code before the
switch_trampoline call, it will trust uninitialized stack data and is
likely to panic with an unaligned access at db_stack_trace_print+0x1d0.
(this was found the hard w
> No problem, real-life often takes precedence.
No way! operator(7) would need an update!
The following diff causes all 64-bit platforms to use the same maxusers
settings. (which in turn affects the maxprocess, maxthread, maxfiles and
initialvnodes kernel variables)
Index: sys/arch/alpha/conf/files.alpha
===
RCS file: /Ope
The code responsible for filling a page with repeated copies of the
signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0.
While this is true on all currently supported OpenBSD platforms, this
might not be the case in the future (and isn't the case on some
no-longer official platforms).
> I guess the rest of the page contains 0?
No, it contains a truncated copy of the sigcode.
> It would be better if it contained "trap" instructions. We still don't
> have an ideal way of doing that tho.
That would work, but that would make the code a bit more complicated.
And I'm not sure it's
A few platforms create pty nodes in /dev in the installation media
filesystem. That wastes 2x62 inodes on an tight filesystem.
The following diff removes these useless (since installation media
kernels lack the pty pseudo-device) /dev entries.
Miod
PS: while there, one might want to unify the cr
The following diff attempts to clean up a few loose ends in the current
MAKEDEV files:
- remove no-longer applicable device definitions (MSCP and SMD disks,
this kind of thing).
- makes sure all platforms use the same `ramdisk' target for
installation media devices, rather than a mix of `ramd'
Following the switch to ypconnect(), several fields in the dom_binding
struct used internally are no longer needed. The following diff removes
them.
Index: yp/ypinternal.h
===
RCS file: /OpenBSD/src/lib/libc/yp/ypinternal.h,v
retrievi
> Do those machines not have Coprocessor 0? If they do, why would you
> prefer glxclk over CP0?
cop0 only provides one timer, from which both the scheduling clock and
statclk are derived. glxclk allows two timers to be used, and thus can
provide a more reliable statclk (see the Torek paper, etc -
> Other platforms (architectures?) (powerpc, powerpc64, arm64, riscv64)
> multiplex their singular interrupt clock to schedule both a
> fixed-period hardclock and a pseudorandom statclock.
>
> This is the direction I intend to take every platform, mips64
> included, after the next release.
>
> In
The alpha part contains code in the kernel to handle unaligned memory
accesses from userland programs, to prevent them from dying in horrible
SIGBUS.
This made sense in the '90s, but since then people have learned to work
with strict-alignment architectures, and this code has been less and
less tr
> after a prompt from stsp@ and florian@, reporting that newfs_msdos
> fails when given an $duid.i argument, I set down to see what could be
> going on. My test using an USB stick failed to reprdouce the problem.
> Then I started using a vnd, and that shows the issue (once in a
> while). The feelin
Come to think further about it, I think it is better for diskmap to
always trust disk drivers to either :
- not have any label (dk_label == NULL, or points to zeroed memory)
or
- have a valid label (duid is not zeroes).
The following diff thus relaxes the logic to always trust
dk_label->d_uid, unl
> What is the result if root runs disklabel, and forces it to all zeros?
If the root duid is all zeroes, then the only way to refer to the root
disk is to use its /dev/{s,w}d* device name, as zero duids are ignored.
If you set a zero duid in disklabel(8), setdisklabel() in the kernel
will compute
> After about 92 hours, one machine showed cp0_raise_calls=622486 and
> another 695892. cp0_raise_miss was zero on both of them. On two other
> machines I had forgotten to allow ddb access from console and could
> not check the values.
Put kern.allowkmem=1 in /etc/sysctl.conf, and then you can do
> Well, something tells me the inclusion of the manual pages for fdisk
> and disklabel is deliberate. Makes some sense as these are complex
> utilities and their interactive use is documented in those pages.
The ability to be able to read the manual pages from the binaries
themselves, when runnin
> > The ability to be able to read the manual pages from the binaries
> > themselves, when running is interactive mode, is an intentional feature
> > and the reason they embed a gzipped version of the formatted manpage.
>
> Even in the installer?
Especially in the installer, because you might not
> What's the status on this diff?
I'm waiting for review from at least one of the softraid suspects prior
to putting this in, in case there are further cinematics to address.
> So we would get rid of all the 32-bit compat stuff from arch/sparc64?
Yes, but this has never been used, so no worries about it.
> Index: include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/sparc64/include/cpu.h,v
> retrieving revisi
The general policy in OpenBSD is to not embed ident(1) strings in
libraries. However, libelf is currently compiled with ident strings, and
thus /usr/lib/libelf* are the only files in /usr/lib sporting ident
strings.
The following diff disables them.
Index: _elftc.h
===
Constify nam2blk[] and chrtoblktbl[], these are never modified at
runtime. Plus an octeon bonus: devmap[].
Index: sys/arch/alpha/alpha/autoconf.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/alpha/autoconf.c,v
retrieving revision 1.38
di
When the kernel is low on memory, the pagedaemon thread will try various
strategies to free memory.
One of those is to ask the pmap layer to free some memory. This is done
in uvm_swapout_threads(), which is roughly a wrapper around the
invocation of pmap_collect() on behalf of all processes.
Howe
> Hey,
>
> the diff below adds FN key combos for Page Up, Page Down and some more
> on the M2 keyboard. Most of the logic was copied from ukbd.
This means most of the munging logic should move from ukbd into hidkbd,
but that can be done later.
If you don't want to do this yet, you need to addre
> Index: dev/hid/hidkbdtrans.h
> +static const struct hidkbd_translation apple_fn_trans[] = {
No effing way. Every file including this header will embed its own copy
of these tables.
Better keep the tables in their original locations. The munge interfaces
already take a pointer to a table and it
> On 16/09/22 12:20 +0000, Miod Vallat wrote:
> > > Index: dev/hid/hidkbdtrans.h
> >
> > > +static const struct hidkbd_translation apple_fn_trans[] = {
> >
> > No effing way. Every file including this header will embed its own copy
> > of these tab
> rev3:
Almost there! Minor nits below, then ok.
> Index: dev/hid/hidkbd.c
> +static const struct hidkbd_translation apple_iso_trans[] = {
> + { 53, 100 },/* less -> grave */
> + { 100, 53 }
> +};
> +
> +static const struct hidkbd_translation apple_iso_mba_trans[] = {
> + { 53, 1
> I've also removed the hidkbd_apple_mba_iso_munge() function as it is
> the same as hidkbd_apple_iso_munge() so this also cleans up the switch
> in ukbd.c
Oh no, it isn't.
See, you are in a maze of twisty little functions, all alike.
The current state of ukbd has four apple munge routines:
- "
> Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> being assigned to
> newly created 'sc_fn' inside 'hidkbd'
Argh, sorry about that.
Does the following diff fix the problem on your machine?
Index: ukbd.c
===
> +.if (${COMPILER_VERSION:L} != "clang" && ! exists(/usr/local/bin/eg++))
> +regress:
> + @echo 'Run "pkg_add g++" to run unittests on GCC architectures'
> + @echo SKIPPED
Or the C++ test could be downgraded to C++98 so that it may be used on
all supported platforms:
Index: utils_unittes
> This patch switches sparc64 to clockintr(9).
[...]
> Testing on the UltraSPARC IIe ("Hummingbird") would also be helpful.
> Apparently it has %SYS_TICK and %SYS_TICK_COMPARE, but in an unusual
> hardware configuration. I imagine this machine is a bit rare, though.
All Sun Blade 100 and 150 ar
The following diff removes the last mentions of the sun4 old style
eeprom behaviour in the eeprom(8) manual page, as well as options
specific to it.
Index: eeprom.8
===
RCS file: /OpenBSD/src/usr.sbin/eeprom/eeprom.8,v
retrieving revi
> This actually breaks my machine. malloc() is saying allocation too
> large. OF_getproplen will return -1 on that. Is it possible that
> len is treated as uint64_t as it is an int and sizeof is effectively
> uint64_t?
Ah, yes; size_t is unsigned and wider than int on 64-bit platforms,
therefor
I'm a bit late to the thread, but whatever its outcome, things have to
work correctly on older sparc64 hardware, where the default behaviour
for on-board and Sun-branded expansion card interfaces is to use the
same MAC address.
This hints that hostname. should have priority over
hoshname. for the
> Here is a diff. Maybe bluhm@ can try this on the macppc machine that
> triggered the original "vref used where vget required" problem?
On a similar machine it panics after a few hours with:
panic: uvn_flush: PGO_SYNCIO return 'try again' error (impossible)
The trace (transcribed by hand) is
u
> Now that we have request_sleep() we can add a new internal KS_Cmd_Sleep
> keycode, map it into the macbook keyboard, catch in wskbd and go to sleep.
>
> ok?
> --- sys/dev/usb/ukbdmap.c
> +++ sys/dev/usb/ukbdmap.c
> @@ -176,6 +176,7 @@ static const keysym_t ukbd_keydesc_us[] = {
> KC(127),
> On, at least, some Chromebook PS/2 protocol is implemented by EC rather
> than a real PS/2 controller. It works fine except for 2 things:
> * Unusual layout like multimedia keys instead of F*
> * Reset command returns garbage (usually last key)
> This patch attempts to handle later as it stops ke
I have had a look at your diff and I think it's decent enough to go in
after some polishing.
Can Wacom tablet users try this cleaned up diff?
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving revision 1.5
> On Sat, Aug 12, 2023 at 08:00:48AM +0000, Miod Vallat wrote:
> > I have had a look at your diff and I think it's decent enough to go in
> > after some polishing.
> >
> > Can Wacom tablet users try this cleaned up diff?
>
> Hi,
>
> My WACOM table
Third time's (hopefully) the charm. How about that diff? Too much things
have been removed in uwacom.
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving revision 1.5
diff -u -p -r1.5 hid.c
--- dev/hid/hid.c
> On Sat, Aug 12, 2023 at 02:27:13PM +0000, Miod Vallat wrote:
> > Third time's (hopefully) the charm. How about that diff? Too much things
> > have been removed in uwacom.
>
> partial success! The wacom driver is recognized, no panics this time. But
> the input is
> CC'ed back the mailing list.
Oops, I thought I had replied to the list as well, my bad.
> Tested your patch. It works on my Chromebook.
Excellent. It's in!
Thanks,
Miod
> lines 195 and 196. Now my question, does this not sorta look wrong?
>
> Shouldn't these values be a little more unique? As in not the same?
No, these are correct. These lines are used when the compiler does not
support __predict_false and __predict_true, so __predict_whaterver(x)
has to behav
I had the misfortune of hitting a KASSERT in dwge:
panic: kernel diagnostic assertion "len > 0" failed: file "/usr/src/sys/dev/fdt
/if_dwge.c", line 1102
Stopped at panic+0x106:addia0,zero,256TIDPIDUID PR
FLAGS PFLAGS CPU COMMAND
*405136 98879 1500 0x3
> Stuart, Miod, I wonder if this also help for the off-by-one issue you
> are seeing. It might not.
It makes the aforementioned issue disappear on the affected machine.
> Comments, ok?
> diff --git sys/uvm/uvm_pdaemon.c sys/uvm/uvm_pdaemon.c
> index 284211d226c..a26a776df67 100644
> --- sys/uvm
> On 21/10/23(Sat) 14:28, Miod Vallat wrote:
> > > Stuart, Miod, I wonder if this also help for the off-by-one issue you
> > > are seeing. It might not.
> >
> > It makes the aforementioned issue disappear on the affected machine.
>
> Thanks at lot for te
> I wonder if the diff below makes a difference. It's hard to debug and it
> might be worth adding a counter for bad swap slots.
It did not help (but your diff is probably correct).
> Index: uvm/uvm_anon.c
> ===
> RCS file: /cvs/src
This ensures consistent spelling of set-{user,group}-ID, and also
mentions LD_DEBUG is ignored by ld.so for such binaries.
Index: ld.so.1
===
RCS file: /OpenBSD/src/libexec/ld.so/ld.so.1,v
retrieving revision 1.23
diff -u -p -r1.23 ld
> For instance, in the wsdisplay_emulops structure, there are:
>
> int (*alloc_attr)(void *c, int fg, int bg, int flags, long *attrp);
> void (*unpack_attr)(void *c, long attr, int *fg, int *bg, int *ul);
>
> And at the end of the structure is this comment, showing that at
> least someone (oth
> Learning how LDOMs work on this T4-1 and we only create 8 devices
> (each /dev/ldom* and /dev/ttyV*) by default. The now-commonly-available
> T4-1 machines can do far more than that pretty easily, so bump up the
> number created by default from 8 to 16.
>
> ok?
MAKEDEV is a generated file. Edi
There seems to be a logic error in tcpdump's print-gtp.c.
The code is printing some values by passing a pointer to the array of
strings, and the index within the array, and the routine uses
sizeof(array) / sizeof(array[0]) to figure out the bound.
But since the caller is passing a pointer, sizeof
Yet another case where the emulator does not match the real hardware.
Why bother with them?
Get qemu to fix their shit so that the frame buffer metrics variable are
aligned on 64-bit boundaries. There might not be a written specification
for this requirement, but that's the way real hardware beha
> There is an interest in supporting PowerPC 970 ("G5"). That would
> allow people to use more than 2G of RAM on the last generations of
> Apple PowerMac machines. Otherwise I don't think we are interested in
> anything before POWER8.
Years ago, a decision was made to ditch 64-bit PA-RISC (mos
>> 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?
>
> I don't think it is available on gcc 3.x for m88k but someone with
> an m88k should confirm.
__builtin_popcount() does not exi
The todr_handle struct contains two unused function pointers, which are
either not implemented or with clones of eopnotsupp(). The following
diff removes this waste of kernel text.
Index: arch/sparc64/dev/rtc.c
===
RCS file: /OpenBSD/
`return f()' when f is a void function is not allowed by the C standard
but is a gcc extension.
Index: com.c
===
RCS file: /OpenBSD/src/sys/dev/ic/com.c,v
retrieving revision 1.173
diff -u -p -r1.173 com.c
--- com.c 14 Aug 2020
All the is*() ctype.h functions take an int as argument, but valid
values are only EOF, and the range of values of `unsigned char'.
All, but one: the XPG4 isascii(), which has no such restriction.
Quoting https://pubs.opengroup.org/onlinepubs/9699919799/ :
``The isascii() function is defined on al
emul.c r1.19 removed a bunch of code, but not enough, and left dead code
around.
Index: emul.c
===
RCS file: /OpenBSD/src/sys/arch/sparc64/sparc64/emul.c,v
retrieving revision 1.23
diff -u -p -r1.23 emul.c
--- emul.c 16 Nov 2014
> The -Wshadow warning was briefly enabled, but it turned out to break vax
> builds with gcc3. Among other things, this warning helps catching stupid
> mistakes in refactoring early, so I was wondering whether we could
> re-enable it. The commit that disabled it also mentions gcc3, so I'm
> unsur
The hppa GENERIC kernel contains various debug options for pcmcia and
cardbus code. None of the other platforms enables these options in
GENERIC.
Index: sys/arch/hppa/conf/GENERIC
===
RCS file: /OpenBSD/src/sys/arch/hppa/conf/GENERIC,
In the never ending story of "encoding of diag instructions is hard,
let's go shopping" (as shown by at least rev 1.65, 1.66 and 1.189 of
hppa locore.S), the following diff attempts to clean and fix things for
good:
- macros get a cpu-family suffix, since encoding differ accross
processor fam
I have noticed, for a while, that my O2 systems were horribly slow
during installs or upgrades, when fetching sets from the network (28
*minutes* to fetch base64.tgz).
At first, I thought this was a bsd.rd specific bug, but couldn't find
anything obvious. After gathering enough data, I found out t
> An unsinged TF_TIMER does not create that problem.
Why don't you simply append an U suffix to TF_TMR_REXMT?
> Sounds like a call for the huge U change.
Since none of these #define seem to be used by .S files, go for it. We
don't really want to bring Mach's U() macro back.
in4_cksum(), used to compute packet checksums for the legacy internet
protocol, has been hand-optimized for speed on most elderly platforms,
with the most recent pieces of silicon using a portable C
implementation.
Most of these implementations, in a not-so-uncommon case, need to
checksum an extra
> Hi,
>
> linking with librpcsvc should be superfluous now.
Then you should also update DPADD to remove $(LIBRPCSVC}...
> Index: Makefile
> ===
> RCS file: /var/cvs/src/usr.bin/passwd/Makefile,v
> retrieving revision 1.41
> diff -u
> > - sum += in_cksumdata((caddr_t) &ipov, sizeof(ipov));
> > + sum += in_cksumdata((caddr_t) &ipov + 8, sizeof(ipov) - 8);
>
> I think this would be clearer with a comment.
Sure, added one.
> Please remove the trailing space that some of the changed lines have.
Ok. Updated
> The register is set to -1, all bits set, and then its upper half
> is cleared. Now that the "and" has been removed, the value seems
> unused. The result of the removed "and" seemed unused too.
Oh, indeed, you're right, that makes things even simpler.
New diff:
Index: sys/arch/alpha/alpha/in_ck
On PowerMac11,2 systems, the PCIe bus attaches as:
mpcpcibr0 at mainbus0 pci: u4-pcie
pci0 at mpcpcibr0 bus 0
However none of the devices attached to pci0 will appear in pcidump.
This is caused by an incorrect bus number during attachment of the
pci(4) subdevice. The following diff queries the `
> Index: usr.sbin/installboot/armv7_installboot.c
> ===
> RCS file: src/usr.sbin/installboot/armv7_installboot.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 armv7_installboot.c
> --- usr.sbin/installboot/armv7_installboot.c 20 Ju
> Diff below introduces an helper for sending an uncatchable SIGABRT and
> annotate that `p_siglist' and `p_sigmask' are updated using atomic
> operations.
Why not use sigexit(p, SIGABRT); for that purpose?
> Something doesn't feel right.
>
> db_kill_cmd finds a process, called p, then kills it. In your new diff
> calling sigexit, take note of the comment at the top:
>
> * Force the current process to exit with the specified signal, dumping core
>
> current process? Doesn't look like it, it look
I had noticed for years that eeprom(8) always reported failure when
attempting to change OpenFirmware environment variables on macppc.
Upon further examination, it doesn't - the variables get changed, but
error is reported. This is caused by a difference in implementation
behaviour between Apple's
> > Suggested diff below; clue from NetBSD.
> I looked for openprom code there but only found it for SPARC, can you
> point me to where you got the "clue" from exactly?
http://bxr.su/NetBSD/sys/dev/ofw/openfirmio.c#205
> Repeating diffs from i386, amd64, sh. Improve alpha diff to handle an
> additional fault case. Adding diffs for powerpc, powerc64, and m88k.
The m88k diff is incomplete:
- changes need to be done in both m88100_trap() and m88110_trap().
- the uvm_map_inentry() check should be put after the use
Exception handling code on superH and m88k does not check for a valid
stack pointer, like other platforms do.
The following (mechanical) diff addresses the m88k case, and has been
tested to work on 88100 and 88110 processors.
Index: sys/arch/m88k/m88k/trap.c
==
The following declaration has actually never been used, for `ver' is a
local in cpuattach() and locore does rdpr %ver every time it needs the
value.
Index: include/psl.h
===
RCS file: /OpenBSD/src/sys/arch/sparc64/include/psl.h,v
retr
The recent mii_tick diff made me ponder whether the mii tick timeout
could be put in the mii_data struct rather than each driver softc (not
that a good idea, actually).
While looking at this, I noticed that two drivers may end up invoking
mii_tick() while not being at IPL_NET.
bnx: bnx_tick() can
Hello,
I have noticed a few inaccuracies in the installation notes. The
following diff fixes them.
Index: hardware
===
RCS file: /OpenBSD/src/distrib/notes/loongson/hardware,v
retrieving revision 1.10
diff -u -p -r1.10 hardware
---
> Is suspend-resume not working on the lemote anymore?
It works (or used to work) on the Yeeloong, not on the Gdium (different
battery controller chip).
> The system has a trap 2, which I looked up as:
>
> #define T_TLB_LD_MISS 2 /* TLB miss on load or ifetch */
>
> what happens before this patch, I think, is that there is a varargs size_t
> (which is size 8 in mips64), that gets promoted (I think) in varargs to int
> (which wou
> Try changing all the final 0 in sppp_auth_send() to 0UL and this ought
> to work. This function needs __attribute__((__sentinel__)) as well to
> prevent such mistakes from occurring again.
The sentinel attribute wants a pointer, not a zero size_t,
unfortunately.
Please try this diff.
Index:
> What happened to this?
I need to split this into orthogonal diffs, and also since this will
expose an issue in makefs(8), I need to polish and send a fix for makefs
first...
As you may vaguely remember, I have plans to clean up MAKEDEV a bit,
which have the side effect of removing many unneeded device nodes from
the ramdisk target, used on the installation media.
Doing this will in turn expose a slight difference in filesystem
creation between the pre-makefs(8) world
> Should the default for makefs not be changed, rather than requiring an
> argument?
I'm not fond of that idea, but why not, as long as it gets documented.
> 100 seem extremely small. Imagine a person installing a machine with 5
> drives. Our installer lets people iterate over all their drives.
1 - 100 of 476 matches
Mail list logo
