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
nicholas.marri...@gmail.com 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
nicholas.marri...@gmail.com 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);
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
nicholas.marri...@gmail.com 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
nicholas.marri...@gmail.com 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);
Re: [patch]lock and unlock like GnuRCS
On Tue, Oct 7, 2014 at 3:34 AM, Otto Moerbeek o...@drijf.net 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: 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: 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: 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=272461view=markup Ah, more specifically http://svnweb.freebsd.org/base?view=revisionrevision=217499 / http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498r2=217499pathrev=217499 OK that's probably more than I can figure out how to port without hardware then..
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: [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
nicholas.marri...@gmail.com 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
nicholas.marri...@gmail.com 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);
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: 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.
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: [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 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: 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 sunxi0, address 02:99:03:c2:d2:6e
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.cREV=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
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: 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 s...@bell.net 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
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=272461view=markup Ah, more specifically http://svnweb.freebsd.org/base?view=revisionrevision=217499 / http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498r2=217499pathrev=217499 OK that's probably more than I can figure out how to port without hardware then.. -- The bums will always lose
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.cREV=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.
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);
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: 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 u...@mx5.nisiq.net
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.
