more MAKEDEV cleanup

2021-04-05 Thread Miod Vallat
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

no ptys on ramdisk filesystems

2021-03-29 Thread Miod Vallat
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

Re: safer sigcode page filling

2021-03-08 Thread Miod Vallat
> 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

safer sigcode page filling

2021-03-08 Thread Miod Vallat
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).

harmonize maxusers on 64-bit platforms

2021-02-28 Thread Miod Vallat
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:

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Miod Vallat
> No problem, real-life often takes precedence. No way! operator(7) would need an update!

hppa: terminate backtrace of secondary processors

2021-02-07 Thread Miod Vallat
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

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-14 Thread Miod Vallat
> 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

Re: libc/regex: safer pointer arithmetic

2021-01-03 Thread Miod Vallat
> 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

Re: compress sparc64 bsd.rd

2021-01-03 Thread Miod Vallat
> > 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.

Re: compress sparc64 bsd.rd

2021-01-03 Thread Miod Vallat
> 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 >

libc/regex: drop debug helpers

2021-01-03 Thread Miod Vallat
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

Re: libc/regex: turn unsafe macros to inline functions

2021-01-03 Thread Miod Vallat
> 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:

libc/regex: turn unsafe macros to inline functions

2021-01-02 Thread Miod Vallat
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

libc/regex: more dead code

2021-01-02 Thread Miod Vallat
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

libc/regex: more regular error handling

2020-12-30 Thread Miod Vallat
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:

libc/regex: drop more unused data

2020-12-30 Thread Miod Vallat
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

libc/regex: const'r'us

2020-12-30 Thread Miod Vallat
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

compress sparc64 bsd.rd

2020-12-30 Thread Miod Vallat
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:

libc/regex: safer pointer arithmetic

2020-12-29 Thread Miod Vallat
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

libc/regex: regerror minor tweaks

2020-12-29 Thread Miod Vallat
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

libc/regex: remove dead code

2020-12-29 Thread Miod Vallat
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

libc/regex: constify more data

2020-12-29 Thread Miod Vallat
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

Re: uvm_map_inentry() checks in trap()

2020-09-25 Thread Miod Vallat
> 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

Re: fix eeprom(8) on macppc

2020-09-20 Thread Miod Vallat
> > 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

fix eeprom(8) on macppc

2020-09-20 Thread Miod Vallat
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

Re: sigabort(), p_sigmask & p_siglist

2020-09-16 Thread Miod Vallat
> 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

Re: sigabort(), p_sigmask & p_siglist

2020-09-16 Thread Miod Vallat
> 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?

Re: symmetric toeplitz hashing

2020-06-14 Thread Miod Vallat
>> 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

Re: powerpc64: ldbrx/stdbrx for endian.h?

2020-06-08 Thread Miod Vallat
> 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

Re: sparc64 boot issue on qemu

2020-05-30 Thread Miod Vallat
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

tcpdump gtp bugfix

2020-05-19 Thread Miod Vallat
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,

Re: Increase default number of devices created for LDOMs on sparc64

2020-05-18 Thread Miod Vallat
> 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.

Re: Code changes for clarity

2020-05-18 Thread Miod Vallat
> 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

ld.so and ldconfig manpage nits

2020-05-08 Thread Miod Vallat
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

Re: Kill indirect configuration in autoconf(9)

