Re: sed: better error message

Jérémie Courrèges-Anglas wrote: > Tobias Stoeckmann writes: > > > $ sed s/a/b/ /nofile > > sed: 0: /nofile: /nofile > > > > That message doesn't tell me a lot, let's better write > > strerror(errno) if fopen returns NULL: > > > > $ ./sed s/a/b/ /nofile > > sed: 0: /nofile:

Re: sed: better error message

Jérémie Courrèges-Anglas wrote: > Michael McConville <mm...@mykolab.com> writes: > > It looks like it can be pretty easily replaced with calls to err(3), > > errx(3), warn(3), warnx(3), etc. > > Not sure about this, you'd have to repeat the same code over and over

Re: locate(1): small cleanup

Michael Reed wrote: > - mmap support was recently made the default, but the includes were > left unsorted; this diff deals with that > > - remove optarg & optind declarations as unistd.h already does this > > - remove `#ifdef sun' block: htohl() isn't used anywhere here, although > ntohl()

Re: unused macros in ksh

Beat me to it. ok mmcc@ Ilya Kaliman wrote: > === > RCS file: /cvs/src/bin/ksh/shf.c,v > retrieving revision 1.25 > diff -u -p -r1.25 shf.c > --- shf.c 19 Oct 2015 14:42:16 - 1.25 > +++ shf.c 23 Oct 2015 00:27:40

Cast isspace() arg to unsigned char

ok? Index: fio.c === RCS file: /cvs/src/usr.bin/mail/fio.c,v retrieving revision 1.35 diff -u -p -r1.35 fio.c --- fio.c 16 Oct 2015 17:56:07 - 1.35 +++ fio.c 16 Oct 2015 17:56:42 - @@ -142,7 +142,7 @@

Re: Char cleanup in lex(1)

Theo de Raadt wrote: > > When scanning for is*() function uses with signed chars, I found that > > lex(1) uses an unecessary #define for unsigned char. The below diff > > removes it and fixes an undefined is*() usage or two as well. > > Our tree uses lex pretty much as-is from upstream, so this

Re: Char cleanup in lex(1)

Michael McConville wrote: > Theo de Raadt wrote: > > > When scanning for is*() function uses with signed chars, I found that > > > lex(1) uses an unecessary #define for unsigned char. The below diff > > > removes it and fixes an undefined is*() usage or two as we

Char cleanup in lex(1)

When scanning for is*() function uses with signed chars, I found that lex(1) uses an unecessary #define for unsigned char. The below diff removes it and fixes an undefined is*() usage or two as well. Index: ecs.c === RCS file:

Re: ftp: ctype interfaces need unsigned chars

Theo de Raadt wrote: > > Some isfoo(char) usages crept back into ftp > > Hmm. I wonder how we can keep these errors out of base. > Having to re-audit all the time is painful. FWIW, this is a perfect use case for Coccinelle. Below is what I dredged up in src/usr.sbin (diff not yet carefully

Re: Removing GCC 2 support from cdefs.h

Philip Guenther wrote: > On Thu, Oct 1, 2015 at 10:52 PM, Jonathan Gray wrote: > > This isn't just removing support for gcc 2 it is removing support > > for anything that doesn't define __GNUC__ and implement all the gnu > > attributes which isn't what we want. > > Yep. We've

Removing GCC 2 support from cdefs.h

Index: sys/cdefs.h === RCS file: /cvs/src/sys/sys/cdefs.h,v retrieving revision 1.39 diff -u -p -r1.39 cdefs.h --- sys/cdefs.h 18 Apr 2014 11:51:17 - 1.39 +++ sys/cdefs.h 1 Oct 2015 23:31:42 - @@ -88,30 +88,17 @@ #endif

explicit_bzero() for isakmpd(8)

Index: sbin/isakmpd/hash.c === RCS file: /cvs/src/sbin/isakmpd/hash.c,v retrieving revision 1.23 diff -u -p -r1.23 hash.c --- sbin/isakmpd/hash.c 21 Mar 2013 04:30:14 - 1.23 +++ sbin/isakmpd/hash.c 1 Oct 2015 00:10:23 -

More explicit_bzero() for ssh

Index: usr.bin/ssh/sshbuf-misc.c === RCS file: /cvs/src/usr.bin/ssh/sshbuf-misc.c,v retrieving revision 1.4 diff -u -p -r1.4 sshbuf-misc.c --- usr.bin/ssh/sshbuf-misc.c 24 Mar 2015 20:03:44 - 1.4 +++

Dubious loop logic in pciide(4)

Yesterday, I ran a Coccinelle script to find useless continue statements and sent a few to tedu@. He pointed out that, based on the loop above it, the one below probably meant to continue the outer loop. Here's the least invasive fix, assuming we're correct. Thoughts? I don't know if this is the

Re: remove unused(?) #includes from snmpd

Stefan Sperling wrote: > On Sat, Sep 26, 2015 at 03:29:07PM -0400, Michael McConville wrote: > > I see some preproc conditions in usr.sbin/snmpctl/snmpclient.c. I > > only bothered to check the first two. Are you sure they still > > compile in all circumstances? If I

Re: remove unused(?) #includes from snmpd

Stefan Sperling wrote: > I was looking for ifmedia bits to fix in here, but found nothing > except a few unused if_media.h includes. > > Turns out snmpd compiles (on i386) without warnings with a lot > less headers included. > > Is this a safe change? > > I've left sys/types.h alone since I

Clarify relevance of PF FAQ

Assuming that what's described applies to the most recent releases. You could also argue that this disclaimer is old enough to be deleted. Index: faq/pf/nat.html === RCS file: /cvs/www/faq/pf/nat.html,v retrieving revision 1.54 diff

Re: Enforce explicit bzeroing in sasyncd(8)

Ping. Michael McConville wrote: > I took the approach of trying to enforce the programmer's intentions. If > anyone thinks some or all of the cases don't make sense, let me know. > > > Index: monitor.c > === &g

Re: Clarify error/warning reporting in style(9)

Jason McIntyre wrote: > On Mon, Sep 21, 2015 at 10:40:29PM -0400, Michael McConville wrote: > > Could also say "Use the err(3) and warn(3) family of functions." That's > > what the err(3) man page intro refers to it as. > > > > please some developer commi

Plug a mem-leak in dhcpd(8)

Am I interpreting this correctly? This is the least invasive fix, but it's unfortunate that this function allows the supplied buffer to be NULL. If we made it unconditionally allocate a new buffer, we would have to change some program logic because uses pass stack-allocated statically-sized

Clarify error/warning reporting in style(9)

Could also say "Use the err(3) and warn(3) family of functions." That's what the err(3) man page intro refers to it as. Index: share/man/man9/style.9 === RCS file: /cvs/src/share/man/man9/style.9,v retrieving revision 1.59 diff -u -p

Re: Drop a distracting function from locate(1)

Otto Moerbeek wrote: > I do not agree. You only have to remeber "that function does sensible > error checking" and you do not have to remember at each spot which > condition is the right one. > > Function are the major way of structuring code, use them. It's not the idea of functions that I'm

Re: Remove errx() clone from fsck_*

Bob Beck wrote: > seeing "8" everywhere here makes me think I'm in OpenSSL code. > > please make that some sort of sensible define. > > And post this with the removal of the function, so do it > everywhere. I can't tell from the diff that it's sane. Below is a complete removal of errexit(),

Remove errx() clone from fsck_*

The best I can tell, fsck's errexit() is just a clone of errx() (less the "progname: " prefix and the appended newline). If we delete it from fsck_ffs, fsck_ext2fs, and fsck_msdos, we can remove its definition in fsck. This diff is just for fsck_ffs. (fsck_msdos has only one use.) Another

Re: Remove errx() clone from fsck_*

Bob Beck wrote: > Alas, you are changing the behaviour in many places now. > > for example you are calling exit(8) where previously the errexit code > would print a newline then exit (making the previous interactive > response not look stupid). Good point. Oversight on my part. > You are

iked(8) cleanup

Drop some unnecessary NULL checks, explicitly bzero sensitive memory. Index: config.c === RCS file: /cvs/src/sbin/iked/config.c,v retrieving revision 1.37 diff -u -p -r1.37 config.c --- config.c21 Aug 2015 11:59:27 -

Drop a distracting function from locate(1)

Index: locate/fastfind.c === RCS file: /cvs/src/usr.bin/locate/locate/fastfind.c,v retrieving revision 1.12 diff -u -p -r1.12 fastfind.c --- locate/fastfind.c 16 Jan 2015 06:40:09 - 1.12 +++ locate/fastfind.c 19 Sep 2015

Remove distracting func from make(1), use errx()

Index: buf.c === RCS file: /cvs/src/usr.bin/make/buf.c,v retrieving revision 1.27 diff -u -p -r1.27 buf.c --- buf.c 29 Apr 2015 00:42:12 - 1.27 +++ buf.c 19 Sep 2015 18:35:22 - @@ -66,6 +66,7 @@ *

Re: Drop a distracting function from locate(1)

> What's your thinking behind this? To me this seems like a perfectly > rational and well motivated function to have, both for readability and > rather than having to repeat the same statements several times over in > the rest of the code, risking future calamity if a change is made in > one place

Re: Remove errx() clone from fsck_*

Bob Beck wrote: > Michael McConville wrote: > > Bob Beck wrote: > > > seeing "8" everywhere here makes me think I'm in OpenSSL code. > > > > > > please make that some sort of sensible define. > > > > > > And post this with the

Re: Use M_ZERO in malloc(9)

Michael McConville wrote: > Michael McConville wrote: > > Martin Pieuchot wrote: > > > On 18/09/15(Fri) 11:47, Michael McConville wrote: > > > > Index: arch/arm/xscale/pxa27x_udc.c > > > > =

Re: Use M_ZERO in malloc(9)

Martin Pieuchot wrote: > On 18/09/15(Fri) 11:47, Michael McConville wrote: > > Index: arch/arm/xscale/pxa27x_udc.c > > === > > RCS file: /cvs/src/sys/arch/arm/xscale/pxa27x_udc.c,v > > retrieving revision

Use M_ZERO in malloc(9)

Index: arch/arm/xscale/pxa27x_udc.c === RCS file: /cvs/src/sys/arch/arm/xscale/pxa27x_udc.c,v retrieving revision 1.31 diff -u -p -r1.31 pxa27x_udc.c --- arch/arm/xscale/pxa27x_udc.c15 May 2015 13:32:08 - 1.31 +++

ypserv(8) cleanup

Index: common/yplib_host.c === RCS file: /cvs/src/usr.sbin/ypserv/common/yplib_host.c,v retrieving revision 1.19 diff -u -p -r1.19 yplib_host.c --- common/yplib_host.c 11 Sep 2015 12:42:47 - 1.19 +++ common/yplib_host.c 18

Re: Fix error reporting in ksh's csh-history

Michael McConville wrote: > ksh offers csh-style history aliases when you set csh-history. This > feature currently works. However, when an alias doesn't exist ksh > reports only the last digit (thanks to Theo for tipping me off on this): > > > mike:/tmp/tech:1$ set -o csh-his

Merge a stub file in ps(1)

fmt.c contains two functions that are only called by command() in print.c. One of them is tiny, too. It seems simpler to have them in print.c as statics. Index: Makefile === RCS file: /cvs/src/bin/ps/Makefile,v retrieving revision

Re: Merge a stub file in ps(1)

Michael McConville wrote: > fmt.c contains two functions that are only called by command() in > print.c. One of them is tiny, too. It seems simpler to have them in > print.c as statics. I forgot to mention that I also changed their argument leftp's type from int to size_t, because th

Re: [patch] if-free cleanup in sys/arch

Miod Vallat wrote: > > Hi, > > > > Here a first sets of "if(x) free(x)" cleanup in sys/arch/ > > > > This patch contains only trivial if(x) removal. The size argument in > > free is keep untouched (because it is already setted, or because it > > makes sens to keep it to 0). > > > > Comments ?

Re: Remove NULL checks before free()

Ted Unangst wrote: > Michael McConville wrote: > > There will probably be more similar patches to come if this is > > acceptable. The legwork was done with the following Coccinelle script: > > I think it should be split up, but I'm happy to see diffs like this. Is this sm

Re: Remove useless NULL casts from mv(1)

m all, for no real advantage. But I don't feel > strongly about it, others may disagree. No strong feelings here either, and apparently style(9) suggests the cast. It was just something I came across while reading. > On Mon, Sep 14, 2015 at 09:39:48AM -0400, Michael McConvill

Remove useless NULL casts from mv(1)

Index: mv.c === RCS file: /cvs/src/bin/mv/mv.c,v retrieving revision 1.40 diff -u -p -r1.40 mv.c --- mv.c24 Aug 2015 00:10:59 - 1.40 +++ mv.c14 Sep 2015 13:38:13 - @@ -348,7 +348,7 @@ copy(char *from, char

Condense fluffy comments in pax

Index: options.c === RCS file: /cvs/src/bin/pax/options.c,v retrieving revision 1.91 diff -u -p -r1.91 options.c --- options.c 18 May 2015 20:26:16 - 1.91 +++ options.c 11 Sep 2015 00:12:19 - @@ -668,9 +668,7 @@

Fix error reporting in ksh's csh-history

ksh offers csh-style history aliases when you set csh-history. This feature currently works. However, when an alias doesn't exist ksh reports only the last digit (thanks to Theo for tipping me off on this): > mike:/tmp/tech:1$ set -o csh-history > mike:/tmp/tech:2$ ls > a b c >

Remove unused vars from if_urtwn.c

Index: if_urtwn.c === RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v retrieving revision 1.51 diff -u -p -r1.51 if_urtwn.c --- if_urtwn.c 10 Sep 2015 11:53:05 - 1.51 +++ if_urtwn.c 13 Sep 2015 21:30:32 - @@ -2713,7 +2713,7

Re: Floating point #define in ksh

Todd C. Miller wrote: > On Michael McConville wrote: > > To be (far) more specific, it's used to enable the 'e', 'g', and 'f' > > fields of ksh's vfprintf() clone. On one hand, this can't be too > > important if it was disabled for >10 years. On the other, the co

More minor ksh stuff

* move tty_close() up so that we can call it in tty_init() * bump tfd's assignment into its own line * realize that those if conditions are identical Index: tty.c === RCS file: /cvs/src/bin/ksh/tty.c,v retrieving revision 1.10

Re: Floating point #define in ksh

Nicholas Marriott wrote: > I would kill it. FPBUF_SIZE and DMAXEXP can go too. Here's the diff: Index: ksh_limval.h === RCS file: /cvs/src/bin/ksh/ksh_limval.h,v retrieving revision 1.2 diff -u -p -r1.2 ksh_limval.h ---

Re: Floating point #define in ksh

Nicholas Marriott wrote: > Works for me. ok anyone? > > I think ksh_limval.h can go entirely after this, per the note in > PROJECTS. If we're in the business of deleting files, bin/ksh/INSTALL describes itself with the following: > [This file is the generic GNU autoconf/configure installation >

Re: Floating point #define in ksh

Nicholas Marriott wrote: > Works for me. ok anyone? > > I think ksh_limval.h can go entirely after this, per the note in > PROJECTS. I also just found this gem. It only has one use, so it can probably be replaced. Am I interpreting it correctly? Index: shf.c

Re: More minor ksh stuff

Nicholas Marriott wrote: > Why do you need to move tty_close? It is prototyped in tty.h which is > included at the start of your diff. > > The other changes look good. You're right. Here's a new diff: Index: tty.c === RCS file:

explicit_bzero() for sasyncd(8)

I took the approach of trying to enforce the programmer's intentions. If anyone thinks some or all of the cases don't make sense, let me know. Index: monitor.c === RCS file: /cvs/src/usr.sbin/sasyncd/monitor.c,v retrieving revision

Floating point #define in ksh

FP has been undefined for at least ten years, and probably forever. It's used to conditionally add two small sections and one large section of shf.c. My initial reaction is that FP should be removed. Is there any reason to keep it? Should the associated code stay or go?

Re: Floating point #define in ksh

Michael McConville wrote: > FP has been undefined for at least ten years, and probably forever. > It's used to conditionally add two small sections and one large > section of shf.c. > > My initial reaction is that FP should be removed. Is there any reason > to keep it? Should t

Dropping needless globals (ksh)

Does this look good? I'm not sure why these globals existed. It looks like it's going to take a little more than search-and-replace to remove null. Index: c_ksh.c === RCS file: /cvs/src/bin/ksh/c_ksh.c,v retrieving revision 1.36

Re: ksh INT32 type

Martijn van Duren wrote: > I already sent this diff on September 1st.[1] Pointed out in private > to and ok by nicm@ > > [1]http://marc.info/?l=openbsd-tech=144112883814618=2 Ah, awkward. I hadn't seen this. Can you clarify why you used int instead of int32_t?

Re: A couple fsck_ext2fs fixes

ping Michael McConville wrote: > The first is a pretty trivial change for clarity and correctness. > > The second probably isn't the best way to solve the problem long-term, > but prevents a div-by-zero two lines later. I may have been affected by > it when fscking a /dev/z

memset() -> explicit_bzero() in login_yubikey(8)

Does this look right? Index: login_yubikey.c === RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v retrieving revision 1.10 diff -u -p -r1.10 login_yubikey.c --- login_yubikey.c 16 Jan 2015 06:39:50 - 1.10 +++

Re: Dropping needless globals (ksh)

Alexey Suslikov wrote: > Michael McConville sccs.swarthmore.edu> writes: > > > RCS file: /cvs/src/bin/ksh/c_ksh.c,v > > > > > - shprintf(newline); > > + shprintf("\n"); > > In terms of portability, are y

Re: bzero() -> explicit_bzero() in bgpd(8)

Philip Guenther wrote: > Loganaden Velvindron wrote: > > Michael McConville wrote: > >> These seem like they were definitely meant to be explicit zeroings. > > > > I'm not entirely sure about this. Since the variable (data) is used > > before return, it would n

bzero() -> explicit_bzero() in bgpd(8)

These seem like they were definitely meant to be explicit zeroings. Index: pfkey.c === RCS file: /cvs/src/usr.sbin/bgpd/pfkey.c,v retrieving revision 1.44 diff -u -p -r1.44 pfkey.c --- pfkey.c 10 Feb 2015 05:18:39 -

Re: Dropping needless globals (ksh)

Todd C. Miller wrote: > On Thu, 10 Sep 2015 23:26:53 +0100, Nicholas Marriott wrote: > > looks good to me, any other ok? > > > > null is serious poo and really needs to go as well > > Beware! Some of these values are used in pointer comparisons so > I'm not sure it is same to remove them. > >

Plug memory leak in ntpd(8)

Found with the Clang static analyzer. Index: constraint.c === RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v retrieving revision 1.14 diff -u -p -r1.14 constraint.c --- constraint.c18 Jul 2015 21:50:47 - 1.14 +++

Remove NULL checks before free()

There will probably be more similar patches to come if this is acceptable. The legwork was done with the following Coccinelle script: @@ expression E; @@ - if(E) { - free(E); - } + free(E); Index: bin/systrace/filter.c ===

ksh INT32 type

I may be totally off base here, but: INT32's comment suggests that the configure script checks that int is >= 32 bits. However, i don't think that script's around anymore, and ANSI specifies a minimum of only 16 bits. The comment also says that INT32 can be 64 bits, but it's then used as Tflag,

Re: ping6(8) bug

Claudio Jeker wrote: > On Mon, Sep 07, 2015 at 03:49:14PM -0400, Michael McConville wrote: > > It seems pretty clear to me that what was here was wrong. A field of > > a global struct was pointed at local array. The program logic was a > > little wacky, but this is my

Re: ping6(8) bug

We'd have to determine where and when this memory gets freed, of course. Michael McConville wrote: > It seems pretty clear to me that what was here was wrong. A field of a > global struct was pointed at local array. The program logic was a > little wacky, but this is my best estimat

ping6(8) bug

It seems pretty clear to me that what was here was wrong. A field of a global struct was pointed at local array. The program logic was a little wacky, but this is my best estimate of what was intended. Input? Index: ping6.c === RCS

Plug a memory leak in dhclient(8)

This seems to be the result of the programmer misunderstanding strsep() (unless I'm misunderstanding something). The return value is the supplied string pointer. Because strsep() is called in a while loop, each iteration's hn is the last iteration's inputstring. We therefore have to keep a

A couple fsck_ext2fs fixes

The first is a pretty trivial change for clarity and correctness. The second probably isn't the best way to solve the problem long-term, but prevents a div-by-zero two lines later. I may have been affected by it when fscking a /dev/zero'd partition. Found with the Clang static analyzer (and the

Remove unused initial value

Found with the Clang static analyzer. Index: c_ksh.c === RCS file: /cvs/src/bin/ksh/c_ksh.c,v retrieving revision 1.35 diff -u -p -r1.35 c_ksh.c --- c_ksh.c 1 Sep 2015 13:12:31 - 1.35 +++ c_ksh.c 7 Sep 2015

Like free(), ksh's afree() is NULL-safe

Also, why is fs on line 390 cast to char* when afree() takes void*? Index: emacs.c === RCS file: /cvs/src/bin/ksh/emacs.c,v retrieving revision 1.50 diff -u -p -r1.50 emacs.c --- emacs.c 25 Mar 2015 12:10:52 - 1.50 +++

Re: Like free(), ksh's afree() is NULL-safe

Ted Unangst wrote: > Michael McConville wrote: > > Also, why is fs on line 390 cast to char* when afree() takes void*? > > this code is older than void. and NULL apparently. please remove the casts > too. Does this look good? I had to leave one cast because the freed pointer i

It's '(U)pgrade' these days, no?

ndex: faq/ports/guide.html === RCS file: /cvs/www/faq/ports/guide.html,v retrieving revision 1.37 diff -u -p -r1.37 guide.html --- faq/ports/guide.html2 Jul 2015 05:49:05 - 1.37 +++ faq/ports/guide.html15 Aug

A typo and a suggested rewording

I have too much time on my hands. Index: sigabrt.c === RCS file: /cvs/src/regress/sys/kern/tame/sigabrt/sigabrt.c,v retrieving revision 1.1 diff -u -p -r1.1 sigabrt.c --- sigabrt.c 27 Jul 2015 18:03:36 - 1.1 +++ sigabrt.c

Warning on assembly of RdRand instructions

This was just an experiment, but it might be worth sharing. Using RdRand in userland software is risky, and not just for tinfoil-hattish reasons: https://www.hyperelliptic.org/tanja/vortraege/random.pdf Intel suggests that people call it directly. As chips with RdRand become more

Re: softdep by default on AMD64

Артур Истомин wrote: Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto) I've been getting I/O errors and other strange problems with softraid crypto, both with and without

Re: softdep by default on AMD64

Артур Истомин wrote: On Tue, Jul 28, 2015 at 06:19:11AM -0700, Chris Cappuccio wrote: ?? ?? [art.is...@yandex.ru] wrote: On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: generally reliable HAHAHAHAHA Why irony? It's more or less true for ALL

Re: softdep by default on AMD64

Theo de Raadt wrote: I understand that you guys are having fun with this. If you think this is actually an issue, though, it's probably a good idea to suggest an FAQ change. Generally reliable is a pretty lukewarm review compared to the current FAQ, which doesn't mention any downsides:

Interactive F option in fsck man pages

It's documented in fsck(8), but not fsck_*(8). This can confuse people. I just copied its paragraph from fsck(8). Index: sbin/fsck_ext2fs/fsck_ext2fs.8 === RCS file: /cvs/src/sbin/fsck_ext2fs/fsck_ext2fs.8,v retrieving revision

Re: [patch] Remove archaic manual sizing from dump(8)

On Fri, Jul 24, 2015 at 10:17:12PM +, Christian Weisgerber wrote: On 2015-07-23, Michael McConville mmcco...@sccs.swarthmore.edu wrote: --- sbin/dump/main.c23 May 2015 05:17:20 - 1.56 +++ sbin/dump/main.c15 Jun 2015 23:16:10 - @@ -115,7 +115,7 @@ main(int

[patch] Remove archaic manual sizing from dump(8)

ping https://marc.info/?l=openbsd-techm=143432732005608w=2 https://marc.info/?l=openbsd-techm=143441062327954w=2 Index: sbin/dump/dump.8 === RCS file: /cvs/src/sbin/dump/dump.8,v retrieving revision 1.49 diff -u

softdep by default on AMD64

There was a great discussion about softdep recently: https://marc.info/?t=14216401691r=1w=2 It needs extra memory, so the FAQ warns against its use on really old architectures. tedu@ described the two main deterrents: https://marc.info/?l=openbsd-miscm=142294185000751w=2

Re: softdep by default on AMD64

On Thu, Jul 23, 2015 at 06:49:55PM -0600, Theo de Raadt wrote: There was a great discussion about softdep recently: https://marc.info/?t=14216401691r=1w=2 It needs extra memory, so the FAQ warns against its use on really old architectures. tedu@ described the two main

Re: [patch] Disklabel message tweak

On Fri, Jul 17, 2015 at 03:53:09PM +0200, Benny Lofgren wrote: On 2015-07-17 08:57, Theo de Raadt wrote: The phrase No label changes. was selected because it is true (there is nothing to save). I don't see what further adds to make this more accurate or understandable. Perhaps phrasing

[patch] Disklabel message tweak

This is another trivial patch, but I've always found the disklabel message No label changes confusing. For example, if you print (p), add a label (a), write (w), print to check your changes (p), and then quit (q), it seems odd to be told No label changes. Index: sbin/disklabel/editor.c

Re: Thinkpad active cooling

On Wed, Jul 15, 2015 at 11:28:49PM -0500, Adam Thompson wrote: Although I agree the fan speed handling under OpenBSD still has room for improvement... I haven't run OpenBSD on it for any significant amount of time since the ~recent changes to improve Thinkpad power usage. The C-state changes

[patch] (www) Outdated and unnecessary version numbers

Also, 'or' - 'and'. Index: faq/faq15.html === RCS file: /cvs/www/faq/faq15.html,v retrieving revision 1.110 diff -u -p -r1.110 faq15.html --- faq/faq15.html 13 Jul 2015 06:08:56 - 1.110 +++ faq/faq15.html 14 Jul

Re: Thinkpad active cooling

On Wed, Jul 15, 2015 at 03:04:07AM +0200, Tobias Ulmer wrote: Theo is asking for affected models, so lets compile a list. All my Thinkpads can be provoked into shutdown due to overtemp because the fan doesn't spin up: T60 T61 X201 I've had it happen on my X201, but only once in the ~6

[patch] Defunct companies in products.html

ping On Fri, Jul 10, 2015 at 12:11:43AM -0400, Michael McConville wrote: On Thu, Jul 09, 2015 at 11:51:23PM -0400, Michael McConville wrote: Core Systems' website has been down for a while, and it seems that they no may longer exist. Can anyone confirm or deny? Also, MIPS-Informatics

[patch] Path typo in FAQ

Index: faq/faq15.html === RCS file: /cvs/www/faq/faq15.html,v retrieving revision 1.109 diff -u -p -r1.109 faq15.html --- faq/faq15.html 2 Jul 2015 05:49:04 - 1.109 +++ faq/faq15.html 13 Jul 2015 04:56:40 - @@

Removing chflags/di_flags

This was buried in a support thread on misc@, so I thought I'd send it here. I'm interested to hear what other devs think. https://marc.info/?l=openbsd-miscm=143650092505421w=2 https://marc.info/?l=openbsd-miscm=143650301005709w=2

Core Systems in products.html

Core Systems' website has been down for a while, and it seems that they no may longer exist. Can anyone confirm or deny? Index: products.html === RCS file: /cvs/www/products.html,v retrieving revision 1.97 diff -u -p -r1.97

Re: Core Systems in products.html

On Thu, Jul 09, 2015 at 11:51:23PM -0400, Michael McConville wrote: Core Systems' website has been down for a while, and it seems that they no may longer exist. Can anyone confirm or deny? Also, MIPS-Informatics seems to be serving World Cup updates these days. Index: products.html

Re: [Patch] New item to the Migrating to OpenBSD guide

On Sun, Jun 28, 2015 at 07:20:51PM +0200, Carlos Fenollosa wrote: This patch is regarding the fact that there are no binary updates, which is a given thing in most Linux distributions, and some tips on how to keep the system updated. It may be worthwhile to mention that updates are

Re: patch: dump(8)'s Default Volume Behavior

On Tue, Jun 16, 2015 at 04:54:41PM -0400, Kenneth Gober wrote: On Mon, Jun 15, 2015 at 7:20 PM, Michael McConville mmcconvi...@mykolab.com wrote: Of course, this breaks existing scripts that used the -a option - they'll just get the usage prompt. It will fail more dangerously (silently

patch: dump(8)'s Default Volume Behavior

On Sun, Jun 14, 2015 at 06:14:09PM -0600, Theo de Raadt wrote: If so, let me know and I can write a patch. Please do, then it is easier for archaic people to play with it. This is my first patch, so I may have made some mistakes. I tried to correct and expand the man page while leaving its

<    1   2   3