Re: another ancient bug in head(1)
> Index: head.c
> ===
> RCS file: /cvs/src/usr.bin/head/head.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 head.c
> --- head.c7 Oct 2014 19:38:57 - 1.17
> +++ head.c7 Oct 2014 21:16:43 -
> @@ -48,6 +48,7 @@ static void usage(void);
> int
> main(int argc, char *argv[])
> {
> + FILE*fp;
> longcnt;
> int ch, firsttime;
> longlinecnt = 10;
> @@ -81,13 +82,13 @@ main(int argc, char *argv[])
> errx(1, "line count %s: %s", errstr, p);
> }
>
> - /* setlinebuf(stdout); */
> for (firsttime = 1; ; firsttime = 0) {
> if (!*argv) {
> if (!firsttime)
> exit(status);
> + fp = stdin;
> } else {
> - if (!freopen(*argv, "r", stdin)) {
> + if ((fp = fopen(*argv, "r")) == NULL) {
> warn("%s", *argv++);
> status = 1;
> continue;
> @@ -99,10 +100,11 @@ main(int argc, char *argv[])
> }
> ++argv;
> }
> - for (cnt = linecnt; cnt && !feof(stdin); --cnt)
> - while ((ch = getchar()) != EOF)
> + for (cnt = linecnt; cnt && !feof(fp); --cnt)
> + while ((ch = getc(fp)) != EOF)
> if (putchar(ch) == '\n')
> break;
> + fclose(fp);
> }
> /*NOTREACHED*/
> }
>
Nice fix! Seems correct to me.
cheers,
natano
Re: pppoe(4), add example for ipv6
On 07/10/14 10:03 PM, Stuart Henderson wrote: Since it's non-obvious how to setup pppoe for v6 now that link-local addresses are no longer configured by default, I think we should have something in the manual. Any comments/objections/suggestions for a better way to do this? This doesn't make any sense. IPv6CP configures the link local address. Having to do something like this is illogical and counter intuitive. I agree it should be documented per se but the current behavior is just plain stupid. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: armv7: banana pi, Allwinner A20 board
Hi, here is the log using bsd.SUNXI.umg instead of bsd.rd.SUNXI.img. (thanks to Theo) "-c" invokes UKC, but hangs up at there. -- OpenBSD/sunxi booting ... arg0 0x0 arg1 0x10bb arg2 0x4100 atag core flags 0 pagesize 0 rootdev 0 atag cmdline [sd0i:/bsd -c] atag mem start 0x4000 size 0x4000 bootfile: sd0i:/bsd bootargs: -c memory size derived from u-boot bootconf.mem[0].address = 4000 pages 262144/0x4000 Allocating page tables freestart = 0x40b9a000, free_pages = 259174 (0x0003f466) IRQ stack: p0x40bc8000 v0xc0bc8000 ABT stack: p0x40bc9000 v0xc0bc9000 UND stack: p0x40bca000 v0xc0bca000 SVC stack: p0x40bcb000 v0xc0bcb000 Creating L1 page table at 0x40b9c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 300196 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org User Kernel Config UKC> -- SASANO Takayoshi
pppoe(4), add example for ipv6
Since it's non-obvious how to setup pppoe for v6 now that link-local addresses are no longer configured by default, I think we should have something in the manual. Any comments/objections/suggestions for a better way to do this? Index: man4/pppoe.4 === RCS file: /cvs/src/share/man/man4/pppoe.4,v retrieving revision 1.26 diff -u -p -r1.26 pppoe.4 --- man4/pppoe.417 Mar 2014 21:55:05 - 1.26 +++ man4/pppoe.48 Oct 2014 02:01:14 - @@ -87,6 +87,8 @@ Configure authentication. The PPP session needs to identify the client to the peer. For more details on the available options see .Xr ifconfig 8 . +.It +If using IPv6, configure a link-local address. .El .Pp This all is typically accomplished using an @@ -94,11 +96,13 @@ This all is typically accomplished using file. A typical file looks like this: .Bd -literal -offset indent +inet6 eui64 inet 0.0.0.0 255.255.255.255 NONE \e pppoedev em0 authproto pap \e authname 'testcaller' authkey 'donttell' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 +!/sbin/route add default -ifp pppoe0 fe80:: .Ed .Pp The physical interface must also be marked
Re: my screen is too big
On 2014/10/08 10:49, David Gwynne wrote: > vi gets upset if i maximise my terminal window. it might need to > go even bigger for 4k displays. > > ok? ok with me, tested by setting xterm's font to "tiny" and making the window twice as wide as my monitor.
my screen is too big
vi gets upset if i maximise my terminal window. it might need to
go even bigger for 4k displays.
ok?
Index: common/options_f.c
===
RCS file: /cvs/src/usr.bin/vi/common/options_f.c,v
retrieving revision 1.7
diff -u -p -r1.7 options_f.c
--- common/options_f.c 27 Oct 2009 23:59:47 - 1.7
+++ common/options_f.c 8 Oct 2014 00:48:09 -
@@ -66,7 +66,7 @@ f_columns(sp, op, str, valp)
* number of lines/columns for the screen, but at least we don't drop
* core.
*/
-#defineMAXIMUM_SCREEN_COLS 500
+#defineMAXIMUM_SCREEN_COLS 768
if (*valp > MAXIMUM_SCREEN_COLS) {
msgq(sp, M_ERR, "041|Screen columns too large, greater than %d",
MAXIMUM_SCREEN_COLS);
Re: improving OpenBSD's gmac.c...
Christian Weisgerber wrote this message on Tue, Oct 07, 2014 at 23:08 +0200: > John-Mark Gurney: > > > So, as I was working on FreeBSD's implementation of gmac.c, I noticed > > that I was able to get a significant speed up by using a mask instead > > of an if branch in ghash_gfmul in gmac.c from OpenBSD... > > > > Add a mask var and replace the code between the comments > > "update Z" and "update V" w/: > > mask = !!(x[i >> 3] & (1 << (~i & 7))); > > mask = ~(mask - 1); > > > > z[0] ^= v[0] & mask; > > z[1] ^= v[1] & mask; > > z[2] ^= v[2] & mask; > > z[3] ^= v[3] & mask; > > > > And you should see a nice performance increase... > > I tried this on a Soekris net6501-50 and the performance increase > was around 1.3%. (I set up an ESP transport association with > AES-128-GMAC and pushed UDP traffic with tcpbench over it.) Yeh, I benchmarked the raw algo in userland, not part of IPsec. I forget the resulting perf increase, but it was well more than 10-20%. > A look at the generated amd64 assembly code shows that the change > indeed removes a branch. What's pretty shocking is that this code > > mul = v[3] & 1; > ... > v[0] = (v[0] >> 1) ^ (0xe100 * mul); > > is turned into an actual imul instruction by GCC. I used the same > masking approach to get rid of the multiplication, but the improvement > was minuscule (<1%). Hmm. interesting... In my code I switched both to using the and operator... I also have code which switches the registers to 64bits so that on amd64, we make better uses of registers, and on i386, the compilers are good at breaking down the 64bit registers to 32bit w/o extra work... > > I also have an implementation of ghash that does a 4 bit lookup table > > version with the table split between cache lines in p4 at: > > https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.c&REV=4 > > I'll have to look at this, but haven't there been increasing > misgivings about table implementations for GHASH because of timing > attacks? Well, the code avoids one issue but introduces another issue... Each table lookup accesses all four lines (assuming 64 byte cache lines), so there isn't a problem there... The issue intrroduded is that the first 64 bits of a cache line are faster to access than the remaining bits... For more info, look at the NSS bug: https://bugzilla.mozilla.org/show_bug.cgi?id=868948 Though considering that the AES implementation that FreeBSD is still using is the standard table based AES, there are also timing issues there too... Yes, no excuse for opening up additional windows... I have thought about introducing an option of slow but secure and fast but insecure against local attackers... Since we are already on the fast but insecure against local attackers path, I figured I'll take the extra performance... As with all things, there is a trade off between speed and security... As most IPsec gateways don't have a local user trying to target the key, this is less of an issue... And even if they did, it'd probably be easier to use a local root exploit to get the key than try to mount a timing attack to extract a key that might change in an hour or a day... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Re: re(4) mtu >1500
I like MIMO/SISO better than 1x1 2x2 etc. Fix that shit :) Stuart Henderson [st...@openbsd.org] wrote: > On 2014/10/06 12:19, Chris Cappuccio wrote: > > Stuart Henderson [s...@spacehopper.org] wrote: > > > Does anyone have an idea of what's needed for working jumbos on the > > > RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled? > > > These seem to account for most of the chips seen in hardware > > > designs from the last couple of years (including APU and some others). > > > > > > if ((sc->rl_flags & RL_FLAG_JUMBOV2) == 0) > > > ifp->if_hardmtu = sc->rl_max_mtu; > > > > > > > I think the secrets are here :) > > > > http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461&view=markup > > > > Ah, more specifically > > http://svnweb.freebsd.org/base?view=revision&revision=217499 / > http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498&r2=217499&pathrev=217499 > > OK that's probably more than I can figure out how to port without > hardware then.. -- The bums will always lose
Re: mg: add bounce matching for [] and {}
It should be noted, You can do that (without a code change) with an
appropriate chunk of code in your ~/.mg file.
(at least, that's how I have always done it)
On Tuesday, October 7, 2014, Stuart Cassoff wrote:
> On 08/13/14 18:51, Brian Callahan wrote:
> > Hi tech --
> >
> > Diff below adds the bounce matching for [] and {} in mg like it does for
> ().
> > I miss having that from GNU Emacs, anyone else?
> >
> > OK?
> >
> > ~Brian
>
> Just noticed this yesterday. Thanks!
>
>
> Stu
>
>
>
another ancient bug in head(1)
Hi,
while we are talking about ancient bugs in head(1), here is another one:
Without the patch:
$ date | head /dev/null /dev/stdin
==> /dev/null <==
==> /dev/stdin <==
$
Oops, where did stdin go? The reopen(3) function doesn't work here,
it first closes stdin, and then it's gone for good.
With the patch:
$ date | ./obj/head /dev/null /dev/stdin
==> /dev/null <==
==> /dev/stdin <==
Tue Oct 7 23:28:21 CEST 2014
$
Actually, it's not me who found and fixed that bug.
Here is the original CSRG SCCS commit message:
^As 9/6/00145
^Ad D 5.7 92/03/04 14:35:42 bostic 9 8
^Ac can't use freopen; example is "date | head file1 /dev/stdin"
So Keith fixed that for 4.4BSD and we neglected to merge his fix
for more than 22 years. Meanwhile, the code diverged slightly,
but my fix follows Keith's as closely as possible.
The tail(1) and cat(1) utilities also avoid the reopen(3) idiom
and use fp = fopen(...).
While here, remove a statement that is commented since November 14,
1987 - that is, for almost 27 years, it was already commented in
4.3BSD Tahoe.
OK?
Ingo
Index: head.c
===
RCS file: /cvs/src/usr.bin/head/head.c,v
retrieving revision 1.17
diff -u -p -r1.17 head.c
--- head.c 7 Oct 2014 19:38:57 - 1.17
+++ head.c 7 Oct 2014 21:16:43 -
@@ -48,6 +48,7 @@ static void usage(void);
int
main(int argc, char *argv[])
{
+ FILE*fp;
longcnt;
int ch, firsttime;
longlinecnt = 10;
@@ -81,13 +82,13 @@ main(int argc, char *argv[])
errx(1, "line count %s: %s", errstr, p);
}
- /* setlinebuf(stdout); */
for (firsttime = 1; ; firsttime = 0) {
if (!*argv) {
if (!firsttime)
exit(status);
+ fp = stdin;
} else {
- if (!freopen(*argv, "r", stdin)) {
+ if ((fp = fopen(*argv, "r")) == NULL) {
warn("%s", *argv++);
status = 1;
continue;
@@ -99,10 +100,11 @@ main(int argc, char *argv[])
}
++argv;
}
- for (cnt = linecnt; cnt && !feof(stdin); --cnt)
- while ((ch = getchar()) != EOF)
+ for (cnt = linecnt; cnt && !feof(fp); --cnt)
+ while ((ch = getc(fp)) != EOF)
if (putchar(ch) == '\n')
break;
+ fclose(fp);
}
/*NOTREACHED*/
}
Re: mpe patch: use rt_ifa_{add,del}
On Sat, Oct 04, 2014 at 07:39:03PM -0300, Rafael Zalamena wrote:
> On Thu, Oct 02, 2014 at 02:36:12PM +0200, Martin Pieuchot wrote:
> > On 01/10/14(Wed) 21:54, Rafael Zalamena wrote:
> > > --- old chat snip ---
>
Code changed:
* Replaced old function that used to create routes in favor of rt_ifa_*
* Modified rt_ifa_{add,del} to handle MPLS addresses: when creating an
route to a MPLS interface it means we want to remove labels. Also MPLS
only works on rdomain 0
Here is the new diff based on mpi@ feedback:
Index: sys/net/if_mpe.c
===
RCS file: /cvs/src/sys/net/if_mpe.c,v
retrieving revision 1.35
diff -u -p -r1.35 if_mpe.c
--- sys/net/if_mpe.c22 Jul 2014 11:06:09 - 1.35
+++ sys/net/if_mpe.c7 Oct 2014 21:24:47 -
@@ -61,7 +61,6 @@ int mpeioctl(struct ifnet *, u_long, cad
void mpestart(struct ifnet *);
intmpe_clone_create(struct if_clone *, int);
intmpe_clone_destroy(struct ifnet *);
-intmpe_newlabel(struct ifnet *, int, struct shim_hdr *);
LIST_HEAD(, mpe_softc) mpeif_list;
struct if_clonempe_cloner =
@@ -280,6 +279,7 @@ mpeioctl(struct ifnet *ifp, u_long cmd,
int error;
struct mpe_softc*ifm;
struct ifreq*ifr;
+ struct sockaddr_mpls smpls;
struct shim_hdr shim;
ifr = (struct ifreq *)data;
@@ -331,12 +331,19 @@ mpeioctl(struct ifnet *ifp, u_long cmd,
if (error)
break;
ifm = ifp->if_softc;
+ memset(&smpls, 0, sizeof(smpls));
+ smpls.smpls_family = AF_MPLS;
+ smpls.smpls_len = sizeof(smpls);
if (ifm->sc_shim.shim_label) {
/* remove old MPLS route */
- mpe_newlabel(ifp, RTM_DELETE, &ifm->sc_shim);
+ smpls.smpls_label = ifm->sc_shim.shim_label;
+ rt_ifa_del(ifp->if_lladdr, RTF_MPLS | RTF_UP,
+ smplstosa(&smpls));
}
/* add new MPLS route */
- error = mpe_newlabel(ifp, RTM_ADD, &shim);
+ smpls.smpls_label = shim.shim_label;
+ error = rt_ifa_add(ifp->if_lladdr, RTF_MPLS | RTF_UP,
+ smplstosa(&smpls));
if (error)
break;
ifm->sc_shim.shim_label = shim.shim_label;
@@ -346,8 +353,12 @@ mpeioctl(struct ifnet *ifp, u_long cmd,
ifm = ifp->if_softc;
if (ifr->ifr_rdomainid != ifp->if_rdomain) {
if (ifm->sc_shim.shim_label) {
- shim.shim_label = ifm->sc_shim.shim_label;
- error = mpe_newlabel(ifp, RTM_ADD, &shim);
+ memset(&smpls, 0, sizeof(smpls));
+ smpls.smpls_label = ifm->sc_shim.shim_label;
+ smpls.smpls_family = AF_MPLS;
+ smpls.smpls_len = sizeof(smpls);
+ error = rt_ifa_add(ifp->if_lladdr,
+ RTF_MPLS | RTF_UP, smplstosa(&smpls));
}
}
/* return with ENOTTY so that the parent handler finishes */
@@ -442,38 +453,3 @@ mpe_input6(struct mbuf *m, struct ifnet
splx(s);
}
#endif /* INET6 */
-
-int
-mpe_newlabel(struct ifnet *ifp, int cmd, struct shim_hdr *shim)
-{
- struct rtentry *nrt;
- struct sockaddr_mpls dst;
- struct rt_addrinfo info;
- int error;
-
- bzero(&dst, sizeof(dst));
- dst.smpls_len = sizeof(dst);
- dst.smpls_family = AF_MPLS;
- dst.smpls_label = shim->shim_label;
-
- bzero(&info, sizeof(info));
- info.rti_flags = RTF_UP | RTF_MPLS;
- info.rti_mpls = MPLS_OP_POP;
- info.rti_info[RTAX_DST] = smplstosa(&dst);
- info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)ifp->if_sadl;
-
- error = rtrequest1(cmd, &info, RTP_CONNECTED, &nrt, 0);
- rt_missmsg(cmd, &info, error ? 0 : nrt->rt_flags, ifp, error, 0);
- if (cmd == RTM_DELETE) {
- if (error == 0 && nrt != NULL) {
- if (nrt->rt_refcnt <= 0) {
- nrt->rt_refcnt++;
- rtfree(nrt);
- }
- }
- }
- if (cmd == RTM_ADD && error == 0 && nrt != NULL) {
- nrt->rt_refcnt--;
- }
- return (error);
-}
Index: sys/net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.185
diff -u -p -r1.185 route.c
--- sys/net/route.c 2 Oct 2014 12:21:20 - 1.185
+++ sys/net/route.c 7 Oct 2014 21:24:47 -
@@ -1100,6 +1100,11 @@ rt_ifa_add(struct ifaddr *ifa, int flags
info.rti
Re: improving OpenBSD's gmac.c...
John-Mark Gurney: > So, as I was working on FreeBSD's implementation of gmac.c, I noticed > that I was able to get a significant speed up by using a mask instead > of an if branch in ghash_gfmul in gmac.c from OpenBSD... > > Add a mask var and replace the code between the comments > "update Z" and "update V" w/: > mask = !!(x[i >> 3] & (1 << (~i & 7))); > mask = ~(mask - 1); > > z[0] ^= v[0] & mask; > z[1] ^= v[1] & mask; > z[2] ^= v[2] & mask; > z[3] ^= v[3] & mask; > > And you should see a nice performance increase... I tried this on a Soekris net6501-50 and the performance increase was around 1.3%. (I set up an ESP transport association with AES-128-GMAC and pushed UDP traffic with tcpbench over it.) A look at the generated amd64 assembly code shows that the change indeed removes a branch. What's pretty shocking is that this code mul = v[3] & 1; ... v[0] = (v[0] >> 1) ^ (0xe100 * mul); is turned into an actual imul instruction by GCC. I used the same masking approach to get rid of the multiplication, but the improvement was minuscule (<1%). > I also have an implementation of ghash that does a 4 bit lookup table > version with the table split between cache lines in p4 at: > https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.c&REV=4 I'll have to look at this, but haven't there been increasing misgivings about table implementations for GHASH because of timing attacks? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: armv7: banana pi, Allwinner A20 board
Hi,
> Did you try disabling ehci to see if that makes a difference?
Curiously, -c option in bootargs seems to be ignored.
I tried it both uEnv.txt and U-Boot console. Here is the log.
There is no problem to pass "-c" string to kernel.
What is happening?
Regards,
U-Boot SPL 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04)
Board: Bananapi
DRAM: 1024 MiB
CPU: 96000Hz, AXI/AHB/APB: 3/2/2
spl: not an uImage at 1600
U-Boot 2014.04-10694-g2ae8b32-dirty (Oct 01 2014 - 17:40:04) Allwinner
Technology
CPU: Allwinner A20 (SUN7I)
Board: Bananapi
I2C: ready
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: dwmac.1c5
Hit any key to stop autoboot: 0
sun7i# setenv bootargs "sd0i:/bsd -c"
sun7i# printenv
autoboot=run loadkernel && run setargs && true && bootm 0x4800
baudrate=115200
boot_ram=saved_stdout=$stdout;setenv stdout nc;if iminfo 0x4100; then true;
setenv stdout $saved_stdout; source 0x4100;else setenv stdout
$saved_stdout;fi
bootargs=sd0i:/bsd -c
bootcmd=if run loadbootenv; then echo Loaded environment from ${bootenv};env
import -t ${scriptaddr} ${filesize};fi;if test -n "${uenvcmd}"; then echo
Running uenvcmd ...;run uenvcmd;fi;if run loadbootscr; then echo Jumping to
${bootscr};source ${scriptaddr};fi;run autoboot;
bootdelay=2
bootenv=uEnv.txt
bootm_size=0x1000
bootscr=boot.scr
console=ttyS0,115200
device=mmc
ethact=dwmac.1c5
ethaddr=02:99:03:c2:d2:6e
kernel=uImage
loadbootenv=fatload $device $partition $scriptaddr ${bootenv} || ext2load
$device $partition $scriptaddr boot/${bootenv} || ext2load $device $partition
$scriptaddr ${bootenv}
loadbootscr=fatload $device $partition $scriptaddr ${bootscr} || ext2load
$device $partition $scriptaddr boot/${bootscr} ||ext2load $device $partition
$scriptaddr ${bootscr}
loadkernel=if bootpath=/boot/ && ext2load $device $partition 0x4300
${bootpath}${script} && ext2load $device $partition 0x4800
${bootpath}${kernel};then true; elif bootpath=/ && fatload $device $partition
0x4300 ${script} && fatload $device $partition 0x4800 ${kernel};then
true; elif bootpath=/ && ext2load $device $partition 0x4300
${bootpath}${script} && ext2load $device $partition 0x4800
${bootpath}${kernel};then true; else false;fi
loglevel=8
panicarg=panic=10
partition=0:1
script=script.bin
scriptaddr=0x4400
setargs=if test -z \\"$root\\"; then if test \\"$bootpath\\" = "/boot/"; then
root="/dev/mmcblk0p1 rootwait"; else root="/dev/mmcblk0p2 rootwait"; fi; fi;
setenv bootargs console=${console} root=${root} loglevel=${loglevel}
${panicarg} ${extraargs}
stderr=serial
stdin=serial
stdout=serial
Environment size: 1943/131068 bytes
sun7i# mmc rescan
sun7i# fatload mmc 0 0x6000 bsd.umg
reading bsd.umg
7386496 bytes read in 364 ms (19.4 MiB/s)
sun7i# bootm 0x6000
## Booting kernel from Legacy Image at 6000 ...
Image Name: boot
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:7386432 Bytes = 7 MiB
Load Address: 4080
Entry Point: 4080
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
OpenBSD/sunxi booting ...
arg0 0x0 arg1 0x10bb arg2 0x4100
atag core flags 0 pagesize 0 rootdev 0
atag cmdline [sd0i:/bsd -c]
atag mem start 0x4000 size 0x4000
bootfile: sd0i:/bsd
bootargs: -c
memory size derived from u-boot
bootconf.mem[0].address = 4000 pages 262144/0x4000
Allocating page tables
freestart = 0x40f0c000, free_pages = 258292 (0x0003f0f4)
IRQ stack: p0x40f3a000 v0xc0f3a000
ABT stack: p0x40f3b000 v0xc0f3b000
UND stack: p0x40f3c000 v0xc0f3c000
SVC stack: p0x40f3d000 v0xc0f3d000
Creating L1 page table at 0x40f0c000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 170664 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org
kernel does not support -c; continuing..
OpenBSD 5.6-current (RAMDISK-SUNXI) #0: Sun Oct 5 13:50:18 AEDT 2014
r...@armv7.jsg.id.au:/usr/src/sys/arch/armv7/compile/RAMDISK-SUNXI
real mem = 1073741824 (1024MB)
avail mem = 1036165120 (988MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cortex0 at mainbus0
ampintc0 at cortex0 nirq 160
cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
sunxi0 at mainbus0: A20
sxipio0 at sunxi0
sxiccmu0 at sunxi0
sxitimer0 at sunxi0: ticktimer 100hz @ 32KHz
sxitimer1 at sunxi0: stattimer 128hz @ 32KHz
sxitimer2 at sunxi0: cntrtimer @ 32KHz
sxidog0 at sunxi0
sxirtc0 at sunxi0
sxiuart0 at sunxi0: console
sxiuart1 at sunxi0
sxiuart2 at sunxi0
sxiuart3 at sunxi0
sxiuart4 at sunxi0
sxiuart5 at sunxi0
sxiuart6 at sunxi0
sxiuart7 at sunxi0
sxie0 at
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:11:28PM +0200, Otto Moerbeek wrote:
> On Tue, Oct 07, 2014 at 02:56:07PM +0200, Fritjof Bornebusch wrote:
>
> > On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote:
> > > On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
> > >
> > > > Fritjof, have you let the gnu rcs project know about the segfault?
> > > > Maybe see how they choose to fix things and then follow their lead?
> > >
> > > That will only slow things down. Do what -L -U does is better, imo.
> > >
> >
> > Otto, so you appreciate a diff more like this one?
>
> well, almost. I think it should be clear one flag and set one, not clear
> all and set one.
>
Here is the new one.
> >
> > > -Otto
> > > >
> > > >
> >
> > fritjof
> >
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.152
diff -u -p -r1.152 rcsprog.c
--- rcsprog.c 2 Oct 2014 06:23:15 - 1.152
+++ rcsprog.c 7 Oct 2014 15:08:39 -
@@ -235,8 +235,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
- /* XXX - Check with -u flag. */
+ if (rcsflags & RCSPROG_UFLAG)
+ warnx("-u overridden by -l");
lrev = rcs_optarg;
+ rcsflags &= ~RCSPROG_UFLAG;
rcsflags |= RCSPROG_LFLAG;
break;
case 'm':
@@ -273,8 +275,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
- /* XXX - Check with -l flag. */
+ if (rcsflags & RCSPROG_LFLAG)
+ warnx("-l overridden by -u");
urev = rcs_optarg;
+ rcsflags &= ~RCSPROG_LFLAG;
rcsflags |= RCSPROG_UFLAG;
break;
case 'V':
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 02:56:07PM +0200, Fritjof Bornebusch wrote:
> On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote:
> > On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
> >
> > > Fritjof, have you let the gnu rcs project know about the segfault?
> > > Maybe see how they choose to fix things and then follow their lead?
> >
> > That will only slow things down. Do what -L -U does is better, imo.
> >
>
> Otto, so you appreciate a diff more like this one?
well, almost. I think it should be clear one flag and set one, not clear
all and set one.
>
> > -Otto
> > >
> > >
>
> fritjof
>
> Index: rcsprog.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
> retrieving revision 1.152
> diff -u -p -r1.152 rcsprog.c
> --- rcsprog.c 2 Oct 2014 06:23:15 - 1.152
> +++ rcsprog.c 7 Oct 2014 12:53:10 -
> @@ -235,9 +235,10 @@ rcs_main(int argc, char **argv)
> lkmode = RCS_LOCK_STRICT;
> break;
> case 'l':
> - /* XXX - Check with -u flag. */
> + if (rcsflags & RCSPROG_UFLAG)
> + warnx("-u overridden by -l");
> lrev = rcs_optarg;
> - rcsflags |= RCSPROG_LFLAG;
> + rcsflags = RCSPROG_LFLAG;
> break;
> case 'm':
> if (logstr != NULL)
> @@ -273,9 +274,10 @@ rcs_main(int argc, char **argv)
> lkmode = RCS_LOCK_LOOSE;
> break;
> case 'u':
> - /* XXX - Check with -l flag. */
> + if (rcsflags & RCSPROG_LFLAG)
> + warnx("-l overridden by -u");
> urev = rcs_optarg;
> - rcsflags |= RCSPROG_UFLAG;
> + rcsflags = RCSPROG_UFLAG;
> break;
> case 'V':
> printf("%s\n", rcs_version);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 09:34:33AM +0200, Otto Moerbeek wrote:
> On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
>
> > Fritjof, have you let the gnu rcs project know about the segfault?
> > Maybe see how they choose to fix things and then follow their lead?
>
> That will only slow things down. Do what -L -U does is better, imo.
>
Otto, so you appreciate a diff more like this one?
> -Otto
> >
> >
fritjof
Index: rcsprog.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
retrieving revision 1.152
diff -u -p -r1.152 rcsprog.c
--- rcsprog.c 2 Oct 2014 06:23:15 - 1.152
+++ rcsprog.c 7 Oct 2014 12:53:10 -
@@ -235,9 +235,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_STRICT;
break;
case 'l':
- /* XXX - Check with -u flag. */
+ if (rcsflags & RCSPROG_UFLAG)
+ warnx("-u overridden by -l");
lrev = rcs_optarg;
- rcsflags |= RCSPROG_LFLAG;
+ rcsflags = RCSPROG_LFLAG;
break;
case 'm':
if (logstr != NULL)
@@ -273,9 +274,10 @@ rcs_main(int argc, char **argv)
lkmode = RCS_LOCK_LOOSE;
break;
case 'u':
- /* XXX - Check with -l flag. */
+ if (rcsflags & RCSPROG_LFLAG)
+ warnx("-l overridden by -u");
urev = rcs_optarg;
- rcsflags |= RCSPROG_UFLAG;
+ rcsflags = RCSPROG_UFLAG;
break;
case 'V':
printf("%s\n", rcs_version);
Re: hack for carp in IPv6 source address selection
On 03/10/14(Fri) 14:46, Stefan Sperling wrote:
> The IPv6 source address selection algorithm breaks ties by performing a
> bitwise match of each candidate source address against the destination
> address. The longest matching source address wins, regardless of which
> interface the source address came from.
>
> In my carp setup, this is causing a problem.
>
> Consider the carp address 2001:DB8:10::14, which is configured on
> firewall A (carp master state) and firewall B (carp backup state),
> each of which has another address in the same prefix on a non-carp
> interface (A has 2001:DB8:10::1 and B has 2001:DB8:10::11).
>
> In this setup, connecting from A to B or from B to A via IPv6 is impossible.
> A will use 2001:DB8:10::14 as source address when it sends neighbour
> solicitations to B (2001:DB8:10::11). Since 2001:DB8:10::14 is a local
> address from B's point of view, B doesn't reply to neighbour solicitations
> sent by A. The only currently available workaround is to re-configure
> addresses in a way that outsmarts the longest match check such that a
> carp address always loses the tie. (Another workaround is to use IPv4
> which doesn't have this problem.)
>
> The hack below special-cases carp interfaces: If there is a tie, then a
> carp interface is not allowed to win even if it has a longer bitwise match.
> (The carp interface is in master state here -- carp interfaces in backup
> state are never considered for source addresses in the first place.)
>
> This hack makes communication between A and B work over IPv6 in the
> above scenario.
I think this hack makes sense. I'm really afraid of the carp tentacles,
but I don't think there's a better way of solving this problem right
now.
This change is similar to the "let's move the cloning route" hack for
IPv4, since it gives a higher ``priority'' to any non-carp interface
when selecting source addresses, right?
> I also considered another solution: Make carp backups treat their
> local carp address as a non-local address. However, this would
> be a much more invasive change and would also affect IPv4.
This is certainly not an easy change, and it definitively comes with its
own specific dragons, but I believe that it would remove a lot of hacks
in the stack.
> - if (matchcmp > 0) /* (8) */
> + if (matchcmp > 0) { /* (8) */
> +#if NCARP > 0
> + /*
[...]
> + */
> + if (ifp->if_type == IFT_CARP)
> + continue;
> +#endif
> goto replace;
> + }
What if oifp is also a carp interface? Is it possible? Shouldn't you
use the pattern of in_addprefix():
if (ifp->if_type == IFT_CARP &&
oifp->if_type != IFT_CARP)
continue;
Either way I'm ok with your diff.
Re: remove repeated #define in acpithinkpad.c
On 2014/10/07 13:08, Theo Buehler wrote: > The latest commit caused a repeated line: > > Index: acpithinkpad.c > === > RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v > retrieving revision 1.39 > diff -u -p -r1.39 acpithinkpad.c > --- acpithinkpad.c5 Oct 2014 01:31:12 - 1.39 > +++ acpithinkpad.c7 Oct 2014 11:02:35 - > @@ -68,7 +68,6 @@ > #define THINKPAD_BUTTON_HIBERNATE 0x100c > #define THINKPAD_KEYLIGHT_CHANGED 0x101c > #define THINKPAD_BUTTON_CONFIG 0x101d > -#define THINKPAD_BUTTON_CONFIG 0x101d > #define THINKPAD_BUTTON_FIND0x101e > #define THINKPAD_BUTTON_ALL_ACTIVEPROGS 0x101f > #define THINKPAD_BUTTON_ALL_PROGS 0x1020 > Fixed, thank you.
remove repeated #define in acpithinkpad.c
The latest commit caused a repeated line: Index: acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.39 diff -u -p -r1.39 acpithinkpad.c --- acpithinkpad.c 5 Oct 2014 01:31:12 - 1.39 +++ acpithinkpad.c 7 Oct 2014 11:02:35 - @@ -68,7 +68,6 @@ #defineTHINKPAD_BUTTON_HIBERNATE 0x100c #defineTHINKPAD_KEYLIGHT_CHANGED 0x101c #defineTHINKPAD_BUTTON_CONFIG 0x101d -#defineTHINKPAD_BUTTON_CONFIG 0x101d #defineTHINKPAD_BUTTON_FIND0x101e #defineTHINKPAD_BUTTON_ALL_ACTIVEPROGS 0x101f #defineTHINKPAD_BUTTON_ALL_PROGS 0x1020
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
> Fritjof, have you let the gnu rcs project know about the segfault?
> Maybe see how they choose to fix things and then follow their lead?
>
No, I have not.
I hope they follow the tech@ mailing list. :)
>
> On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
> wrote:
> >
> > I think that GNU RCS segfaulting for -u -l is enough justification to do
> > what we like, so a message (and last flag wins) like -L/-U would be fine
> > with me.
> >
> > But if we want to do what they probably "meant" to happen then better to
> > match -l -u like Fritjof's diff.
> >
> >
> > On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
> > > On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
> > >
> > > >
> > > > OTOH, check out what we do with rcs -L and -U...
> > >
> > > I kinda like that, because it tells you exactly what it is doing.
> > >
> > > -Otto
> > >
> > > >
> > > >
> > > > On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
> > > > > Matching GNU RCS seems preferable to me but I don't feel strongly
> > > > > about
> > > > > it.
> > > > >
> > > > > I wouldn't mention this in the man page, it hardly seems like
> > > > > behaviour
> > > > > anyone should (or will need to) rely on.
> > > > >
> > > > >
> > > > > On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
> > > > > > posix commands (like ls(1) for example) keep the last option when
> > > > > > mutually exclusive options are specified. does it make sense to
> > > > > > keep rcs consistent with that convention? also is a man page diff
> > > > > > needed?
> > > > > >
> > > > > >
> > > > > > > On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
> > > > > > > wrote:
> > > > > > >
> > > > > > > The existing behaviour isn't wildly useful, makes sense to me, ok
> > > > > > > nicm
> > > > > > >
> > > > > > >
> > > > > > >> On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch
> > > > > > >> wrote:
> > > > > > >> Hi tech,
> > > > > > >>
> > > > > > >> the OpenRCS rcs command produces the following output if -l and
> > > > > > >> -u is
> > > > > > >> used in the same command:
> > > > > > >>
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> 1.1 unlocked
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> 1.1 unlocked
> > > > > > >>
> > > > > > >> I've looked at GnuRCS and it has another way to handle these
> > > > > > >> parameters
> > > > > > >> (it seems the other BSDs use GnuRCS, too).
> > > > > > >>
> > > > > > >> Debian 7.5:
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> rcs: foo.txt,v: no lock set on revision 1.1
> > > > > > >> 1.1 locked
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> Segmentation fault
> > > > > > >>
> > > > > > >> Well, I think the "Segmentation fault" isn't that important :),
> > > > > > >> but GnuRCS
> > > > > > >> does not lock and unlock a file by using the same command like
> > > > > > >> OpenRCS.
> > > > > > >>
> > > > > > >> I think the different implementations of RCS should share the
> > > > > > >> same
> > > > > > >> behaviour:
> > > > > > >>
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> done
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 unlocked
> > > > > > >> done
> > > > > > >>
> > > > > > >> fritjof
> > > > > > >>
> > > > > > >>
> > > > > > >> Index: rcsprog.c
> > > > > > >> ===
> > > > > > >> RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
> > > > > > >> retrieving revision 1.151
> > > > > > >> diff -u -p -r1.151 rcsprog.c
> > > > > > >> --- rcsprog.c12 Jul 2011 21:00:32 -1.151
> > > > > > >> +++ rcsprog.c3 Aug 2014 15:42:34 -
> > > > > > >> @@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
> > > > > > >>lkmode = RCS_LOCK_STRICT;
> > > > > > >>break;
> > > > > > >>case 'l':
> > > > > > >> -/* XXX - Check with -u flag. */
> > > > > > >> -lrev = rcs_optarg;
> > > > > > >> -rcsflags |= RCSPROG_LFLAG;
> > > > > > >> +if (!(rcsflags & RCSPROG_UFLAG)) {
> > > > > > >> +lrev = rcs_optarg;
> > > > > > >> +rcsflags |= RCSPROG_LFLAG;
> > > > > > >> +}
> > > > > > >>break;
> > > > > > >>case 'm':
> > > > > > >>if (logstr != NULL)
> > > > > > >> @@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
> > > > > > >>lkmode = RCS_LOCK_LOOSE;
> > > > > > >>break;
> > > > > > >>case 'u':
> > > > > > >> -/* XXX - Check with -l flag. */
> > > > > > >> -urev = rcs_optarg;
> > > > > > >>
Unnecessary lookup for every packet in ip_output()
Now that we can use the routing table to check if the destination
of a packet is a broadcast address, we can replace the lookup done
for every packet by the simple check below.
Ok?
Index: netinet/ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.267
diff -u -p -r1.267 ip_output.c
--- netinet/ip_output.c 27 Sep 2014 12:26:16 - 1.267
+++ netinet/ip_output.c 7 Oct 2014 10:09:56 -
@@ -484,8 +484,8 @@ reroute:
* such a packet; if the packet is going in an IPsec tunnel, skip
* this check.
*/
- if ((sproto == 0) && (in_broadcast(dst->sin_addr, ifp,
- m->m_pkthdr.ph_rtableid))) {
+ if ((sproto == 0) && ((dst->sin_addr.s_addr == INADDR_BROADCAST) ||
+ (ro && ro->ro_rt && ISSET(ro->ro_rt->rt_flags, RTF_BROADCAST {
if ((ifp->if_flags & IFF_BROADCAST) == 0) {
error = EADDRNOTAVAIL;
goto bad;
Re: re(4) mtu >1500
On 2014/10/06 12:19, Chris Cappuccio wrote: > Stuart Henderson [s...@spacehopper.org] wrote: > > Does anyone have an idea of what's needed for working jumbos on the > > RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled? > > These seem to account for most of the chips seen in hardware > > designs from the last couple of years (including APU and some others). > > > > if ((sc->rl_flags & RL_FLAG_JUMBOV2) == 0) > > ifp->if_hardmtu = sc->rl_max_mtu; > > > > I think the secrets are here :) > > http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461&view=markup > Ah, more specifically http://svnweb.freebsd.org/base?view=revision&revision=217499 / http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498&r2=217499&pathrev=217499 OK that's probably more than I can figure out how to port without hardware then..
Re: Kill rtalloc_noclone()
On 30/09/14(Tue) 10:51, Martin Pieuchot wrote:
> After rtalloc(), here's a simpler inliner diff to only use rtalloc1()
> when dealing with route lookups.
>
> ok?
Anyone?
>
> Index: net/pf.c
> ===
> RCS file: /home/ncvs/src/sys/net/pf.c,v
> retrieving revision 1.887
> diff -u -p -r1.887 pf.c
> --- net/pf.c 27 Sep 2014 12:26:16 - 1.887
> +++ net/pf.c 30 Sep 2014 08:48:00 -
> @@ -2968,7 +2968,8 @@ pf_calc_mss(struct pf_addr *addr, sa_fam
> dst->sin_len = sizeof(*dst);
> dst->sin_addr = addr->v4;
> ro.ro_tableid = rtableid;
> - rtalloc_noclone(&ro);
> + ro.ro_rt = rtalloc1(&ro.ro_dst, RT_REPORT | RT_NOCLONING,
> + ro.ro_tableid);
> rt = ro.ro_rt;
> break;
> #endif /* INET */
> @@ -2981,7 +2982,8 @@ pf_calc_mss(struct pf_addr *addr, sa_fam
> dst6->sin6_len = sizeof(*dst6);
> dst6->sin6_addr = addr->v6;
> ro6.ro_tableid = rtableid;
> - rtalloc_noclone((struct route *)&ro6);
> + ro6.ro_rt = rtalloc1(sin6tosa(&ro6.ro_dst),
> + RT_REPORT | RT_NOCLONING, ro6.ro_tableid);
> rt = ro6.ro_rt;
> break;
> #endif /* INET6 */
> @@ -5435,7 +5437,8 @@ pf_routable(struct pf_addr *addr, sa_fam
> if (kif != NULL && kif->pfik_ifp->if_type == IFT_ENC)
> goto out;
>
> - rtalloc_noclone((struct route *)&ro);
> + ro.ro_rt = rtalloc1((struct sockaddr *)&ro.ro_dst,
> + RT_REPORT | RT_NOCLONING, ro.ro_tableid);
>
> if (ro.ro_rt != NULL) {
> /* No interface given, this is a no-route check */
> @@ -5502,7 +5505,8 @@ pf_rtlabel_match(struct pf_addr *addr, s
> #endif /* INET6 */
> }
>
> - rtalloc_noclone((struct route *)&ro);
> + ro.ro_rt = rtalloc1((struct sockaddr *)&ro.ro_dst,
> + RT_REPORT | RT_NOCLONING, ro.ro_tableid);
>
> if (ro.ro_rt != NULL) {
> if (ro.ro_rt->rt_labelid == aw->v.rtlabel)
> Index: net/route.c
> ===
> RCS file: /home/ncvs/src/sys/net/route.c,v
> retrieving revision 1.183
> diff -u -p -r1.183 route.c
> --- net/route.c 27 Sep 2014 12:26:16 - 1.183
> +++ net/route.c 30 Sep 2014 08:48:00 -
> @@ -310,18 +310,6 @@ rtable_exists(u_int id) /* verify table
> return (1);
> }
>
> -/*
> - * Packet routing routines.
> - */
> -void
> -rtalloc_noclone(struct route *ro)
> -{
> - if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP))
> - return; /* cached route is still valid */
> - ro->ro_rt = rtalloc1(&ro->ro_dst, RT_REPORT | RT_NOCLONING,
> - ro->ro_tableid);
> -}
> -
> struct rtentry *
> rtalloc1(struct sockaddr *dst, int flags, u_int tableid)
> {
> Index: net/route.h
> ===
> RCS file: /home/ncvs/src/sys/net/route.h,v
> retrieving revision 1.97
> diff -u -p -r1.97 route.h
> --- net/route.h 27 Sep 2014 12:26:16 - 1.97
> +++ net/route.h 30 Sep 2014 08:48:00 -
> @@ -380,7 +380,6 @@ void rt_timer_queue_destroy(struct
> rt
> unsigned long rt_timer_queue_count(struct rttimer_queue *);
> void rt_timer_timer(void *);
>
> -void rtalloc_noclone(struct route *);
> #ifdef SMALL_KERNEL
> #define rtalloc_mpath(dst, s, rtableid) rtalloc1((dst), RT_REPORT,
> (rtableid))
> #endif
>
Re: mg: add bounce matching for [] and {}
On 08/13/14 18:51, Brian Callahan wrote:
> Hi tech --
>
> Diff below adds the bounce matching for [] and {} in mg like it does for ().
> I miss having that from GNU Emacs, anyone else?
>
> OK?
>
> ~Brian
Just noticed this yesterday. Thanks!
Stu
Re: FIFO fd not marked readable after EOF
On Mon, Oct 06, 2014 at 04:56:08PM -0600, Todd C. Miller wrote:
> The following diff should fix it.
>
> - todd
>
> Index: sys/miscfs/fifofs/fifo_vnops.c
> ===
> RCS file: /home/cvs/openbsd/src/sys/miscfs/fifofs/fifo_vnops.c,v
> retrieving revision 1.41
> diff -u -r1.41 fifo_vnops.c
> --- sys/miscfs/fifofs/fifo_vnops.c14 Sep 2014 14:17:26 - 1.41
> +++ sys/miscfs/fifofs/fifo_vnops.c6 Oct 2014 22:51:50 -
> @@ -147,8 +147,8 @@
> return (error);
> }
> fip->fi_readers = fip->fi_writers = 0;
> + wso->so_state |= SS_CANTSENDMORE;
> wso->so_snd.sb_lowat = PIPE_BUF;
> - rso->so_state |= SS_CANTRCVMORE;
> }
> if (ap->a_mode & FREAD) {
> fip->fi_readers++;
> @@ -287,24 +287,12 @@
> {
> struct vop_poll_args *ap = v;
> struct file filetmp;
> - short ostate;
> int revents = 0;
>
> if (ap->a_events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) {
> - /*
> - * Socket and FIFO poll(2) semantics differ wrt EOF on read.
> - * Unlike a normal socket, FIFOs don't care whether or not
> - * SS_CANTRCVMORE is set. To get the correct semantics we
> - * must clear SS_CANTRCVMORE from so_state temporarily.
> - */
> - ostate = ap->a_vp->v_fifoinfo->fi_readsock->so_state;
> - if (ap->a_events & (POLLIN | POLLRDNORM))
> - ap->a_vp->v_fifoinfo->fi_readsock->so_state &=
> - ~SS_CANTRCVMORE;
> filetmp.f_data = ap->a_vp->v_fifoinfo->fi_readsock;
> if (filetmp.f_data)
> revents |= soo_poll(&filetmp, ap->a_events, ap->a_p);
> - ap->a_vp->v_fifoinfo->fi_readsock->so_state = ostate;
> }
> if (ap->a_events & (POLLOUT | POLLWRNORM | POLLWRBAND)) {
> filetmp.f_data = ap->a_vp->v_fifoinfo->fi_writesock;
Thanks, that fixed it!
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 7, 2014 at 3:34 AM, Otto Moerbeek wrote: > On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote: > >> Fritjof, have you let the gnu rcs project know about the segfault? >> Maybe see how they choose to fix things and then follow their lead? > > That will only slow things down. Do what -L -U does is better, imo. > > -Otto between the 2 choices this would be my choice too.
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 07, 2014 at 03:10:44AM -0400, Daniel Dickman wrote:
> Fritjof, have you let the gnu rcs project know about the segfault?
> Maybe see how they choose to fix things and then follow their lead?
That will only slow things down. Do what -L -U does is better, imo.
-Otto
>
>
> On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
> wrote:
> >
> > I think that GNU RCS segfaulting for -u -l is enough justification to do
> > what we like, so a message (and last flag wins) like -L/-U would be fine
> > with me.
> >
> > But if we want to do what they probably "meant" to happen then better to
> > match -l -u like Fritjof's diff.
> >
> >
> > On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
> > > On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
> > >
> > > >
> > > > OTOH, check out what we do with rcs -L and -U...
> > >
> > > I kinda like that, because it tells you exactly what it is doing.
> > >
> > > -Otto
> > >
> > > >
> > > >
> > > > On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
> > > > > Matching GNU RCS seems preferable to me but I don't feel strongly
> > > > > about
> > > > > it.
> > > > >
> > > > > I wouldn't mention this in the man page, it hardly seems like
> > > > > behaviour
> > > > > anyone should (or will need to) rely on.
> > > > >
> > > > >
> > > > > On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
> > > > > > posix commands (like ls(1) for example) keep the last option when
> > > > > > mutually exclusive options are specified. does it make sense to
> > > > > > keep rcs consistent with that convention? also is a man page diff
> > > > > > needed?
> > > > > >
> > > > > >
> > > > > > > On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
> > > > > > > wrote:
> > > > > > >
> > > > > > > The existing behaviour isn't wildly useful, makes sense to me, ok
> > > > > > > nicm
> > > > > > >
> > > > > > >
> > > > > > >> On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch
> > > > > > >> wrote:
> > > > > > >> Hi tech,
> > > > > > >>
> > > > > > >> the OpenRCS rcs command produces the following output if -l and
> > > > > > >> -u is
> > > > > > >> used in the same command:
> > > > > > >>
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> 1.1 unlocked
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> 1.1 unlocked
> > > > > > >>
> > > > > > >> I've looked at GnuRCS and it has another way to handle these
> > > > > > >> parameters
> > > > > > >> (it seems the other BSDs use GnuRCS, too).
> > > > > > >>
> > > > > > >> Debian 7.5:
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> rcs: foo.txt,v: no lock set on revision 1.1
> > > > > > >> 1.1 locked
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> Segmentation fault
> > > > > > >>
> > > > > > >> Well, I think the "Segmentation fault" isn't that important :),
> > > > > > >> but GnuRCS
> > > > > > >> does not lock and unlock a file by using the same command like
> > > > > > >> OpenRCS.
> > > > > > >>
> > > > > > >> I think the different implementations of RCS should share the
> > > > > > >> same
> > > > > > >> behaviour:
> > > > > > >>
> > > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 locked
> > > > > > >> done
> > > > > > >>
> > > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > > >> RCS file: foo.txt,v
> > > > > > >> 1.1 unlocked
> > > > > > >> done
> > > > > > >>
> > > > > > >> fritjof
> > > > > > >>
> > > > > > >>
> > > > > > >> Index: rcsprog.c
> > > > > > >> ===
> > > > > > >> RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
> > > > > > >> retrieving revision 1.151
> > > > > > >> diff -u -p -r1.151 rcsprog.c
> > > > > > >> --- rcsprog.c12 Jul 2011 21:00:32 -1.151
> > > > > > >> +++ rcsprog.c3 Aug 2014 15:42:34 -
> > > > > > >> @@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
> > > > > > >>lkmode = RCS_LOCK_STRICT;
> > > > > > >>break;
> > > > > > >>case 'l':
> > > > > > >> -/* XXX - Check with -u flag. */
> > > > > > >> -lrev = rcs_optarg;
> > > > > > >> -rcsflags |= RCSPROG_LFLAG;
> > > > > > >> +if (!(rcsflags & RCSPROG_UFLAG)) {
> > > > > > >> +lrev = rcs_optarg;
> > > > > > >> +rcsflags |= RCSPROG_LFLAG;
> > > > > > >> +}
> > > > > > >>break;
> > > > > > >>case 'm':
> > > > > > >>if (logstr != NULL)
> > > > > > >> @@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
> > > > > > >>lkmode = RCS_LOCK_LOOSE;
> > > > > > >>break;
> > > > > > >>case 'u':
> > > > > > >> -/* XXX - Check with -l flag. */
> > > > > > >> -urev = rcs_op
Re: [patch]lock and unlock like GnuRCS
Fritjof, have you let the gnu rcs project know about the segfault?
Maybe see how they choose to fix things and then follow their lead?
On Mon, Oct 6, 2014 at 10:47 AM, Nicholas Marriott
wrote:
>
> I think that GNU RCS segfaulting for -u -l is enough justification to do
> what we like, so a message (and last flag wins) like -L/-U would be fine
> with me.
>
> But if we want to do what they probably "meant" to happen then better to
> match -l -u like Fritjof's diff.
>
>
> On Fri, Oct 03, 2014 at 12:55:35PM +0200, Otto Moerbeek wrote:
> > On Thu, Oct 02, 2014 at 12:56:10AM +0100, Nicholas Marriott wrote:
> >
> > >
> > > OTOH, check out what we do with rcs -L and -U...
> >
> > I kinda like that, because it tells you exactly what it is doing.
> >
> > -Otto
> >
> > >
> > >
> > > On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
> > > > Matching GNU RCS seems preferable to me but I don't feel strongly about
> > > > it.
> > > >
> > > > I wouldn't mention this in the man page, it hardly seems like behaviour
> > > > anyone should (or will need to) rely on.
> > > >
> > > >
> > > > On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
> > > > > posix commands (like ls(1) for example) keep the last option when
> > > > > mutually exclusive options are specified. does it make sense to keep
> > > > > rcs consistent with that convention? also is a man page diff needed?
> > > > >
> > > > >
> > > > > > On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
> > > > > > wrote:
> > > > > >
> > > > > > The existing behaviour isn't wildly useful, makes sense to me, ok
> > > > > > nicm
> > > > > >
> > > > > >
> > > > > >> On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
> > > > > >> Hi tech,
> > > > > >>
> > > > > >> the OpenRCS rcs command produces the following output if -l and -u
> > > > > >> is
> > > > > >> used in the same command:
> > > > > >>
> > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > >> RCS file: foo.txt,v
> > > > > >> 1.1 locked
> > > > > >> 1.1 unlocked
> > > > > >>
> > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > >> RCS file: foo.txt,v
> > > > > >> 1.1 locked
> > > > > >> 1.1 unlocked
> > > > > >>
> > > > > >> I've looked at GnuRCS and it has another way to handle these
> > > > > >> parameters
> > > > > >> (it seems the other BSDs use GnuRCS, too).
> > > > > >>
> > > > > >> Debian 7.5:
> > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > >> RCS file: foo.txt,v
> > > > > >> rcs: foo.txt,v: no lock set on revision 1.1
> > > > > >> 1.1 locked
> > > > > >>
> > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > >> Segmentation fault
> > > > > >>
> > > > > >> Well, I think the "Segmentation fault" isn't that important :),
> > > > > >> but GnuRCS
> > > > > >> does not lock and unlock a file by using the same command like
> > > > > >> OpenRCS.
> > > > > >>
> > > > > >> I think the different implementations of RCS should share the same
> > > > > >> behaviour:
> > > > > >>
> > > > > >> $ rcs -l1.1 -u1.1 foo.txt
> > > > > >> RCS file: foo.txt,v
> > > > > >> 1.1 locked
> > > > > >> done
> > > > > >>
> > > > > >> $ rcs -u1.1 -l1.1 foo.txt
> > > > > >> RCS file: foo.txt,v
> > > > > >> 1.1 unlocked
> > > > > >> done
> > > > > >>
> > > > > >> fritjof
> > > > > >>
> > > > > >>
> > > > > >> Index: rcsprog.c
> > > > > >> ===
> > > > > >> RCS file: /cvs/src/usr.bin/rcs/rcsprog.c,v
> > > > > >> retrieving revision 1.151
> > > > > >> diff -u -p -r1.151 rcsprog.c
> > > > > >> --- rcsprog.c12 Jul 2011 21:00:32 -1.151
> > > > > >> +++ rcsprog.c3 Aug 2014 15:42:34 -
> > > > > >> @@ -234,9 +234,10 @@ rcs_main(int argc, char **argv)
> > > > > >>lkmode = RCS_LOCK_STRICT;
> > > > > >>break;
> > > > > >>case 'l':
> > > > > >> -/* XXX - Check with -u flag. */
> > > > > >> -lrev = rcs_optarg;
> > > > > >> -rcsflags |= RCSPROG_LFLAG;
> > > > > >> +if (!(rcsflags & RCSPROG_UFLAG)) {
> > > > > >> +lrev = rcs_optarg;
> > > > > >> +rcsflags |= RCSPROG_LFLAG;
> > > > > >> +}
> > > > > >>break;
> > > > > >>case 'm':
> > > > > >>if (logstr != NULL)
> > > > > >> @@ -272,9 +273,10 @@ rcs_main(int argc, char **argv)
> > > > > >>lkmode = RCS_LOCK_LOOSE;
> > > > > >>break;
> > > > > >>case 'u':
> > > > > >> -/* XXX - Check with -l flag. */
> > > > > >> -urev = rcs_optarg;
> > > > > >> -rcsflags |= RCSPROG_UFLAG;
> > > > > >> +if (!(rcsflags & RCSPROG_LFLAG)) {
> > > > > >> +urev = rcs_optarg;
> > > > > >> +rcsflags |= RCSPROG_UFLAG;
> > > > > >> +}
> > > > > >>break;
> > > > > >>case 'V':
> > > > > >>printf("%s\n", rcs_version);
> > > > > >