2020-01-21 Thread Miod Vallat
>> While discussing recent config_detach(9) vs close(2) race I figured >> out that the 'indirect' flag (`cd_indirect') is never set. Some struct cfdriver initialize it to 1. See isa_cd in sys/dev/isa/isa.c. >> Time to kill this feature? Please don't.

Re: fd(4): tsleep(9) -> tsleep_nsec(9), timeout_add(9) -> timeout_add_msec(9)

2020-01-07 Thread Miod Vallat
> Convert ticks to milliseconds. > > The 33 milliseconds in the timeout_add_msec(9) call will be truncated > to 3 ticks, but that was already the case with the current (hz / 30) > code so this is no worse. [...] > /* allow 1/30 second for heads to settle */ > -

sparc64: simplify boot()

2020-01-03 Thread Miod Vallat
Although Open Firmware supports it, there is no way from OpenBSD to reboot with a specified boot command line, so drop vestigial support for it from boot(). Index: sparc64/machdep.c === RCS file:

sparc64: kill BOOT_ARG

2020-01-03 Thread Miod Vallat
BOOT_ARG from is a NetBSDism which did not make its way to OpenBSD, where parsing kernel commandline options is done inline. It is no surprise then, that it is only used by the sparc64 boot blocks; but boot blocks really only care about one option, -a, so there is no need to check for more

Re: TIMESPEC_TO_NSEC(), futex(2) & __thrsleep(2)

2019-12-31 Thread Miod Vallat
> Should we use inline instead of __inline for new code? inline is a C99 keyword, C99 is 20 years old now, and the kernel source is using C99 named initializers, therefore it is safe to assume C99 support from the compiler. It's time to stop defining __const, __inline, __signed and __volatile in

sparc64: remove bogus comment

2019-12-31 Thread Miod Vallat
sparc_bus_protect() was copied from uvm_chgkprot() (which was a KGDB support routine and is no longer present in uvm_glue.c). The "cheezy hack" comment predates the pmap_extract() interface change of 2001 (uvm_glue.c 1.15) and ought to have been removed back then. Index: machdep.c

grep -R with no path

2019-12-02 Thread Miod Vallat
grep(1), when invoked with the -R option but no path, displays a "recursive search of stdin" warning and acts as if -R had not been specified. GNU grep, in that case, will perform a recursive search in the current directory, i.e. uses an implicit "." path if none is given. This is IMO a much

Re: syscall call-from verification

2019-11-28 Thread Miod Vallat
> For dynamic binaries, valid regions are ld.so's text segment, the signal > trampoline, and libc.so's text segment... AND the main program's text. > > Unfortunately our current go build model hasn't followed solaris/macos > approach yet of calling libc stubs, and uses the inappropriate "embed >

Re: ppppoe octeon kernel panic .6.6

2019-10-23 Thread Miod Vallat
> 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:

Re: ppppoe octeon kernel panic .6.6

2019-10-23 Thread Miod Vallat
> 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

Re: minor INSTALL.loongson tweaks

2019-08-13 Thread Miod Vallat
> 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).

minor INSTALL.loongson tweaks

2019-08-10 Thread Miod Vallat
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

missing splnet in network drivers

2019-07-03 Thread Miod Vallat
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()

unused sparc64 extern

2019-06-29 Thread Miod Vallat
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

missing trap.c code for m88k

2019-06-17 Thread Miod Vallat
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

Re: free() sizes in zlib

2019-05-14 Thread Miod Vallat
> I have serious doubt whether the whole "plan" for using the sizes to > change the malloc implementation is feasable. The drm(4) code for > example relies on emulation of Linux memory allocation APIs to keep > the diffs small and jsg@ and myself sane. Most of these APIs don't > pass sizes in

free() sizes in zlib

2019-05-14 Thread Miod Vallat
This tries to keep diffability against upstream, hence a questionable choice of the size type for zcfree() - but all sizes should fit in 32 bits anyway. Since all zcfree routines used in the tree cope with NULL arguments (including the various alloc.c used by the boot blocks), I have simplified

free() sizes for ahc(4)

2019-05-14 Thread Miod Vallat
Note ahc_set_name() gets invoked with the dv_xname field of a struct device, so it's not a good idea to free anything, should it be invoked more than once. Tested on: ahc0 at pci0 dev 1 function 0 "Adaptec AIC-7880" rev 0x00: irq 8 ahc0: Host Adapter Bios disabled. Using default SCSI device

free() sizes in sys/arch/alpha

2019-05-13 Thread Miod Vallat
Index: dev/sgmap_common.c === RCS file: /OpenBSD/src/sys/arch/alpha/dev/sgmap_common.c,v retrieving revision 1.14 diff -u -p -r1.14 sgmap_common.c --- dev/sgmap_common.c 9 Dec 2014 06:58:28 - 1.14 +++ dev/sgmap_common.c 13

Re: Removing PF

2019-04-01 Thread Miod Vallat
> Will the bpf JIT changes be done in time for 6.6? I have no doubt > that "pfctl -p /dev/bfp" can be made to work in time but for a truly > performant firewall we will need bpf JIT. I wrote a vax BPF jit as a simple exercize some time ago, so all you really need now is to implement

Re: replacing timeout_add() with timeout_add_msec()

2019-01-21 Thread Miod Vallat
> The intent was to wait a 30th of a second. In practice it has always > fired 30ms hence. It's a magic number, so I'd just call it 30ms. > miod might have an opinion on whether those extra milliseconds would > be useful in the event that sparc64 is ever able to timeout with > millisecond or

Re: minor ttyflags(8) diff

2019-01-13 Thread Miod Vallat
> > Opening a pseudo-tty (/dev/tty[p-zP-T][0-9a-zA-Z]) causes the kernel to > > allocate a struct tty for it, as well as ring buffers for tty data. This > > memory will not get released if the pseudo-tty is closed, for it may be > > opened again in the future. > > The change seems reasonable to

minor ttyflags(8) diff

2019-01-13 Thread Miod Vallat
Opening a pseudo-tty (/dev/tty[p-zP-T][0-9a-zA-Z]) causes the kernel to allocate a struct tty for it, as well as ring buffers for tty data. This memory will not get released if the pseudo-tty is closed, for it may be opened again in the future. On pseudo-ttys, the largest possible ring buffer

SGI O2 mec(4) cold boot issue (and workaround)

2018-12-08 Thread Miod Vallat
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

hppa minor cleanup

2018-11-15 Thread Miod Vallat
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

Remove debug options in hppa GENERIC

2018-11-03 Thread Miod Vallat
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:

Re: re-enable -Wshadow for openssl(1)?

2018-08-23 Thread Miod Vallat
> 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 >

[sparc64] dead code in emul.c

2018-08-07 Thread Miod Vallat
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

Re: reduce hppa interrupt guts awfulness

2018-05-03 Thread Miod Vallat
> Regarding your diff. The approach seems reasonable to me. The magic > number in the gscbus.c doesn't fill me with joy. > > > + r[4] = cpu_gethpa(0) | (31 - irqbit); /* iar */ > > I realise you're following existing practice, but maybe you could you > add a gscbus_reg struct

unbreak gsckbc (possibly iockbc and mkbc)

2018-05-03 Thread Miod Vallat
sys/dev/pckbc/pckbd.c introduces a buglet, where the value computed for local variable `table' in pckbd_set_xtscancode() in the non-translating case, is overwritten by accident. Unfortunately, this means that the keyboard ends up using a scancode set which is not the one expected by the driver,

Re: avoid uninitialised attr in rasops_scrollback()

2018-05-01 Thread Miod Vallat
> Thanks, looks good/ok. Shouldn't the eraserows call in > rasops_doswitch() also use scr->rs_defattr for the attr argument? Yes, indeed. Good catch!

reduce hppa interrupt guts awfulness

2018-05-01 Thread Miod Vallat
[this is long, and hppa-specific, feel free to ignore if you don't care about OpenBSD/hppa. Noone does anyway nowadays] At the beginning of the hppa port, no interrupts were shared - the processor allows for 32 interrupt sources and the existing designs made sure to allocate distinct interrupts

Re: avoid uninitialised attr in rasops_scrollback()

2018-05-01 Thread Miod Vallat
> scrollback isn't part of wsdisplay_emulops but rather wsdisplay_accessops. > It isn't clear how to properly get an attr in wsscrollback() > GETCHAR/getchar is part of wsmoused and sc->sc_accessops->getchar > may be NULL. Ok, ignore that. There is a simpler solution. Index: rasops.c

Re: avoid uninitialised attr in rasops_scrollback()

2018-04-30 Thread Miod Vallat
> On Sun, Apr 29, 2018 at 09:42:00AM +0000, Miod Vallat wrote: > > > > > Don't use attr uninitialised. Avoids glitches seen when using > > > scrollback with radeondrm. > > > > That's horrible. The bg attribute should be passed to the function, > >

Re: avoid uninitialised attr in rasops_scrollback()

2018-04-29 Thread Miod Vallat
> Don't use attr uninitialised. Avoids glitches seen when using > scrollback with radeondrm. That's horrible. The bg attribute should be passed to the function, rather than computed here with possibly wrong values.

Re: Stop ping telling world its pid

2018-04-12 Thread Miod Vallat
> what we need is an eventually consistent 16 bit number microservice message > bus that all ping processes can subscribe to. And it should be available as early as possible during boot, so I think its place is in init(8).

Re: sparc64 ci_cpuid

2017-12-01 Thread Miod Vallat
> sparc64 uses a different name of storing the CPU number. I'd like to > use `ci_cpuid' to be able to use it in MI code without adding another > abstraction layer. Isn't that what CPU_INFO_UNIT() is for?

Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam

2017-10-29 Thread Miod Vallat
> The patch below simply stops printing additional messages after 10 > lines have been printed. > You might want to use ratecheck(9) rather than a simple limit.

Re: pow() returns a negative result on loongson

2017-10-10 Thread Miod Vallat
> My first thought would on Loongson would be softfloat bug. > But I am not 100% sure it (still) uses softfloat. Loongson has never used softfloat. But all mips ports embed the softfloat code in order to perform tricky computations the FPU won't perform (mostly edge cases involving denormals and

Ethernet media autoselect for DEC 3000

2017-09-22 Thread Miod Vallat
The on-board Ethernet interface on DEC 3000 systems (except for models 300) has both a 10base5 and a 10baseT connector, which is software selected. The following diff, based upon sparc le@ledma attachment, lets the user force a specific media regardless of the PROM settings, and will also, when

fix blinkenlichten on TURBOchannel alpha

2017-09-12 Thread Miod Vallat
Blinkenlichten used to be disabled by default, and became enabled by default some releases ago. However, the tc alpha blinkenlichten code was expecting to be triggered by a sysctl machdep.led_blink change, and would not start by default. The following diff fixes this, and restores the balance of

Re: Looking for testers with a floppy drive

2017-08-26 Thread Miod Vallat
> Hi, > > is anyone still using floppies? If yes, it would be nice if they could > give the diff below a test. It defers probing of the drives which reduces > boot time quite a bit. If floppy does not work with the diff, please also > test if it works without it. On qemu, floppy access seems

Re: wsfont: remove iso7/pcvt encoding macros and entries

2017-06-13 Thread Miod Vallat
> Hi tech@, > > We do not support iso7 nor pcvt encoding, so remove macro definitions > and commented entries. If you do that, then you can probably optimize away vga_valid_primary_font() in sys/dev/ic/vga.c as well.

Re: monop(6): drop the conditional shrt macro definitions

2017-06-10 Thread Miod Vallat
> Hi tech@, > > Drop the conditional shrt macro definitions and use short everywhere. Why not use uint8_t then?

g/c ASPICFLAG

2017-06-06 Thread Miod Vallat
This used to be necessary in the gcc 2.95 days. Nowadays nothing in base or X uses it. Index: share/mk/bsd.own.mk === RCS file: /OpenBSD/src/share/mk/bsd.own.mk,v retrieving revision 1.184 diff -u -p -r1.184 bsd.own.mk ---

Re: Makefile.cross tweaks

2017-06-06 Thread Miod Vallat
>> The following diff attempts to cross-build more things, in particular >> gnu/lib (except for libiberty). It also passes the proper optimization >> flags so that libstdc++-v3 gets built with optimization. > > Doesn't build for arm64, probably because BUILD_GCC4 is transparently > set by the

Makefile.cross tweaks

2017-05-29 Thread Miod Vallat
The following diff attempts to cross-build more things, in particular gnu/lib (except for libiberty). It also passes the proper optimization flags so that libstdc++-v3 gets built with optimization. Index: Makefile.cross === RCS file:

Re: Use copyin32(9) to implement futex(2)

2017-05-28 Thread Miod Vallat
> This makes MULTIPROCESSOR kernels use copyin32(9) to guarantee > atomicity. This will break m88k GENERIC.MP; shouldn't be too > difficult to fix for someone whu understands m88k assembly. Index: subr.S === RCS file:

Re: Atomic copyin(9)/copyout(9) for amd64

2017-05-15 Thread Miod Vallat
> So I implemented a new function called > copyin_futex(9), which is all we really need. But it is not specific to futex - in fact, it could be used in syscall() as well. Better call it fuword() or aligned_fuword() since it has the extra alignment requirement that

Re: Include packet timestamp into the mbuf packet header

2017-05-02 Thread Miod Vallat
> diff --git sys/sys/mbuf.h sys/sys/mbuf.h > index 202ce8ced8b..7ca1a779fe0 100644 > --- sys/sys/mbuf.h > +++ sys/sys/mbuf.h > @@ -127,10 +127,11 @@ struct pkthdr { > u_int16_tph_flowid; /* pseudo unique flow id */ > u_int16_tcsum_flags;/*

Re: sync root.mail

2017-03-30 Thread Miod Vallat
>> > Ambiguous: choose package for emacs--no_x11 >> > a 0: >> > 1: emacs-21.4p37-no_x11 >> > 2: emacs-25.1p3-no_x11 >> > Your choice: >> >> Time to choose another package? > > I think in this case choice is good. Indeed, but why aren't vim-no_x11 packages listed as

Re: Linking userland with lld

2017-01-21 Thread Miod Vallat
> The plan is to use lld (the llvm linker) on arm64 to avoid GLPv3 > binutils. Mostly works, but it triggers an issue in building ldapd > and ldapctl. > > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our >

libcrypto: get rid of I386_ONLY

2016-11-04 Thread Miod Vallat
I386_ONLY was used to prefer a different assembler sequence in the sha512 code, which would be faster on 80386 processors, but slower on 80486 and above. This code path has never been enabled, and there are actually no plans to make libcrypto friendlier to genuine 80386 chips, so why bother

obsolete bits in libcrypto Makefile

2016-11-04 Thread Miod Vallat
libcrypto no longer needs to use internal headers from libssl; and no longer checks for TERMIOS being defined. Index: Makefile === RCS file: /cvs/src/lib/libcrypto/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile ---

Smarter OpenBSD/sgi boot blocks

2016-10-04 Thread Miod Vallat
The sgi boot blocks use the PROM (ARCBios or ARCS) for its I/O routines. When using a disk-based path, these routines are using the partition table found in the ``volume header''. In order to be able to use 16 partitions per disk, the OpenBSD port only claims one volume header partition, #0, as

Re: squeeze some isa drivers

2016-08-31 Thread Miod Vallat
> Time to play whack i386/conf/GENERIC with a bat and see what pops out. > > Extensive research in the archives indicates that these devices are extinct. You'll need to remove out the commented wss line in alpha GENERIC as well.

com(4) mcr games

2016-08-18 Thread Miod Vallat
While everyone is looking at com(4)... Some systems use reserved (and sometimes not) bits of the MCR register for extra features. In particular, on some systems, clearing the DCS bit in the MCR is not a good idea (kudos if you can guess what historical machine I am thinking of). It makes sense

Re: RELRO on mips64

2016-08-10 Thread Miod Vallat
> Also, since mips64 doesn't have a real hardware NX bit, splitting the > .text and .rodata segments doesn't actually get us anything from a > protection standpoint. So, unset PAD_NO to smoosh them back together. The Loongson processors are supposed to have an NX bit, but it's only mentioned

Re: libcrypto: explicitly initialize constant

2016-07-12 Thread Miod Vallat
>> Noted by VS2013, const values should be initialized (though I think >> the 'static' should also implicitly zero). > > this sounds like the compiler doesn't know C? He is talking about Visual Studio. The C part of that piece of shit pretending to be a compiler only supports a subset of C89.

Re: cbfb: coreboot framebuffer console

2016-06-16 Thread Miod Vallat
> Here is a third version that just integrates the coreboot code into > efifb. The cnattach path still has to be different to allow vga to > try to attach before doing the coreboot version. > > > Index: arch/amd64/amd64/efifb.c > @@ -55,6 +102,8 @@ int efifb_show_screen(void *, void *,

Re: cbfb: coreboot framebuffer console

2016-06-15 Thread Miod Vallat
> On Wed, 15 Jun 2016 19:01:23 +0200, Mark Kettenis wrote: > >> I don't really consider it to be terribly important to rename the >> efifb(4). The chromebooks are weird machines, and I don't expect the >> coreboot-based framebuffer to show up on many systems. > > Agreed, just keep it as

Re: cbfb: coreboot framebuffer console

2016-06-11 Thread Miod Vallat
> Index: arch/amd64/amd64/cbfb.c > +struct cfattach cbfb_ca = { > + sizeof(struct cbfb_softc), cbfb_match, cbfb_attach, NULL > +}; Make it const. > +void > +cbfb_rasops_preinit(struct cbfb *cbfb) > +{ > +#define bmnum(_x) (fls(_x) - ffs(_x) + 1) > +#define bmpos(_x) (ffs(_x) - 1) These

Re: smu(4) PWM Fan Support

2016-05-12 Thread Miod Vallat
> > fcu(4) could benefit from a similar change, as there may be pwm fans > > there too. At least RackMac3,1 has two pwm fans according to the eeprom > > -p output. > > Hmm, looking at the fcu(4) code it already should support pwm fans, no? Doh! I was looking for `fan' in the sensors output and

Re: smu(4) PWM Fan Support

2016-05-11 Thread Miod Vallat
> I've recently noticed that two of five fans in my G5 don't spin up. > That's because smu(4) currently just supports RPM fans. > The attached diff adds initial support for PWM fans as well. fcu(4) could benefit from a similar change, as there may be pwm fans there too. At least RackMac3,1 has

Re: SROP mitigation

2016-05-09 Thread Miod Vallat
> This is just a draft. > > Index: arch/hppa/hppa/machdep.c > @@ -1329,11 +1330,31 @@ sys_sigreturn(struct proc *p, void *v, r > struct trapframe *tf = p->p_md.md_regs; > int error; > > + if (PROC_PC(p) != (u_int64_t)p->p_p->ps_sigcode + Why uint64_t here? This is a 32-bit

  1   2   3   4   >