Perl 5.22.1 testing request + issue on alpha
Again it's time to look at updating perl. I am looking for more test results on different platforms. I have alpha, amd64, armv7, i386, sparc64, and macppc tests already. Looking for help with any others, especially vax and sparc. I have built a release with the new perl and dpb built pretty much all the packages I need for my laptop and pkg_add/delete seem to be working well. As usual, download the latest version of the update script: https://github.com/afresh1/OpenBSD-perl/archive/master.tar.gz Extract it, and download perl 5.22.1 into the extracted directory: https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.22.1.tar.gz cd to someplace you have room run /path/to/OpenBSD-perl/build_perl wait send me the log file(s) it generates Logs I have already are available on Github. https://github.com/afresh1/OpenBSD-perl I have run into a strange issue on alpha that I'm still tracking down. I fear this has interrupted me too long to get 5.22 in for OpenBSD 5.9, but maybe we can get ahead of the curve and be ready after unlock. Previously, NaN + 1 looked like this: $ perl -we 'print "NaN" + 1' -nan Due to improvements in the Inf/NaN code, 5.22 should get: $ perl -we 'print "NaN" + 1' NaN But for some reason on alpha NaN isn't special and we instead get: $ ./perl -we 'print "NaN" + 1' 1 As far as I can tell, when reading it in the flags get set properly, so I'm not sure what's different on alpha.
Re: ksh another home/end pair
>> In tmux, home and end send different bytes. I don't know why, but I want >> things to just work. We already have two different keys here, so what's one >> more? (how many can there be...?) > >We shouldn't have any there. That's what termcap(3) is for. If >you don't link to termcap, you don't get the functionality. I also find this change disturbing. Though termcap isn't completely suitable, we don't want the shell parsing environment and opening (re-opening) terminal config files on a regular basis. 2000+ other terminal types have been left behind. This entire functionality is a non-mandatory convenience written to assume "ANSI terminals"...
ifconfig: rm not need variable noprint
Hi tech@, this patch removes the 'noprint' variable which was added to ifconfig.c in rev 1.216 and is not in use since rev. 1.220. Cheers, Fabian Index: sbin/ifconfig/ifconfig.c === --- sbin/ifconfig/ifconfig.c.orig +++ sbin/ifconfig/ifconfig.c @@ -604,7 +604,6 @@ main(int argc, char *argv[]) int Cflag = 0; int gflag = 0; int i; - int noprint = 0; /* If no args at all, print all interfaces. */ if (argc < 2) { @@ -760,7 +759,7 @@ nextarg: argc--, argv++; } - if (argc == 0 && actions == 0 && !noprint) { + if (argc == 0 && actions == 0) { printif(ifr.ifr_name, aflag ? ifaliases : 1); exit(0); }
Re: allocation simplifications in yacc
Michael McConville wrote: > Christian Weisgerber wrote: > > Christian Weisgerber: > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > the yacc output is used in C++: > > > > Also: > > graphics/grap > > math/aamath > > math/logic2cnf > > ok? > "goto bail;", > - "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check > above */", > + "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* > overflow check above */", no, newvs isn't a short. but i alread fixed it.
Add C11 stdalign.h and stdnoreturn.h
I used n1570 for C11: http://www.iso-9899.info/n1570.html and n3242 for C++11: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf C11: stdalign.h: 7.15.1: The header defines four macros. 7.15.2: The macro alignas expands to _Alignas; the macro alignof expands to _Alignof. 7.15.3: The remaining macros are suitable for use in #if preprocessing directives. They are __alignas_is_defined and __alignof_is_defined which both expand to the integer constant 1. stdnoreturn.h: 7.23.1: The header defines the macro noreturn which expands to _Noreturn. C++11: stdalign.h: 18.10.2: The contents of these headers are the same as the Standard C library headers (...) (...) respectively, with the following changes: 18.10.6: The header and the header shall not define a macro named alignas. No mention of stdnoreturn.h. Note that C++11 does not mention "alignof", even though it mentions "alignas". Both are defined as keywords (Table 4 - Keywords). A commit in Clang has this to say: libstdc++'s #includes and expects it to guard against being included in C++. Don't define alignof or alignas in this case. Note that the C++11 standard is broken in various ways here (it refers to the contents of in C99, where that header did not exist, and doesn't mention the alignas macro at all), but we do our best to do what it intended. So I went ahead and followed Clang, not C++11. Clang's stdnoreturn.h differs from the standard as well, as it defines "__noreturn_is_defined". I couldn't find a reason, so I didn't. stdnoreturn.h isn't mentioned in C++11, so skip the #ifndef __cplusplus. The commit message in FreeBSD that contains these files notes: "Even though these header files make little sense to me, they are part of the standard.". I believe these headers are defined to preserve backwards compatibility. There might exist code where the keywords "alignas", "alignof", and "noreturn" are already defined. The standard therefore picked keywords from the reserved namespace, i.e. ones starting with an underscore and an upper case letter and provided the headers for convenience. And also make whitespace in stdbool.h consistent with other files. Index: include/Makefile === RCS file: /cvs/src/include/Makefile,v retrieving revision 1.208 diff -u -p -r1.208 Makefile --- include/Makefile18 Nov 2015 16:48:34 - 1.208 +++ include/Makefile30 Dec 2015 16:43:53 - @@ -17,8 +17,8 @@ FILES=a.out.h ar.h asr.h assert.h bitst md5.h memory.h ndbm.h netdb.h netgroup.h nlist.h nl_types.h \ paths.h poll.h pwd.h ranlib.h readpassphrase.h regex.h \ resolv.h rmd160.h search.h setjmp.h sha1.h sha2.h signal.h siphash.h \ - sndio.h \ - spawn.h stdbool.h stddef.h stdio.h stdlib.h string.h strings.h struct.h \ + sndio.h spawn.h stdalign.h stdbool.h stddef.h stdio.h stdlib.h \ + stdnoreturn.h string.h strings.h struct.h \ sysexits.h tar.h tgmath.h time.h ttyent.h unistd.h utime.h \ utmp.h uuid.h vis.h wchar.h wctype.h Index: include/stdalign.h === RCS file: include/stdalign.h diff -N include/stdalign.h --- /dev/null 1 Jan 1970 00:00:00 - +++ include/stdalign.h 30 Dec 2015 16:43:53 - @@ -0,0 +1,18 @@ +/* $OpenBSD$ */ + +/* + * Public domain. + */ + +#ifndef_STDALIGN_H_ +#define_STDALIGN_H_ + +#ifndef __cplusplus +#define alignas _Alignas +#define alignof _Alignof +#endif + +#define __alignas_is_defined 1 +#define __alignof_is_defined 1 + +#endif /* _STDALIGN_H_ */ Index: include/stdbool.h === RCS file: /cvs/src/include/stdbool.h,v retrieving revision 1.7 diff -u -p -r1.7 stdbool.h --- include/stdbool.h 4 Sep 2015 23:47:09 - 1.7 +++ include/stdbool.h 30 Dec 2015 16:43:53 - @@ -1,4 +1,4 @@ -/* $OpenBSD: stdbool.h,v 1.7 2015/09/04 23:47:09 daniel Exp $ */ +/* $OpenBSD: stdbool.h,v 1.7 2015/09/04 23:47:09 daniel Exp $ */ /* * Written by Marc Espie, September 25, 1999 Index: include/stdnoreturn.h === RCS file: include/stdnoreturn.h diff -N include/stdnoreturn.h --- /dev/null 1 Jan 1970 00:00:00 - +++ include/stdnoreturn.h 30 Dec 2015 16:43:53 - @@ -0,0 +1,12 @@ +/* $OpenBSD$ */ + +/* + * Public domain. + */ + +#ifndef_STDNORETURN_H_ +#define_STDNORETURN_H_ + +#define noreturn _Noreturn + +#endif /* _STDNORETURN_H_ */ -- Michal Mazurek
xr mktime
Neither strftime nor strptime describe the fields inside struct tm, and while they eventually point that way in references, strftime provides no guidance as to which of its nine (9!) references I should read next. I don't like guessing. Index: strftime.3 === RCS file: /cvs/src/lib/libc/time/strftime.3,v retrieving revision 1.34 diff -u -p -r1.34 strftime.3 --- strftime.3 29 Jan 2015 01:46:31 - 1.34 +++ strftime.3 30 Dec 2015 16:46:29 - @@ -47,6 +47,8 @@ The .Fn strftime function formats the information from .Fa timeptr +(as described in +.Xr mktime 3 ) into the buffer .Fa buf according to the string pointed to by Index: strptime.3 === RCS file: /cvs/src/lib/libc/time/strptime.3,v retrieving revision 1.24 diff -u -p -r1.24 strptime.3 --- strptime.3 4 Dec 2014 00:10:40 - 1.24 +++ strptime.3 30 Dec 2015 16:47:17 - @@ -44,7 +44,9 @@ function parses the string according to the specified .Fa format and fills matching data into the structure -.Fa tm . +.Fa tm +(described in +.Xr mktime 3 ) . .Pp The .Fa format
Re: allocation simplifications in yacc
> Date: Wed, 30 Dec 2015 11:30:11 -0500 > From: Michael McConville> > Christian Weisgerber wrote: > > Christian Weisgerber: > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > the yacc output is used in C++: > > > > Also: > > graphics/grap > > math/aamath > > math/logic2cnf > > ok? Please revert the diff. Then propose a new diff that only changes the NULL-check for free. > Index: skeleton.c > === > RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v > retrieving revision 1.36 > diff -u -p -r1.36 skeleton.c > --- skeleton.c28 Dec 2015 19:14:04 - 1.36 > +++ skeleton.c30 Dec 2015 16:28:57 - > @@ -137,14 +137,14 @@ char *body[] = > "#endif", > "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)", > "goto bail;", > - "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check > above */", > + "newss = (short *)realloc(yyss, newsize * sizeof(*newss)); /* > overflow check above */", > "if (newss == NULL)", > "goto bail;", > "yyss = newss;", > "yyssp = newss + sslen;", > "if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)", > "goto bail;", > - "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check > above */", > + "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* > overflow check above */", > "if (newvs == NULL)", > "goto bail;", > "yyvs = newvs;", > >
Re: allocation simplifications in yacc
Mark Kettenis wrote: > > Date: Wed, 30 Dec 2015 11:30:11 -0500 > > From: Michael McConville> > > > Christian Weisgerber wrote: > > > Christian Weisgerber: > > > > > > > The removal of the casts causes a problem in ports/devel/mico, where > > > > the yacc output is used in C++: > > > > > > Also: > > > graphics/grap > > > math/aamath > > > math/logic2cnf > > > > ok? > > Please revert the diff. Then propose a new diff that only changes the > NULL-check for free. this shouldn't be necessary. i fixed the skeleton and checked it with c++.
Re: Add C11 stdalign.h and stdnoreturn.h
This makes no sense as our base compiler doesn't support C11.
Re: Add C11 stdalign.h and stdnoreturn.h
On Wed, 30 Dec 2015 18:07:32 +0100, Mark Kettenis wrote: > This makes no sense as our base compiler doesn't support C11. In other words, it has no underlying support for _Alignas or _Alignof so this header could only be used by C compilers in ports. I don't think that's what we want... - todd
Re: allocation simplifications in yacc
Christian Weisgerber wrote: > Christian Weisgerber: > > > The removal of the casts causes a problem in ports/devel/mico, where > > the yacc output is used in C++: > > Also: > graphics/grap > math/aamath > math/logic2cnf ok? Index: skeleton.c === RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v retrieving revision 1.36 diff -u -p -r1.36 skeleton.c --- skeleton.c 28 Dec 2015 19:14:04 - 1.36 +++ skeleton.c 30 Dec 2015 16:28:57 - @@ -137,14 +137,14 @@ char *body[] = "#endif", "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)", "goto bail;", - "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check above */", + "newss = (short *)realloc(yyss, newsize * sizeof(*newss)); /* overflow check above */", "if (newss == NULL)", "goto bail;", "yyss = newss;", "yyssp = newss + sslen;", "if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)", "goto bail;", - "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check above */", + "newvs = (short *)realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check above */", "if (newvs == NULL)", "goto bail;", "yyvs = newvs;",
Re: Declare usage() as __dead on fstat(1), plus a few nitpicks
On Wed, Dec 30, 2015 at 06:41:32PM +, Ricardo Mestre wrote: > Declare usage() as __dead, and while here align a few variables to the rest of > the list and also ANSI one function. No functional change. > > OK? ok tb@ > > Index: fstat.c > === > RCS file: /cvs/src/usr.bin/fstat/fstat.c,v > retrieving revision 1.84 > diff -u -p -u -r1.84 fstat.c > --- fstat.c 17 Nov 2015 17:17:24 - 1.84 > +++ fstat.c 30 Dec 2015 18:35:29 - > @@ -96,10 +96,10 @@ int nflg; /* (numerical) display f.s. an > int oflg; /* display file offset */ > int sflg; /* display file xfer/bytes counters */ > int vflg; /* display errors in locating kernel data objects etc... */ > -int cflg; /* fuser only */ > +int cflg; /* fuser only */ > > -int fuser; /* 1 if we are fuser, 0 if we are fstat */ > -int signo; /* signal to send (fuser only) */ > +int fuser; /* 1 if we are fuser, 0 if we are fstat */ > +int signo; /* signal to send (fuser only) */ > > kvm_t *kd; > uid_t uid; > @@ -107,7 +107,7 @@ uid_t uid; > void fstat_dofile(struct kinfo_file *); > void fstat_header(void); > void getinetproto(int); > -void usage(void); > +__dead void usage(void); > int getfname(char *); > void kqueuetrans(struct kinfo_file *); > void pipetrans(struct kinfo_file *); > @@ -827,8 +827,7 @@ socktrans(struct kinfo_file *kf) > * print name of protocol number > */ > void > -getinetproto(number) > - int number; > +getinetproto(int number) > { > static int isopen; > struct protoent *pe; >
OpenBSD 5.8 on Xeon-D (1540) systems
Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 system? We're experimenting with a SuperMicro Xeon-D 1540 system (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) and are, surprisingly, not getting terribly far into the kernel boot process, with a plethora of "... not configured" messages on console preceding a complete free-up after probing the xHCI root hub. The "not configured" messages also apply to each of the 8 cores ("cpu at mainbus0: not configured"). The same thing happens with the latest snapshot (dated Dec. 27) Here's a screenshot of the console showing how far the kernel gets before things grind to a halt: http://imgur.com/zETFs7j Might anyone be able to drop a hint or some background info? /dale signature.asc Description: Message signed with OpenPGP using GPGMail
Declare usage() as __dead on fstat(1), plus a few nitpicks
Declare usage() as __dead, and while here align a few variables to the rest of the list and also ANSI one function. No functional change. OK? Index: fstat.c === RCS file: /cvs/src/usr.bin/fstat/fstat.c,v retrieving revision 1.84 diff -u -p -u -r1.84 fstat.c --- fstat.c 17 Nov 2015 17:17:24 - 1.84 +++ fstat.c 30 Dec 2015 18:35:29 - @@ -96,10 +96,10 @@ int nflg; /* (numerical) display f.s. an intoflg; /* display file offset */ intsflg; /* display file xfer/bytes counters */ intvflg; /* display errors in locating kernel data objects etc... */ -intcflg; /* fuser only */ +intcflg; /* fuser only */ -intfuser; /* 1 if we are fuser, 0 if we are fstat */ -intsigno; /* signal to send (fuser only) */ +intfuser; /* 1 if we are fuser, 0 if we are fstat */ +intsigno; /* signal to send (fuser only) */ kvm_t *kd; uid_t uid; @@ -107,7 +107,7 @@ uid_t uid; void fstat_dofile(struct kinfo_file *); void fstat_header(void); void getinetproto(int); -void usage(void); +__dead void usage(void); int getfname(char *); void kqueuetrans(struct kinfo_file *); void pipetrans(struct kinfo_file *); @@ -827,8 +827,7 @@ socktrans(struct kinfo_file *kf) * print name of protocol number */ void -getinetproto(number) - int number; +getinetproto(int number) { static int isopen; struct protoent *pe;
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> From: Dale Ghent> Date: Wed, 30 Dec 2015 14:49:58 -0500 > > Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 = > system? We're experimenting with a SuperMicro Xeon-D 1540 system = > (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) = > and are, surprisingly, not getting terribly far into the kernel boot = > process, with a plethora of "... not configured" messages on console = > preceding a complete free-up after probing the xHCI root hub. > > The "not configured" messages also apply to each of the 8 cores ("cpu at = > mainbus0: not configured"). The same thing happens with the latest = > snapshot (dated Dec. 27) > > Here's a screenshot of the console showing how far the kernel gets = > before things grind to a halt: http://imgur.com/zETFs7j > > Might anyone be able to drop a hint or some background info? You could try disabing devices in UKC. Boot your kernel with "boot -c" at the boot> prompt, and at the UKC> prompt enter "disable xhci"and "quit". If that doesn't help, try disabling other devices as well. Cheers, Mark
Re: utf8 input in el_gets(3)
Ingo Schwarze wrote: > Hi Christian & Michael, > > Michael McConville wrote on Thu, Dec 24, 2015 at 04:19:03PM -0500: > > Christian Heckendorf wrote: > > >> A couple of somewhat recent changes in NetBSD's libedit permit > >> el_gets(3) to accept multibyte characters if the locale supports > >> it. > > Ugh. The amount of indirection in that code is disturbing, and the > amount of contortion is disgusting. Such stuff is highly error > prone, in particular since the manual is way below OpenBSD standards > (functions mentioned in the SYNOPSIS but not actually documented, > vague statements, confusion regarding bytes versus characters, ...). > Besides, it's not completely clear which parts of the interface are > public and which are internal to the library. > > In the vicinity of this particular diff: The IGNORE_EXTCHARS flag > appears to be private to the library, the users seems to have no > way to change it. Otherwise, the existing code in el_getc(3) > would already be broken because it clears the flag on exit even > if it was set on entry. But as an internal flag, it's completely > pointless. If CHARSET_IS_UTF8 is set, the present diff makes > sure it is never set. If CHARSET_IS_UTF8 is not set, it has no > effect because the only place where it is used also checks "bytes > 1", > which cannot happen in the C locale. > > But if we want to stay in sync with upstream, freely borrowing Bob's > whale flensing knife may not be the best idea. > > Also note that el_gets(3) is documented to return the number of > characters read, but actually, callers assume it returns the > number of *bytes* read, so what your diff is doing makes sense. > > Michael, as you already looked at NetBSD, is there a documentation > update to go with this diff? > I'll jump in here. As far as I can tell, the man entry for this function describing the value of count hasn't been touched since the original commit for the document in 1997 (before the wide variants existed). I also found the documentation to be a source of confusion. Perhaps a change like this would help to clarify at least el_gets(3) and el_wgets(3). -- Christian Index: editline.3 === RCS file: /cvs/src/lib/libedit/editline.3,v retrieving revision 1.39 diff -u -p -r1.39 editline.3 --- editline.3 14 Sep 2015 13:45:25 - 1.39 +++ editline.3 30 Dec 2015 20:07:59 - @@ -208,7 +208,7 @@ state. .It Fn el_gets Read a line from the tty. .Fa count -is modified to contain the number of characters read. +is modified to contain the number of bytes read. Returns the line read if successful, or .Dv NULL if no characters were read or if an error occurred. @@ -220,6 +220,13 @@ contains the error code that caused it. The return value may not remain valid across calls to .Fn el_gets and must be copied if the data is to be retained. +.It Fn el_wgets +Behaves the same way as +.Fn el_gets +except that +.Fa count +is modified to contain the number of wide characters read, rather +than bytes. .It Fn el_getc Read a character from the tty. .Fa ch
Re: OpenBSD 5.8 on Xeon-D (1540) systems
I managed to get a slow-motion video of the console and transcribe the first several lines of CPU setup and probing from a verbose boot. It seems that the kernel isn't finding a lot of stuff here. >>> bios probe won bios0 at mainbus0: SMBIUOS rev. 2.8 @ 0xed8b0 (55 entries) bios0: vendor American Megatrends Inc. version "1.0b" date 09/09/2015 bios0: Supermicro X10SDV-8C-TLN4F >>> probing for mpbios0 >>> mpbios probe returned 0 >>> probing for acpi0 >>> acpi probe returned 1 >>> acpi probe won acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC FPDT FIDT SPMI NCFG UEFI HPET WDDT SSDT BGRT SSDT PRAD SMAR HEST BERT ERST EINJ >>> probing for acpiec* >>> acpiec probe returned 0 >>> probing for acpimadt0 >>> acpimadt probe returned 0 >>> probing for acpiprt* >>> acpiprt returned 0 >>> no winning probe >>> probing for acpiec* >>> acpiec probe returned 0 >>> probing for acpimadt0 >>> acpimadt probe returned 0 >>> probing for acpiprt* >>> acpiprt returned 0 >>> no winning probe >>> probing for acpiec* >>> acpiec probe returned 0 >>> probing for acpimadt0 >>> acpimadt probe returned 0 >>> probing for acpiprt* >>> acpiprt returned 0 >>> acpimadt0 probe won acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >>> probing for cpu0 >>> cpu probe returned 1 >>> probing for ioapic* >>> ioapic probe returned 0 >>> probing for efifb0 >>> efifb probe returned 0 >>> probing for pci* >>> pci probe returned 0 >>> probing for isa0 >>> isa probe returned 0 >>> cpu probe won cpu0 at mainbus0: apid 0 (application processor) cpu0: not started >>> probing for ioapic* >>> ioapic probe returned 0 >>> probing for efifb0 >>> efifb probe returned 0 >>> probing for pci* >>> pci probe returned 0 >>> probing for isa0 >>> isa probe returned 0 >>> no winning probe cpu at mainbus0: not configured >>> probing for ioapic* >>> ioapic probe returned 0 >>> probing for efifb0 >>> efifb probe returned 0 >>> probing for pci* >>> pci probe returned 0 ... and so on for each CPU. > On Dec 30, 2015, at 2:49 PM, Dale Ghentwrote: > > > Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 system? > We're experimenting with a SuperMicro Xeon-D 1540 system > (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) and > are, surprisingly, not getting terribly far into the kernel boot process, > with a plethora of "... not configured" messages on console preceding a > complete free-up after probing the xHCI root hub. > > The "not configured" messages also apply to each of the 8 cores ("cpu at > mainbus0: not configured"). The same thing happens with the latest snapshot > (dated Dec. 27) > > Here's a screenshot of the console showing how far the kernel gets before > things grind to a halt: http://imgur.com/zETFs7j > > Might anyone be able to drop a hint or some background info? > > /dale signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> On Dec 30, 2015, at 3:21 PM, Mark Ketteniswrote: > >> From: Dale Ghent >> Date: Wed, 30 Dec 2015 14:49:58 -0500 >> >> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 = >> system? We're experimenting with a SuperMicro Xeon-D 1540 system = >> (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) = >> and are, surprisingly, not getting terribly far into the kernel boot = >> process, with a plethora of "... not configured" messages on console = >> preceding a complete free-up after probing the xHCI root hub. >> >> The "not configured" messages also apply to each of the 8 cores ("cpu at = >> mainbus0: not configured"). The same thing happens with the latest = >> snapshot (dated Dec. 27) >> >> Here's a screenshot of the console showing how far the kernel gets = >> before things grind to a halt: http://imgur.com/zETFs7j >> >> Might anyone be able to drop a hint or some background info? > > You could try disabing devices in UKC. Boot your kernel with "boot > -c" at the boot> prompt, and at the UKC> prompt enter "disable > xhci"and "quit". If that doesn't help, try disabling other devices as > well. We've tried that route, but unfortunately there's not a whole lot in the BIOS options to turn off, including the USB controllers. I just replied to my original post with a transcription of the kernel messages when it tries to initially probe and set up the busses and cpus... clearly it isn't happy with something. /dale signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> From: Dale Ghent> Date: Wed, 30 Dec 2015 15:35:42 -0500 > > > On Dec 30, 2015, at 3:21 PM, Mark Kettenis = > wrote: > >=20 > >> From: Dale Ghent > >> Date: Wed, 30 Dec 2015 14:49:58 -0500 > >>=20 > >> Has anyone used or otherwise been able to boot 5.8 on a Xeon-D 1540 =3D= > > >> system? We're experimenting with a SuperMicro Xeon-D 1540 system =3D > >> = > (http://www.supermicro.com/products/system/1U/5018/SYS-5018D-FN4T.cfm) =3D= > > >> and are, surprisingly, not getting terribly far into the kernel boot = > =3D > >> process, with a plethora of "... not configured" messages on console = > =3D > >> preceding a complete free-up after probing the xHCI root hub. > >>=20 > >> The "not configured" messages also apply to each of the 8 cores ("cpu = > at =3D > >> mainbus0: not configured"). The same thing happens with the latest =3D > >> snapshot (dated Dec. 27) > >>=20 > >> Here's a screenshot of the console showing how far the kernel gets =3D > >> before things grind to a halt: http://imgur.com/zETFs7j > >>=20 > >> Might anyone be able to drop a hint or some background info? > >=20 > > You could try disabing devices in UKC. Boot your kernel with "boot > > -c" at the boot> prompt, and at the UKC> prompt enter "disable > > xhci"and "quit". If that doesn't help, try disabling other devices as > > well. > > We've tried that route, but unfortunately there's not a whole lot in the = > BIOS options to turn off, including the USB controllers. I just replied = > to my original post with a transcription of the kernel messages when it = > tries to initially probe and set up the busses and cpus... clearly it = > isn't happy with something. Read my message again. I'm suggesting to turn xhci off in the kernel, not the BIOS. Also, using a serial console could help catching afull dmesg. Looks like there is no physical serial port, but you can use the IPMI SOL(serial-over-LAN). Assuming console redirection to COM1 is enabled in the bios. Enter "stty com1 115200" and "set tty com1" at the OpenBSD bootloader boot> prompt to let the kernel use the serial port as the console. Cheers, Mark
Re: malloc should always abort
Hi Ted, FWIW, I agree with malloc always failing on error. On Wed, Dec 30, 2015 at 7:12 AM, Ted Unangstwrote: > @@ -523,10 +521,8 @@ omalloc_init(struct dir_info **dp) > mopts.malloc_cache >>= 1; > break; > case 'a': > - mopts.malloc_abort = 0; > break; > case 'A': > - mopts.malloc_abort = 1; > break; > case 'c': > mopts.malloc_canaries = 0; > I guess you will remove the option treatment in a near future ? ;-) On a side note, with this option var removal, you can collapse the switch condition as : @@ -523,10 +521,7 @@ omalloc_init(struct dir_info **dp) mopts.malloc_cache >>= 1; break; case 'a': - mopts.malloc_abort = 0; - break; case 'A': - mopts.malloc_abort = 1; break; case 'c': mopts.malloc_canaries = 0; Thierry
carp: fix SIOCSVH if carpr.carpr_carpdev is \0
Hi tech@, i've found the undocumented -carpdev option in ifconfig(8) which freezes my sytem if executed. As the -carpdev option is undocumented in both ifconfig(8) and carp(4) i propose two patches to remove this functionality. The patch below will return EINVAL in SIOCSVH if carpr.carpr_carpdev is not a valid interface name. I will send another patch to @tech to remove -carpdev from ifconfig(8) Cheers, Fabian Index: ip_carp.c === RCS file: /cvs/src/sys/netinet/ip_carp.c,v retrieving revision 1.284 diff -u -p -r1.284 ip_carp.c --- ip_carp.c 19 Dec 2015 11:19:35 - 1.284 +++ ip_carp.c 30 Dec 2015 11:31:57 - @@ -2022,8 +2022,7 @@ carp_ioctl(struct ifnet *ifp, u_long cmd if ((error = copyin(ifr->ifr_data, , sizeof carpr))) break; error = 1; - if (carpr.carpr_carpdev[0] != '\0' && - (ifp0 = ifunit(carpr.carpr_carpdev)) == NULL) + if ((ifp0 = ifunit(carpr.carpr_carpdev)) == NULL) return (EINVAL); if (carpr.carpr_peer.s_addr == 0) sc->sc_peer.s_addr = INADDR_CARP_GROUP;
ifconfig: remove undocumented -carpdev
Hi, please find below a patch to remove the undocumented -carpdev command from ifconfig(8). Cheers, Fabian Index: ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.311 diff -u -p -r1.311 ifconfig.c --- ifconfig.c 10 Dec 2015 17:26:59 - 1.311 +++ ifconfig.c 30 Dec 2015 11:07:40 - @@ -236,7 +236,6 @@ voidsetcarp_passwd(const char *, int); void setcarp_vhid(const char *, int); void setcarp_state(const char *, int); void setcarpdev(const char *, int); -void unsetcarpdev(const char *, int); void setcarp_nodes(const char *, int); void setcarp_balancing(const char *, int); void setpfsync_syncdev(const char *, int); @@ -395,7 +394,6 @@ const structcmd { { "carpdev",NEXTARG,0, setcarpdev }, { "carpnodes", NEXTARG,0, setcarp_nodes }, { "balancing", NEXTARG,0, setcarp_balancing }, - { "-carpdev", 1, 0, unsetcarpdev }, { "syncdev",NEXTARG,0, setpfsync_syncdev }, { "-syncdev", 1, 0, unsetpfsync_syncdev }, { "syncif", NEXTARG,0, setpfsync_syncdev }, @@ -4008,23 +4006,6 @@ setcarpdev(const char *val, int d) err(1, "SIOCGVH"); strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev)); - - if (ioctl(s, SIOCSVH, (caddr_t)) == -1) - err(1, "SIOCSVH"); -} - -void -unsetcarpdev(const char *val, int d) -{ - struct carpreq carpr; - - bzero(, sizeof(struct carpreq)); - ifr.ifr_data = (caddr_t) - - if (ioctl(s, SIOCGVH, (caddr_t)) == -1) - err(1, "SIOCGVH"); - - bzero(_carpdev, sizeof(carpr.carpr_carpdev)); if (ioctl(s, SIOCSVH, (caddr_t)) == -1) err(1, "SIOCSVH");
Re: [patch] kern/exec_script: avoid invalid free() in a case of error
Michael McConville wrote: > Michael McConville wrote: > > Michael McConville wrote: > > > > On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev> > > > wrote: > > > > > Hi, > > > > > > > > > > In exec_script_makecmds function, when EXEC_HASFD flag was set, but > > > > > copystr/copyinstr returns an error, we need to set *tmpsap to NULL to > > > > > terminate a loop (under "fail" label) correctly. > > > > > > I spent a while straining to see the forest through the trees, but this > > > makes sense to me. ok mmcc@ > > > > > > Is this allocation chain idiom used elsewhere in sys/kern? Maybe we > > > could break it out into ~3 functions. The current state of affairs seems > > > bug-prone. > > > > It seems that all possible paths through this nested condition increment > > tmpsap. Why not just increment it afterward so no one else ends up with > > the headache I now have? > > > > As always: I could be misinterpreting this. > > tedu and gsoares pointed out the nop expression in my last diff. I guess > I was moving too fast... > > Here's a new one: this looks better to me.
Re: ksh another home/end pair
tmux is doing the right thing and changing what it generates would break other programs. ksh should use terminfo to work out what to expect, but we have always resisted linking ksh against ncurses. Your change is the best we can do without making ksh use ncurses. On Wed, Dec 30, 2015 at 01:19:24AM -0500, Ted Unangst wrote: > Mark Kettenis wrote: > > > From: "Ted Unangst"> > > Date: Tue, 29 Dec 2015 12:11:25 -0500 > > > > > > In tmux, home and end send different bytes. I don't know why, but I want > > > things to just work. We already have two different keys here, so what's > > > one > > > more? (how many can there be...?) > > > > Isn't that somehowa tmux bug? I mean, isn't tmux supposed to be > > compatible with some standard terminal type? > > It could be. I don't know why tmux chooses a different set of bytes to > represent home/end than xterm. I mostly don't care. > > There was a thread on misc about this where it was suggested I either > reconfigure ksh or tmux. Or both. But that's silly. This should work out of > the box. > > If somebody would like to propose a diff for tmux, I'd be happy with that, but > I'm not sure where to begin myself. ksh already appears to be trying to > support a nonconflicting superset of terminal types without resorting to > termcap, so it seemed logical to fix here. > > http://marc.info/?l=openbsd-misc=144906064413240=2 >
Re: Another mpsafe ix(4) diff
On 29.12.2015. 22:23, Hrvoje Popovski wrote: > On 29.12.2015. 17:49, Mark Kettenis wrote: >>> Date: Tue, 22 Dec 2015 23:45:49 +0100 On 22.12.2015. 22:08, Mark Kettenis wrote: >> Anybody willing to give this a spin? I don't have access to hardware >> currently... >> >> Thanks, >> >> Mark Hi, i'm sending 1.1Mpps and this patch almost immediately trigger OACTIVE flag. Patch is applied on clean source few minutes ago. If there is anything i can do more, please tell >> ok, that diff wasn't quite right. Here is a better one. This one >> gets rid of the ridiculous number of scatter segments on the 82598. >> There really is no point in allowing that many segments, and with the >> new code it would reduce the usable part of the tx ring significantly. >> >> I did some testing of forwarding performance on a machine with two >> sockets filled with: >> >> cpu0: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2400.37 MHz >> >> for a total of 16 cores forwarding between ix1 and ix0: >> >> ix0 at pci3 dev 0 function 0 "Intel X540T" rev 0x01: msi, address >> 0c:c4:7a:4d:a3:e4 >> ix1 at pci3 dev 0 function 1 "Intel X540T" rev 0x01: msi, address >> 0c:c4:7a:4d:a3:e5 >> >> I basically tested how many pps I could push through the box without >> loss, and many pps got through if sent 1Mpps into the box. All >> testing was done with pf disabled. >> >> With -current I got the following numbers: >> >> - 730kpps without loss >> - 82kpps when receiving 1Mpps >> >> and if I set net.inet.ip.ifq.maxlen to 8000 I got: >> >> - 740kpps without loss >> - 640-740kpps when receiving 1Mpps (fluctuating) >> >> With this diff I got: >> >> - 670kpps without loss >> - 250kpps when receiving 1Mpps >> >> and if I set net.inet.ip.ifq.maxlen to 8000 I got: >> >> - 690kpps without loss >> - 680kpps when receiving 1Mpps (fluctuating) >> >> So the maximal throughput goes slightly down, but it seems it with the >> diff it behaves betterunder load. >> >> Further tests are welcome! > > > Hi, > > i'm getting similar results with this patch. Sending 1Mpps and getting > 750Kpps. I didn't see OACTIVE flag even when generating 14Mpps :) > > PF=no > ddb.console=1 > kern.pool_debug=0 > net.inet.ip.forwarding=1 > net.inet.ip.ifq.maxlen=8192 > kern.maxclusters=32768 > > One cpu... > Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz, 2800.01 MHz > > ix0 at pci2 dev 0 function 0 "Intel 82599" rev 0x01: msi, address > 90:e2:ba:33:af:ec > ix1 at pci2 dev 0 function 1 "Intel 82599" rev 0x01: msi, address > 90:e2:ba:33:af:ed > just for fun i leave 14Mpps through box over night and ssh is alive, very slow but it's alive ... and i'm getting stable 650Kpps without OACTIVE flag ...
Re: ifconfig: remove undocumented -carpdev
Fabian Raetz(fabian.ra...@gmail.com) on 2015.12.30 13:32:54 +0100: > On Wed, Dec 30, 2015 at 07:24:01AM -0500, Ted Unangst wrote: > > Fabian Raetz wrote: > > > Hi, > > > > > > please find below a patch to remove the undocumented -carpdev command from > > > ifconfig(8). > > > > wouldn't it make more sense to document the command? > > as the command is broken [0] and nobody noticed it so far, i'm > wondering if anybody needs -carpdev > > [0] https://www.marc.info/?l=openbsd-tech=145147632420539=2 -carpdev was valid back when you did not have to specify the device. Until some time ago there was magic that chose the parent dev based on the ip on the carp - the idea was that it must be in the same net as the parent. This was removed (by mpi i think) to reduce complexety. So now you always have to specify the carpdev. I believe the option can go.
Re: ifconfig: remove undocumented -carpdev
On Wed, Dec 30, 2015 at 07:24:01AM -0500, Ted Unangst wrote: > Fabian Raetz wrote: > > Hi, > > > > please find below a patch to remove the undocumented -carpdev command from > > ifconfig(8). > > wouldn't it make more sense to document the command? as the command is broken [0] and nobody noticed it so far, i'm wondering if anybody needs -carpdev [0] https://www.marc.info/?l=openbsd-tech=145147632420539=2
Re: allocation simplifications in yacc
Michael McConville: > Index: skeleton.c > === > RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v > retrieving revision 1.35 > diff -u -p -r1.35 skeleton.c > --- skeleton.c16 Mar 2014 18:38:30 - 1.35 > +++ skeleton.c24 Dec 2015 17:34:02 - > @@ -137,16 +137,14 @@ char *body[] = > "#endif", > "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)", > "goto bail;", > - "newss = yyss ? (short *)realloc(yyss, newsize * sizeof *newss) :", > - " (short *)malloc(newsize * sizeof *newss); /* overflow check > above */", > + "newss = realloc(yyss, newsize * sizeof(*newss)); /* overflow check > above */", > "if (newss == NULL)", > "goto bail;", > "yyss = newss;", > "yyssp = newss + sslen;", > "if (newsize && YY_SIZE_MAX / newsize < sizeof *newvs)", > "goto bail;", > - "newvs = yyvs ? (YYSTYPE *)realloc(yyvs, newsize * sizeof *newvs) > :", > - " (YYSTYPE *)malloc(newsize * sizeof *newvs); /* overflow check > above */", > + "newvs = realloc(yyvs, newsize * sizeof(*newvs)); /* overflow check > above */", > "if (newvs == NULL)", > "goto bail;", > "yyvs = newvs;", The removal of the casts causes a problem in ports/devel/mico, where the yacc output is used in C++: c++ -I. -I../include -Wall -Wwrite-strings -O2 -pipe -fno-strict-aliasing -D_REENTRANT -D_THREAD_SAFE-c yacc.cc -o yacc.o yacc.c: In function 'int yygrowstack()': yacc.c:1183: error: invalid conversion from 'void*' to 'short int*' yacc.c:1190: error: invalid conversion from 'void*' to 'YYSTYPE*' yacc.c: In function 'int yyparse()': yacc.c:1280: warning: deprecated conversion from string constant to 'char*' yacc.c:3528: warning: deprecated conversion from string constant to 'char*' -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: allocation simplifications in yacc
Christian Weisgerber: > The removal of the casts causes a problem in ports/devel/mico, where > the yacc output is used in C++: Also: graphics/grap math/aamath math/logic2cnf -- Christian "naddy" Weisgerber na...@mips.inka.de
Get PCI resources from ACPI
It seems more and more server machines ship in a "64-bit" configuration where the BIOS assigns addresses above the 4GB mark to 64-bit BARs. We have a hack in arch/amd64/pci_machdep.c:pci_init_extents() to deal with some of these configurations: /* * ... * * Dell 13G servers have important devices outside the * 36-bit address space. Until we can extract the address * ranges from ACPI, expand the allowed range to suit. */ I ran into a SuperMicro machine that puts stuff even higher. And ratherthan extending the range again, I think it is time to bite the bullet and trust ACPI. The diff below is a first stab. Needs a bit more polish, but before I spend more time on it, I'd like to get some test results. I'd like to see the diff tested on a wide variety of machines. Please send me old and new dmesg and acpidump output. Warning! A kernel with this diff might panic early on in the boot process, so don't play with it unless you have a way to boot your previous kernel. Index: acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.297 diff -u -p -r1.297 acpi.c --- acpi.c 23 Nov 2015 00:10:53 - 1.297 +++ acpi.c 30 Dec 2015 13:03:38 - @@ -561,6 +561,48 @@ acpi_matchhids(struct acpi_attach_args * return (0); } +int +acpi_fill_memex(union acpi_resource *crs, void *arg) +{ + int type = AML_CRSTYPE(crs); + struct extent *ex = arg; + uint64_t min, max, len; + uint16_t flags; + + switch (type) { + case LR_DWORD: + type = crs->lr_dword.type; + flags = crs->lr_dword.flags; + len = crs->lr_dword._len; + min = crs->lr_dword._min; + max = crs->lr_dword._max; + break; + case LR_QWORD: + type = crs->lr_qword.type; + flags = crs->lr_qword.flags; + len = crs->lr_qword._len; + min = crs->lr_qword._min; + max = crs->lr_qword._max; + break; + default: + return 0; + } + + if (type != 0) + return 0; + if (len == 0) + return 0; + if ((flags & 0xc) != 0xc) + return 0; + if (min >= max) + return 0; + if (len != max - min + 1) + return 0; + + extent_free(ex, min, len, EX_NOWAIT); + return 0; +} + /* Map ACPI device node to PCI */ int acpi_getpci(struct aml_node *node, void *arg) @@ -573,10 +615,17 @@ acpi_getpci(struct aml_node *node, void pcitag_t tag; uint64_t val; uint32_t reg; + int64_t sta = 0; if (!node->value || node->value->type != AML_OBJTYPE_DEVICE) return 0; - if (!aml_evalhid(node, )) { + + /* Evaluate _STA to decide PCI Root node fate and walk fate */ + if (aml_evalinteger(sc, node, "_STA", 0, NULL, )) + sta = STA_PRESENT | STA_ENABLED | STA_DEV_OK | 0x1000; + + if ((sta & (STA_PRESENT|STA_ENABLED)) == (STA_PRESENT|STA_ENABLED) && + !aml_evalhid(node, )) { /* Check if this is a PCI Root node */ if (_acpi_matchhids(res.v_string, pcihid)) { aml_freevalue(); @@ -603,6 +652,18 @@ acpi_getpci(struct aml_node *node, void dnprintf(10, "found PCI root: %s %d\n", aml_nodename(node), pci->bus); TAILQ_INSERT_TAIL(_pcirootdevs, pci, next); + + pci->memex = extent_create("pcimem", 0, -1, M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED); + KASSERT(pci->memex != NULL); + + if (aml_evalname(sc, node, "_CRS", 0, NULL, ) == 0) { + aml_parse_resource(, acpi_fill_memex, pci->memex); + aml_freevalue(); + printf("bus %d\n", pci->bus); + extent_print(pci->memex); + if (pci->bus == 0) + pcimem_ex = pci->memex; + } } aml_freevalue(); return 0; @@ -833,6 +894,7 @@ acpi_pciroots_attach(struct device *dev, 1, EX_NOWAIT) != 0) continue; pba->pba_bus = pdev->bus; + pba->pba_memex = pdev->memex; config_found(dev, pba, pr); } } Index: amltypes.h === RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v retrieving revision 1.40 diff -u -p -r1.40 amltypes.h --- amltypes.h 7 Sep 2012 19:19:59 - 1.40 +++ amltypes.h 30 Dec 2015 13:03:38 - @@ -362,6 +362,8 @@
Re: malloc should always abort
On Wed, Dec 30, 2015 at 01:12:05AM -0500, Ted Unangst wrote: > Long ago, malloc internally had two kinds of failures, warnings and errors. > The 'A' option elevated warningst to errors, and has been the default for some > time. But then warnings were effectively eliminated in favor of everything > being an error, but then the 'a' flag turned errors into warnings! > > 1. This is bad because it means unconditional failures can now be made > conditional. > 2. If you are using 'X' (not recommended imo) then the 'a' option effectively > disables that as well because of the merger. > 3. Nobody should be running with 'a' anyway. > > We should remove the 'a' option. This diff does. There is now some redundant > code left to handle wrterror() returning which can be removed next. > This seems to be the natural reaction to the bug reported by Michal and the one you fixed earlier today. ok tb@ > > Index: lib/libc/stdlib/malloc.3 > === > RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v > retrieving revision 1.91 > diff -u -p -r1.91 malloc.3 > --- lib/libc/stdlib/malloc.3 14 Sep 2015 13:08:01 - 1.91 > +++ lib/libc/stdlib/malloc.3 30 Dec 2015 06:07:59 - > @@ -345,10 +345,7 @@ or > detect an error condition, > a message will be printed to file descriptor > 2 (not using stdio). > -Errors will result in the process being aborted, > -unless the > -.Cm a > -option has been specified. > +Errors will result in the process being aborted. > .Pp > Here is a brief description of the error messages and what they mean: > .Bl -tag -width Ds > Index: lib/libc/stdlib/malloc.c > === > RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v > retrieving revision 1.179 > diff -u -p -r1.179 malloc.c > --- lib/libc/stdlib/malloc.c 30 Dec 2015 06:04:39 - 1.179 > +++ lib/libc/stdlib/malloc.c 30 Dec 2015 06:08:00 - > @@ -177,7 +177,6 @@ struct chunk_info { > > struct malloc_readonly { > struct dir_info *malloc_pool; /* Main bookkeeping information */ > - int malloc_abort; /* abort() on error */ > int malloc_freenow; /* Free quickly - disable chunk rnd */ > int malloc_freeunmap; /* mprotect free pages PROT_NONE? */ > int malloc_hint;/* call madvice on free pages? */ > @@ -280,8 +279,8 @@ wrterror(char *msg, void *p) > #endif /* MALLOC_STATS */ > > errno = saved_errno; > - if (mopts.malloc_abort) > - abort(); > + > + abort(); > } > > static void > @@ -485,7 +484,6 @@ omalloc_init(struct dir_info **dp) > /* >* Default options >*/ > - mopts.malloc_abort = 1; > mopts.malloc_junk = 1; > mopts.malloc_move = 1; > mopts.malloc_cache = MALLOC_DEFAULT_CACHE; > @@ -523,10 +521,8 @@ omalloc_init(struct dir_info **dp) > mopts.malloc_cache >>= 1; > break; > case 'a': > - mopts.malloc_abort = 0; > break; > case 'A': > - mopts.malloc_abort = 1; > break; > case 'c': > mopts.malloc_canaries = 0; > Index: share/man/man5/malloc.conf.5 > === > RCS file: /cvs/src/share/man/man5/malloc.conf.5,v > retrieving revision 1.2 > diff -u -p -r1.2 malloc.conf.5 > --- share/man/man5/malloc.conf.5 9 Dec 2015 14:09:50 - 1.2 > +++ share/man/man5/malloc.conf.5 30 Dec 2015 06:08:00 - > @@ -35,14 +35,6 @@ and finally for the global variable > and scan them for flags in that order. > Flags are single letters, uppercase means on, lowercase means off. > .Bl -tag -width indent > -.It Cm A > -.Dq Abort . > -.Xr malloc 3 > -will coredump the process, rather than tolerate internal > -inconsistencies or incorrect usage. > -This is the default and a very handy debugging aid, > -since the core file represents the time of failure, > -rather than when the bogus pointer was used. > .It Cm C > .Dq Canaries . > Add canaries at the end of allocations in order to detect >
mg(1) dired-find-alternate-file
By shuffling find-alternate-file around we have dired-find-alternate-file as well. ok? -lum Index: def.h === RCS file: /cvs/src/usr.bin/mg/def.h,v retrieving revision 1.153 diff -u -p -u -p -r1.153 def.h --- def.h 29 Dec 2015 19:44:32 - 1.153 +++ def.h 30 Dec 2015 13:20:35 - @@ -377,6 +377,7 @@ int makebkfile(int, int); int writeout(FILE **, struct buffer *, char *); voidupmodes(struct buffer *); size_t xbasename(char *, const char *, size_t); +int do_filevisitalt(char *); /* line.c X */ struct line*lalloc(int); Index: dired.c === RCS file: /cvs/src/usr.bin/mg/dired.c,v retrieving revision 1.81 diff -u -p -u -p -r1.81 dired.c --- dired.c 11 Dec 2015 20:21:23 - 1.81 +++ dired.c 30 Dec 2015 13:20:35 - @@ -51,6 +51,7 @@ static int d_forwline(int, int); static int d_backline(int, int); static int d_killbuffer_cmd(int, int); static int d_refreshbuffer(int, int); +static int d_filevisitalt(int, int); static void reaper(int); static struct buffer *refreshbuffer(struct buffer *); static int createlist(struct buffer *); @@ -120,7 +121,9 @@ static PF diredcz[] = { d_create_directory /* + */ }; -static PF diredc[] = { +static PF direda[] = { + d_filevisitalt, /* a */ + rescan, /* b */ d_copy, /* c */ d_del, /* d */ d_findfile, /* e */ @@ -184,7 +187,7 @@ static struct KEYMAPE (7) diredmap = { CCHR('Z'), '+', diredcz, (KEYMAP *) & metamap }, { - 'c', 'g', diredc, NULL + 'a', 'g', direda, NULL }, { 'n', 'x', diredn, NULL @@ -838,6 +841,17 @@ d_backline (int f, int n) { backline(f | FFRAND, n); return (d_warpdot(curwp->w_dotp, >w_doto)); +} + +int +d_filevisitalt (int f, int n) +{ + char fname[NFILEN]; + + if (d_makename(curwp->w_dotp, fname, sizeof(fname)) == ABORT) + return (FALSE); + + return(do_filevisitalt(fname)); } /* Index: file.c === RCS file: /cvs/src/usr.bin/mg/file.c,v retrieving revision 1.99 diff -u -p -u -p -r1.99 file.c --- file.c 29 Oct 2015 19:46:47 - 1.99 +++ file.c 30 Dec 2015 13:20:35 - @@ -94,9 +94,7 @@ filevisit(int f, int n) int filevisitalt(int f, int n) { - struct buffer *bp; - char fname[NFILEN], *bufp, *adjf; - int status; + char fname[NFILEN], *bufp, *fn; if (getbufcwd(fname, sizeof(fname)) != TRUE) fname[0] = '\0'; @@ -107,11 +105,23 @@ filevisitalt(int f, int n) else if (bufp[0] == '\0') return (FALSE); + fn = fname; + + return (do_filevisitalt(fn)); +} + +int +do_filevisitalt(char *fn) +{ + struct buffer *bp; + int status; + char*adjf; + status = killbuffer(curbp); if (status == ABORT || status == FALSE) return (ABORT); - adjf = adjustname(fname, TRUE); + adjf = adjustname(fn, TRUE); if (adjf == NULL) return (FALSE); if (fisdir(adjf) == TRUE) Index: mg.1 === RCS file: /cvs/src/usr.bin/mg/mg.1,v retrieving revision 1.99 diff -u -p -u -p -r1.99 mg.1 --- mg.129 Dec 2015 19:44:32 - 1.99 +++ mg.130 Dec 2015 13:20:35 - @@ -952,6 +952,8 @@ dired-next-line dired-shell-command .It + dired-create-directory +.It a +dired-find-alternate-file .It c dired-do-copy .It d and C-d @@ -988,6 +990,9 @@ Copy the file listed on the current line Delete the files that have been flagged for deletion. .It dired-do-rename Rename the file listed on the current line of the dired buffer. +.It dired-find-alternate-file +Replace the current dired buffer with an alternate one as specified +by the position of the cursor. .It dired-find-file Open the file on the current line of the dired buffer. If the cursor is on a directory it will be opened in dired mode.
Re: pledge tokenadm(8)
On Wed, Dec 23, 2015 at 04:26:11PM +, Ricardo Mestre wrote: > Hi tech@ > > tokenadm(8) pretty much needs almost the same pledge annotations as > login_token(8), > "rpath wpath cpath fattr flock" for operations on the DB files and before that > it also needs getpw due to calling getgrnam(3) to get the group (TOKEN_GROUP). > In this case where both differ is that tokenadm(8) doesn't call > readpassphrase(3) > and therefore it doesn't need tty. > > Any comments? Please move the pledge() line just before the while(getopt) loop. otherwise OK bluhm@ > > Index: tokenadm.c > === > RCS file: /cvs/src/usr.sbin/tokenadm/tokenadm.c,v > retrieving revision 1.10 > diff -u -p -u -r1.10 tokenadm.c > --- tokenadm.c16 Jan 2015 06:40:22 - 1.10 > +++ tokenadm.c23 Dec 2015 22:24:26 - > @@ -167,6 +167,9 @@ main(int argc, char **argv) > goto usage; > } > > + if (pledge("stdio rpath wpath cpath fattr flock getpw", NULL) == -1) > + err(1, "pledge"); > + > if (what == LIST && (dmode || emode)) > what = MODECH;
Re: ifconfig: remove undocumented -carpdev
Fabian Raetz wrote: > Hi, > > please find below a patch to remove the undocumented -carpdev command from > ifconfig(8). wouldn't it make more sense to document the command?
Re: ksh another home/end pair
On 2015-12-29, "Ted Unangst"wrote: > In tmux, home and end send different bytes. I don't know why, but I want > things to just work. We already have two different keys here, so what's one > more? (how many can there be...?) We shouldn't have any there. That's what termcap(3) is for. If you don't link to termcap, you don't get the functionality. -- Christian "naddy" Weisgerber na...@mips.inka.de