newsyslog hardcoded paths
Some of the paths #define'd in newsyslog.c seem to be outfated. Jan Index: newsyslog.c === RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.c,v retrieving revision 1.93 diff -u -p -r1.93 newsyslog.c --- newsyslog.c 16 Jan 2015 06:40:10 - 1.93 +++ newsyslog.c 18 Feb 2015 08:58:13 - @@ -75,7 +75,7 @@ #define CONF "/etc/newsyslog.conf" /* Configuration file */ #endif #ifndef PIDFILE -#define PIDFILE "/etc/syslog.pid" +#define PIDFILE "/var/run/syslog.pid" #endif #ifndef COMPRESS #define COMPRESS "/usr/bin/compress" /* File compression program */ @@ -87,7 +87,7 @@ #define STATS_DIR "/etc" #endif #ifndef SENDMAIL -#define SENDMAIL "/usr/lib/sendmail" +#define SENDMAIL "/usr/sbin/sendmail" #endif #include /* DEV_BSIZE */
Re: event(3): add misssing prototypes / reorder
On Wed, Feb 18, 2015 at 07:16:14AM +, Nicholas Marriott wrote: > I think reordering and missing arguments etc is fine, but we shouldn't > add the missing prototypes until we are adding documentation for them as > well. Can you send a diff with just the fixes for the current prototypes > first? > > Thanks > Hi Nicholas, here's a new diff without the missing prototypes. diff --git a/lib/libevent/Makefile b/lib/libevent/Makefile index f1226a2..feb8202 100644 --- a/lib/libevent/Makefile +++ b/lib/libevent/Makefile @@ -9,24 +9,11 @@ HDRS= event.h evutil.h MAN= event.3 evbuffer_new.3 MLINKS=event.3 event_init.3 \ event.3 event_dispatch.3 \ - event.3 event_loop.3 \ - event.3 event_loopexit.3 \ - event.3 event_loopbreak.3 \ event.3 event_set.3 \ - event.3 event_base_dispatch.3 \ - event.3 event_base_loop.3 \ - event.3 event_base_loopexit.3 \ - event.3 event_base_loopbreak.3 \ - event.3 event_base_set.3 \ - event.3 event_base_free.3 \ event.3 event_add.3 \ event.3 event_del.3 \ - event.3 event_once.3 \ - event.3 event_base_once.3 \ event.3 event_pending.3 \ event.3 event_initialized.3 \ - event.3 event_priority_init.3 \ - event.3 event_priority_set.3 \ event.3 evtimer_set.3 \ event.3 evtimer_add.3 \ event.3 evtimer_del.3 \ @@ -37,6 +24,22 @@ MLINKS= event.3 event_init.3 \ event.3 signal_del.3 \ event.3 signal_pending.3 \ event.3 signal_initialized.3 \ + event.3 event_once.3 \ + event.3 event_loop.3 \ + event.3 event_loopexit.3 \ + event.3 event_loopbreak.3 \ + event.3 event_asr_run.3 \ + event.3 event_asr_abort.3 \ + event.3 event_priority_init.3 \ + event.3 event_priority_set.3 \ + event.3 event_base_dispatch.3 \ + event.3 event_base_loop.3 \ + event.3 event_base_loopexit.3 \ + event.3 event_base_loopbreak.3 \ + event.3 event_base_set.3 \ + event.3 event_base_once.3 \ + event.3 event_base_free.3 \ + event.3 bufferevent_base_set.3 \ event.3 bufferevent_new.3 \ event.3 bufferevent_free.3 \ event.3 bufferevent_write.3 \ @@ -45,9 +48,6 @@ MLINKS= event.3 event_init.3 \ event.3 bufferevent_enable.3 \ event.3 bufferevent_disable.3 \ event.3 bufferevent_settimeout.3 \ - event.3 bufferevent_base_set.3 \ - event.3 event_asr_run.3 \ - event.3 event_asr_abort.3 \ evbuffer_new.3 evbuffer_free.3 \ evbuffer_new.3 evbuffer_setcb.3 \ evbuffer_new.3 evbuffer_expand.3 \ diff --git a/lib/libevent/event.3 b/lib/libevent/event.3 index 7354b1a..2c76326 100644 --- a/lib/libevent/event.3 +++ b/lib/libevent/event.3 @@ -29,24 +29,11 @@ .Sh NAME .Nm event_init , .Nm event_dispatch , -.Nm event_loop , -.Nm event_loopexit , -.Nm event_loopbreak , .Nm event_set , -.Nm event_base_dispatch , -.Nm event_base_loop , -.Nm event_base_loopexit , -.Nm event_base_loopbreak , -.Nm event_base_set , -.Nm event_base_free , .Nm event_add , .Nm event_del , -.Nm event_once , -.Nm event_base_once , .Nm event_pending , .Nm event_initialized , -.Nm event_priority_init , -.Nm event_priority_set , .Nm evtimer_set , .Nm evtimer_add , .Nm evtimer_del , @@ -57,6 +44,22 @@ .Nm signal_del , .Nm signal_pending , .Nm signal_initialized , +.Nm event_once , +.Nm event_loop , +.Nm event_loopexit , +.Nm event_loopbreak , +.Nm event_asr_run , +.Nm event_asr_abort, +.Nm event_priority_init , +.Nm event_priority_set , +.Nm event_base_dispatch , +.Nm event_base_loop , +.Nm event_base_loopexit , +.Nm event_base_loopbreak , +.Nm event_base_set , +.Nm event_base_once , +.Nm event_base_free , +.Nm bufferevent_base_set , .Nm bufferevent_new , .Nm bufferevent_free , .Nm bufferevent_write , @@ -65,9 +68,6 @@ .Nm bufferevent_enable , .Nm bufferevent_disable , .Nm bufferevent_settimeout , -.Nm bufferevent_base_set , -.Nm event_asr_run , -.Nm event_asr_abort .Nd execute a function when a specific event occurs .Sh SYNOPSIS .In sys/time.h @@ -76,64 +76,70 @@ .Fn "event_init" "void" .Ft int .Fn "event_dispatch" "void" -.Ft int -.Fn "event_loop" "int flags" -.Ft int -.Fn "event_loopexit" "struct timeval *tv" -.Ft int -.Fn "event_loopbreak" "void" .Ft void .Fn "event_set" "struct event *ev" "int fd" "short event" "void (*fn)(int, short, void *)" "void *arg" .Ft int -.Fn "event_base_dispatch" "struct event_base *base" -.Ft int -.Fn "event_base_loop" "struct event_base *base" "int flags" -.Ft int -.Fn "event_base_loopexit" "struct event_base *base" "struct timeval *tv" -.Ft int -.Fn "event_base_loopbreak" "struct event_base *base" -.Ft int -.Fn "event_base_set" "struct event_base *base" "struct event *" -.Ft void -.Fn "event_base_free" "struct event_base *base" -.Ft int -.Fn "event_add" "struct event *ev" "struct timeval *tv" +.Fn "event_add" "struct event *ev" "const struct timev
splassert: rtrequest1: want 5 have 0
Hi, I'm setting up a new pair of firewalls, running -current. When I bring up the carp0 interface, I get (running with kern.splassert=2): Feb 18 12:09:59 castor /bsd: splassert: rtrequest1: want 5 have 0 Feb 18 12:09:59 castor /bsd: Starting stack trace... Feb 18 12:09:59 castor /bsd: splassert_check() at splassert_check+0x78 Feb 18 12:09:59 castor /bsd: rtrequest1() at rtrequest1+0x5e Feb 18 12:09:59 castor /bsd: nd6_prefix_offlink() at nd6_prefix_offlink+0x1bf Feb 18 12:09:59 castor /bsd: pfxlist_onlink_check() at pfxlist_onlink_check+0x25e Feb 18 12:09:59 castor /bsd: in6_control() at in6_control+0x894 Feb 18 12:09:59 castor /bsd: ifioctl() at ifioctl+0x175 Feb 18 12:09:59 castor /bsd: sys_ioctl() at sys_ioctl+0x169 Feb 18 12:09:59 castor /bsd: syscall() at syscall+0x297 Feb 18 12:09:59 castor /bsd: --- syscall (number 54) --- Feb 18 12:09:59 castor /bsd: end of kernel Feb 18 12:09:59 castor /bsd: end trace frame: 0xc8115948400, count: 249 Feb 18 12:09:59 castor /bsd: 0xc8115715cda: Feb 18 12:09:59 castor /bsd: End of stack trace. Feb 18 12:10:00 castor /bsd: carp0: state transition: BACKUP -> MASTER I do have an IPv6 address configured on carp0: castor$ cat /etc/hostname.carp0 vhid 100 carpdev em0 pass suppressed0 inet 140.93.56.3 255.255.248.0 inet6 2001:660:6602:13::3 64 OpenBSD 5.7-beta (GENERIC.MP) #3: Tue Feb 17 11:03:09 CET 2015 matthieu@castor:/share/OpenBSD/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17115840512 (16322MB) avail mem = 16656306176 (15884MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (77 entries) bios0: vendor Dell Inc. version "2.3.3" date 07/10/2014 bios0: Dell Inc. PowerEdge R420 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT EINJ TCPA PC__ SRAT SSDT acpi0: wakeup devices PCI0(S5) EHC1(S3) EHC2(S3) PCI1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.34 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 1 pa 0xfec3f000, version 20, 24 pins ioapic1: misconfigured as apic 15, remapped to apid 1 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX1) acpiprt2 at acpi0: bus -1 (PEX2) acpiprt3 at acpi0: bus 8 (PEX3) acpiprt4 at acpi0: bus -1 (PEX4) acpiprt5 at acpi0: bus -1 (PEX5) acpiprt6 at acpi0: bus 10 (PEX6) acpiprt7 at acpi0: bus 2 (PEX7) acpiprt8 at acpi0: bus -1 (PEX8) acpiprt9 at acpi0: bus 3 (PEX9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel E5 v2 Host" rev 0x04 ppb0 at pci0 dev 1 function 0 "Intel E5 v2 PCIE" rev 0x04 pci1 at ppb0 bus 1 mfi0 at
Re: ksh version lies
On 2015/02/17 21:06, John Merriam wrote: > 2) Remove it completely as proposed by tedu. Some things in ports (like autoconf) check for the existence of KSH_VERSION. The only thing I've noticed so far that checks for "PD KSH" in the contents of KSH_VERSION is ksh.kshrc in base.
Re: ksh version lies
On 2015-02-17, "Ted Unangst" wrote: >> pdksh is not the same thing as ksh88 or ksh93. And not the same thing as >> mksh, which has grew features since it was based on pdksh from the >> OpenBSD tree. And you may want to avoid known problems in some of those, >> or use known nice features in others, whether it is in scripts or your >> dotfiles. > > I'm asking specifically what those features are. Start with src/bin/ksh/NOTES. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: stop deleting /usr/include/openssl
On 2015-02-16, Jérémie Courrèges-Anglas wrote:
>> -@ln -sf openssl ${DESTDIR}/usr/include/ssl
>
> Not ok for this part...
I now have
lrwxr-xr-x 1 root bin 7 Feb 17 15:32 /usr/include/openssl/openssl -> openssl
on updated systems.
/usr/include/openssl/blowfish.h:62:33: error:
/usr/include/openssl/openssl/opensslconf.h: Too many levels of symbolic links
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: stop deleting /usr/include/openssl
On 2015/02/18 12:20, Christian Weisgerber wrote:
> On 2015-02-16, Jérémie Courrèges-Anglas wrote:
>
> >> - @ln -sf openssl ${DESTDIR}/usr/include/ssl
> >
> > Not ok for this part...
>
> I now have
>
> lrwxr-xr-x 1 root bin 7 Feb 17 15:32 /usr/include/openssl/openssl ->
> openssl
>
> on updated systems.
>
> /usr/include/openssl/blowfish.h:62:33: error:
> /usr/include/openssl/openssl/opensslconf.h: Too many levels of symbolic links
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
This should fix it..
Index: Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.199
diff -u -p -r1.199 Makefile
--- Makefile16 Feb 2015 14:06:15 - 1.199
+++ Makefile18 Feb 2015 12:54:31 -
@@ -89,7 +89,7 @@ includes:
${INSTALL} ${INSTALL_COPY} -m 444 $$j
${DESTDIR}/usr/include/$$i/$$j; \
done; \
done
- @ln -sf openssl ${DESTDIR}/usr/include/ssl
+ @ln -sfh openssl ${DESTDIR}/usr/include/ssl
@echo installing ${LFILES}
@for i in ${LFILES}; do \
rm -f ${DESTDIR}/usr/include/$$i && \
Re: ksh version lies
On Tue, 17 Feb 2015, Adam Thompson wrote: > On 2015-02-17 08:06 PM, John Merriam wrote: > > I definitely agree that the silliness of checking a version string to > > possibly use some exotic or non-standard feature of a particular flavor of a > > particular family of shells is not a good idea when writing a shell script. > > If you can't do what you want without relying on that particular feature > > then maybe what you're writing shouldn't be a shell script. If it's a bug > > in a particular flavor of a shell, then instead of checking for and working > > around it, report the bug to the author/maintainer. > > Jumping in late in the conversation... > > This is not an academic point; as an ISV, I've had to do this sort of thing in > the past, and will have to do so again in the future. > > There is no "standard" or universal way to detect what version of what shell > happened to get invoked on what operating system, so an ISV must rely on > tricks and silliness like checking the version string to make what amounts to > an educated guess. > For example, I have a customer that must run a specific (non-current) version > of HP-UX due to hard dependencies in a mission-critical line-of-business app. > Yes, that means there's a foundational problem, but it would cost ~$100M to > fix now. Not going to happen. > "Report the bug to the author/maintainer" is all very well, but HP isn't going > to issue a patch for an old version of HP-UX just because one customer > complains about /bin/ksh behaving badly. (Actually, they very well might, > given sufficient financial incentive, but that's another story altogether...) > > Meanwhile, portable shell scripts must continue to run - portably - across > multiple OSes. > > Array handling is the big bugbear I run into; if I can handle arrays inside > the shell, I don't have to resort to using tmpfiles and fork/exec'ing multiple > external utilities to simulate the functionality. Which means, firstly, > determining if I'm inside something ksh-like or bash-like, or if I'm running > in a simple POSIX shell. There are virtually no safe assumptions that can be > made in portable shell scripting - how was the script invoked? Sourced? > Hash-bang? Explicit "/bin/sh script" invocation? > > It's a mess, despite POSIX' attempt to unify things; the choice is to either > code for lowest-common-denominator, which typically results in payloads up to > 10x larger and that run up to 10x slower, or to probe for advanced features > and exit cleanly and safely if they're absent. I definitely hear what you're saying. I also have seen issues dealing with arrays in shell scripts. What I do when I want an array in a shell script is to either switch to Perl5 or some other language, or insist that the shell be Bash. Say what you want about Bash but I have found it to be relatively consistent and available on many platforms. I would guess that option 5 in my original post in this thread (a version string with no version numbers with or without PD KSH in it) would probably keep the majority of shell script writers happy (especially if it does have PD KSH in it) and would involve no maintenance down the line. But maybe that's not the case. Are there large numbers of scripts keying off the version numbers out there? -- John Merriam
Re: stop deleting /usr/include/openssl
Stuart Henderson writes:
> On 2015/02/18 12:20, Christian Weisgerber wrote:
>> On 2015-02-16, Jérémie Courrèges-Anglas wrote:
>>
>> >> - @ln -sf openssl ${DESTDIR}/usr/include/ssl
>> >
>> > Not ok for this part...
>>
>> I now have
>>
>> lrwxr-xr-x 1 root bin 7 Feb 17 15:32 /usr/include/openssl/openssl ->
>> openssl
>>
>> on updated systems.
>>
>> /usr/include/openssl/blowfish.h:62:33: error:
>> /usr/include/openssl/openssl/opensslconf.h: Too many levels of symbolic links
>>
>> --
>> Christian "naddy" Weisgerber na...@mips.inka.de
>>
>
> This should fix it..
Yup. ok jca@
Should we also add
@rm -f ${DESTDIR}/usr/include/openssl/openssl
now that this erroneous symlink has been created? It seems like naddy
has encountered a build error due to this.
> Index: Makefile
> ===
> RCS file: /cvs/src/include/Makefile,v
> retrieving revision 1.199
> diff -u -p -r1.199 Makefile
> --- Makefile 16 Feb 2015 14:06:15 - 1.199
> +++ Makefile 18 Feb 2015 12:54:31 -
> @@ -89,7 +89,7 @@ includes:
> ${INSTALL} ${INSTALL_COPY} -m 444 $$j
> ${DESTDIR}/usr/include/$$i/$$j; \
> done; \
> done
> - @ln -sf openssl ${DESTDIR}/usr/include/ssl
> + @ln -sfh openssl ${DESTDIR}/usr/include/ssl
> @echo installing ${LFILES}
> @for i in ${LFILES}; do \
> rm -f ${DESTDIR}/usr/include/$$i && \
>
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: stop deleting /usr/include/openssl
On 2015/02/18 16:21, Jérémie Courrèges-Anglas wrote:
> Should we also add
>
> @rm -f ${DESTDIR}/usr/include/openssl/openssl
>
> now that this erroneous symlink has been created? It seems like naddy
> has encountered a build error due to this.
Since it's only affected builds from source in a short window, I think it's
probably better not to do this.
Re: stop deleting /usr/include/openssl
Jérémie Courrèges-Anglas wrote:
> Stuart Henderson writes:
>
> > On 2015/02/18 12:20, Christian Weisgerber wrote:
> >> On 2015-02-16, Jérémie Courrèges-Anglas wrote:
> >>
> >> >> - @ln -sf openssl ${DESTDIR}/usr/include/ssl
> >> >
> >> > Not ok for this part...
> >>
> >> I now have
> >>
> >> lrwxr-xr-x 1 root bin 7 Feb 17 15:32 /usr/include/openssl/openssl ->
> >> openssl
> >>
> >> on updated systems.
> >>
> >> /usr/include/openssl/blowfish.h:62:33: error:
> >> /usr/include/openssl/openssl/opensslconf.h: Too many levels of symbolic
> >> links
> >>
> >> --
> >> Christian "naddy" Weisgerber na...@mips.inka.de
> >>
> >
> > This should fix it..
>
> Yup. ok jca@
oops.
>
> Should we also add
>
> @rm -f ${DESTDIR}/usr/include/openssl/openssl
>
> now that this erroneous symlink has been created? It seems like naddy
> has encountered a build error due to this.
I don't think so. That's how we got here in the first place. This isn't the
file to be correcting mistakes. People who built during the window should
remove the symlink by hand.
Re: ksh version lies
Le 17/02/2015 23:23, Ted Unangst a écrit :
> Jérémie Courrèges-Anglas wrote:
>> Tristan Le Guern writes:
>>
>>> On 02/16/2015 05:22 PM, Todd C. Miller wrote:
There are scripts that use KSH_VERSION to determine whether they
are being run under ksh or a Bourne shell. That seems like a
reasonable thing to do. I don't really care what the version
number is set to. Using the OpenBSD version seems reasonable
and could be generated at build time.
>>>
>>> Same thing for me: I don't care about the content of this variable, just
>>> about its presence. The same for BASH_VERSION or ZSH_VERSION.
>>
>> Maybe you don't, but our ksh isn't the only ksh around.
>>
>> Removing "PD KSH" from KSH_VERSION would just break scripts that probe
>> the content of this variable.
>
> So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What does
> one do differently if that string is present or missing?
There is some features used in a lot of scripts that doesn't behave the
same way with the various ksh derivatives and which can be detected with
the presence of the variable KSH_VERSION and its content.
pdksh doesn't work well with arrays, it cannot allocate more than a few
hundred cells, so I guess some scripts might check for that. OpenBSD ksh
and mksh handle thousands of cells without (too much) problem.
OpenBSD ksh, mksh and pdksh do not implement substring expansion like
"echo ${foobar:0:5}", while ksh88 and ksh93 do.
It is possible to declare arrays with "set -A -- foo value1 value2 ..."
with ksh but it is not possible, or not this way, with various other shells.
increase worm difficulty
I have a jumbo terminal. worm(6) is cheese for approximately the first hour of
play because the worm's growth is imperceptible compared to the available
space. In theory, I could increase the start length, but that's kind of
degenerate. worm 1000 leaves you with this giant pile of worm stretching back
and forth across the terminal. Eating a pellet on the bottom of the screen
isn't an exercise in strategy, but it is rather boring to wrap the whole worm
up in one corner to make an opening.
Solution: scale the worm's growth by the terminal size. The break point of
1000 means that growthscale is still 1 for an 80x24 terminal, but 2 for an
80x25 terminal.
Side effect: score doesn't get incremented again for eating a second pellet
while still growing. This seems unintentional; there's little skill involved
so I don't think it should result in a bonus.
Index: worm.c
===
RCS file: /cvs/src/games/worm/worm.c,v
retrieving revision 1.27
diff -u -p -r1.27 worm.c
--- worm.c 3 Nov 2014 22:14:54 - 1.27
+++ worm.c 18 Feb 2015 22:50:07 -
@@ -60,6 +60,7 @@ struct body {
struct body *next;
} *head, *tail, goody;
int growing = 0;
+int growthscale = 1;
int running = 0;
int slow = 0;
int score = 0;
@@ -106,6 +107,8 @@ main(int argc, char **argv)
endwin();
errx(1, "screen too small");
}
+ if (COLS * LINES > 1000)
+ growthscale = COLS * LINES / 1000;
if (argc >= 2) {
start_len = strtonum(argv[1], 1, ((LINES-3) * (COLS-2)) / 3,
&errstr);
@@ -301,9 +304,10 @@ process(int ch)
wmove(tv, y, x);
if (isdigit(ch = winch(tv)))
{
- growing += ch-'0';
+ int amt = ch - '0';
+ growing += amt * growthscale;
prize();
- score += growing;
+ score += amt;
running = 0;
wmove(stw, 0, COLS - 12);
wprintw(stw, "Score: %3d", score);
httpd.conf.5 return code typo
Thank you for the new 'block' functionality. Index: httpd.conf.5 === RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v retrieving revision 1.51 diff -u -p -r1.51 httpd.conf.5 --- httpd.conf.515 Feb 2015 13:43:32 - 1.51 +++ httpd.conf.518 Feb 2015 23:38:27 - @@ -157,7 +157,7 @@ Close the connection and send an error p If the optional return code is not specified, .Xr httpd 8 denies access with a -.Sq 404 Forbidden +.Sq 403 Forbidden response. The optional .Ar uri
Re: re(4) reads the pci-e max packet size wrongly
On Wed, Feb 18, 2015 at 11:23:15AM +1000, David Gwynne wrote:
> it looks like it reads the DCSR register and then keeps everything
> except the MPS field.
>
> this might cause it to erronously consider the mps to be much bigger
> than 2048, which in turn could prevent it from setting it correctly.
>
> i dont actually have one of these chips. can someone give it a spin?
nothing broke on my 8168D and 8168E running -current with this, for
what it's worth.
> Index: if_re_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 if_re_pci.c
> --- if_re_pci.c 26 Jan 2015 09:58:47 - 1.45
> +++ if_re_pci.c 18 Feb 2015 01:12:22 -
> @@ -182,7 +182,7 @@ re_pci_attach(struct device *parent, str
> /* Set PCIe maximum read request size to 2048. */
> reg = pci_conf_read(pa->pa_pc, pa->pa_tag,
> sc->rl_expcap + PCI_PCIE_DCSR);
> - reg = (reg & ~PCI_PCIE_DCSR_MPS);
> + reg &= PCI_PCIE_DCSR_MPS;
> reg >>= 12;
> rrs = (1 << (reg + 7));
> if (rrs < 2048) {
>
Re: [PATCH] ukbd.c cleanup and mba iso support
Hey,
Any interest?
Thanks,
William Orr
On 2/4/15 9:37 AM, William Orr wrote:
> Hey,
>
> This implements some of Alexey's comments as well as munging the grave key for
> macbook airs. Tested on a mba with a WELLSPRING ANSI keyboard.
>
> Thanks,
> William Orr
>
> Index: sys/dev/usb/ukbd.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
> retrieving revision 1.70
> diff -u -b -w -p -r1.70 ukbd.c
> --- sys/dev/usb/ukbd.c19 Jan 2015 20:16:10 - 1.70
> +++ sys/dev/usb/ukbd.c4 Feb 2015 05:18:47 -
> @@ -182,6 +182,11 @@ void ukbd_gdium_munge(void *, uint8_t *,
> void ukbd_apple_munge(void *, uint8_t *, u_int);
> void ukbd_apple_mba_munge(void *, uint8_t *, u_int);
> void ukbd_apple_iso_munge(void *, uint8_t *, u_int);
> +void ukbd_apple_iso_mba_munge(void *, uint8_t *, u_int);
> +
> +void ukbd_apple_translate(void *, uint8_t *, u_int,
> + const struct ukbd_translation *, u_int);
> +
> uint8_t ukbd_translate(const struct ukbd_translation *, size_t,
> uint8_t);
>
> int
> @@ -244,14 +249,16 @@ ukbd_attach(struct device *parent, struc
> case USB_PRODUCT_APPLE_GEYSER_ISO:
> sc->sc_munge = ukbd_apple_iso_munge;
> break;
> - case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
> case USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
> + case USB_PRODUCT_APPLE_WELLSPRING4_ISO:
> + case USB_PRODUCT_APPLE_WELLSPRING_ISO:
> + sc->sc_munge = ukbd_apple_iso_mba_munge;
> + break;
> + case USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
> case USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
> case USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
> - case USB_PRODUCT_APPLE_WELLSPRING4_ISO:
> case USB_PRODUCT_APPLE_WELLSPRING4_JIS:
> case USB_PRODUCT_APPLE_WELLSPRING_ANSI:
> - case USB_PRODUCT_APPLE_WELLSPRING_ISO:
> case USB_PRODUCT_APPLE_WELLSPRING_JIS:
> sc->sc_munge = ukbd_apple_mba_munge;
> break;
> @@ -461,12 +468,28 @@ ukbd_translate(const struct ukbd_transla
> }
>
> void
> -ukbd_apple_munge(void *vsc, uint8_t *ibuf, u_int ilen)
> +ukbd_apple_translate(void *vsc, uint8_t *ibuf, u_int ilen,
> +const struct ukbd_translation* trans, u_int tlen)
> {
> struct ukbd_softc *sc = vsc;
> struct hidkbd *kbd = &sc->sc_kbd;
> uint8_t *pos, *spos, *epos, xlat;
>
> + spos = ibuf + kbd->sc_keycodeloc.pos / 8;
> + epos = spos + kbd->sc_nkeycode;
> +
> + for (pos = spos; pos != epos; pos++) {
> + xlat = ukbd_translate(trans, tlen, *pos);
> + if (xlat != 0)
> + *pos = xlat;
> + }
> +}
> +
> +void
> +ukbd_apple_munge(void *vsc, uint8_t *ibuf, u_int ilen)
> +{
> + struct ukbd_softc *sc = vsc;
> +
> static const struct ukbd_translation apple_fn_trans[] = {
> { 40, 73 }, /* return -> insert */
> { 42, 76 }, /* backspace -> delete */
> @@ -499,23 +522,14 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
> if (!hid_get_data(ibuf, ilen, &sc->sc_apple_fn))
> return;
>
> - spos = ibuf + kbd->sc_keycodeloc.pos / 8;
> - epos = spos + kbd->sc_nkeycode;
> -
> - for (pos = spos; pos != epos; pos++) {
> - xlat = ukbd_translate(apple_fn_trans,
> - nitems(apple_fn_trans), *pos);
> - if (xlat != 0)
> - *pos = xlat;
> - }
> + ukbd_apple_translate(vsc, ibuf, ilen, apple_fn_trans,
> + nitems(apple_fn_trans));
> }
>
> void
> ukbd_apple_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
> {
> struct ukbd_softc *sc = vsc;
> - struct hidkbd *kbd = &sc->sc_kbd;
> - uint8_t *pos, *spos, *epos, xlat;
>
> static const struct ukbd_translation apple_fn_trans[] = {
> { 40, 73 }, /* return -> insert */
> @@ -545,40 +559,34 @@ ukbd_apple_mba_munge(void *vsc, uint8_t
> if (!hid_get_data(ibuf, ilen, &sc->sc_apple_fn))
> return;
>
> - spos = ibuf + kbd->sc_keycodeloc.pos / 8;
> - epos = spos + kbd->sc_nkeycode;
> -
> - for (pos = spos; pos != epos; pos++) {
> - xlat = ukbd_translate(apple_fn_trans,
> - nitems(apple_fn_trans), *pos);
> - if (xlat != 0)
> - *pos = xlat;
> - }
> + ukbd_apple_translate(vsc, ibuf, ilen, apple_fn_trans,
> + nitems(apple_fn_trans));
> }
>
> void
> ukbd_apple_is
Re: splassert: rtrequest1: want 5 have 0
On Wed, Feb 18, 2015 at 12:14:15PM +0100, Matthieu Herrb wrote: > Hi, > > I'm setting up a new pair of firewalls, running -current. When I bring > up the carp0 interface, I get (running with kern.splassert=2): > > Feb 18 12:09:59 castor /bsd: splassert: rtrequest1: want 5 have 0 > Feb 18 12:09:59 castor /bsd: Starting stack trace... > Feb 18 12:09:59 castor /bsd: splassert_check() at splassert_check+0x78 > Feb 18 12:09:59 castor /bsd: rtrequest1() at rtrequest1+0x5e > Feb 18 12:09:59 castor /bsd: nd6_prefix_offlink() at > nd6_prefix_offlink+0x1bf > Feb 18 12:09:59 castor /bsd: pfxlist_onlink_check() at > pfxlist_onlink_check+0x25e > Feb 18 12:09:59 castor /bsd: in6_control() at in6_control+0x894 > Feb 18 12:09:59 castor /bsd: ifioctl() at ifioctl+0x175 > Feb 18 12:09:59 castor /bsd: sys_ioctl() at sys_ioctl+0x169 > Feb 18 12:09:59 castor /bsd: syscall() at syscall+0x297 > Feb 18 12:09:59 castor /bsd: --- syscall (number 54) --- > Feb 18 12:09:59 castor /bsd: end of kernel > Feb 18 12:09:59 castor /bsd: end trace frame: 0xc8115948400, count: > 249 > Feb 18 12:09:59 castor /bsd: 0xc8115715cda: > Feb 18 12:09:59 castor /bsd: End of stack trace. > Feb 18 12:10:00 castor /bsd: carp0: state transition: BACKUP -> > MASTER I notided that only one rtrequest1() call in nd6_rtr.c is protected by splsoftnet()/splx() explicitely. Should I add that to the call in nd6_prefix_offlink (and maybe the others too) ? > > I do have an IPv6 address configured on carp0: > > castor$ cat /etc/hostname.carp0 > vhid 100 carpdev em0 pass suppressed0 > inet 140.93.56.3 255.255.248.0 > inet6 2001:660:6602:13::3 64 > > OpenBSD 5.7-beta (GENERIC.MP) #3: Tue Feb 17 11:03:09 CET 2015 > matthieu@castor:/share/OpenBSD/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17115840512 (16322MB) > avail mem = 16656306176 (15884MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (77 entries) > bios0: vendor Dell Inc. version "2.3.3" date 07/10/2014 > bios0: Dell Inc. PowerEdge R420 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT > EINJ TCPA PC__ SRAT SSDT > acpi0: wakeup devices PCI0(S5) EHC1(S3) EHC2(S3) PCI1(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.34 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2400.01 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins > ioapic1 at mainbus0: apid 1 pa 0xfec3f000, version 20, 24 pins > ioapic1: misconfigured as apic 15, remapped to apid 1 > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (PEX1) > acpiprt2 at acpi0: bus -1 (PEX2) > acpiprt3 at acpi0: bus 8 (PEX3) > acpiprt4 at acpi0: bus -1 (PEX4) > acpipr
fusefs_readdir() should set eofflag
fuse_readdir() fails to set the eofflag correctly. The consequence of
this is, that callers of VOP_READDIR, that examine the value of the
eofflag after the call, might be mislead about the eof status, as the
flag hasn't been modified (and my even be uninitialized).
The manual page for VOP_READDIR() mentions, that the eofflag is set to a
non-zero value when the eof of the directory contents has (successfully)
been reached, but in the following diff I chose to also in addition set
the flag to 0 when eof has not been reached for uniformity with other
filesystem implementations.
Index: miscfs/fuse/fuse_vnops.c
===
RCS file: /cvs/src/sys/miscfs/fuse/fuse_vnops.c,v
retrieving revision 1.22
diff -u -r1.22 fuse_vnops.c
--- miscfs/fuse/fuse_vnops.c10 Feb 2015 21:56:10 - 1.22
+++ miscfs/fuse/fuse_vnops.c12 Feb 2015 20:48:06 -
@@ -686,7 +686,7 @@
struct vnode *vp;
struct proc *p;
struct uio *uio;
- int error = 0;
+ int error = 0, eofflag = 0;
vp = ap->a_vp;
uio = ap->a_uio;
@@ -720,8 +720,9 @@
break;
}
- /*ack end of readdir */
+ /* ack end of readdir */
if (fbuf->fb_len == 0) {
+ eofflag = 1;
fb_delete(fbuf);
break;
}
@@ -733,6 +734,9 @@
fb_delete(fbuf);
}
+
+ if (!error && ap->a_eofflag != NULL)
+ *ap->a_eofflag = eofflag;
return (error);
}
cheers,
natano
