Re: ed(1): keep custom prompt string that was specified by -p
On Thu, Jun 18, 2015 at 12:33:58PM +0200, Theo Buehler wrote:
Here's a silly ed(1) session:
$ ed -p :
: P
P
*q
$
Notice how the prompt string changed from the custom prompt : to
the default prompt *.
This behavior seems to contradict both the man page and POSIX:
From ed(1):
-p string Specifies a command prompt. This may be toggled on and off
with the P command.
From POSIX:
The P command shall cause ed to prompt with an asterisk ('*') (or
string, if -p is specified) for all subsequent commands. The P command
alternatively shall turn this mode on and off; it shall be initially on
if the -p option is specified; otherwise, off.
With the patch below, the above session becomes
$ ed -p :
: P
P
: q
$
which, I believe, is closer to both the documentation and POSIX.
This also matches the behavior of GNU Ed 1.10.
it does seem odd, yes.
still, i'd like to know how netbsd and freebsd behave: all 3 manuals use
the same (ambiguous) text. it could be that we want to document it as a
difference to posix rather than change the behaviour (i'm not the guy to
judge whether a change in behaviour is warranted).
note also:
- posix isn;t explicit (surprise, surprise)
- posix also documents bsd systems as (simultaneously!) not supporting
P and supporting P as a synonym for p
jmc
Index: bin/ed/main.c
===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.43
diff -u -p -r1.43 main.c
--- bin/ed/main.c 16 Jan 2015 06:39:32 - 1.43
+++ bin/ed/main.c 18 Jun 2015 10:33:21 -
@@ -110,7 +110,7 @@ top:
while ((c = getopt(argc, argv, p:sx)) != -1)
switch (c) {
case 'p': /* set prompt */
- prompt = optarg;
+ dps = prompt = optarg;
break;
case 's': /* run script */
scripted = 1;
Re: openssl.1: two misspellings
On Thu, Jun 18, 2015 at 12:25:13PM +0200, Theo Buehler wrote: Index: usr.bin/openssl/openssl.1 === RCS file: /cvs/src/usr.bin/openssl/openssl.1,v retrieving revision 1.13 diff -u -p -r1.13 openssl.1 --- usr.bin/openssl/openssl.1 28 Feb 2015 21:51:56 - 1.13 +++ usr.bin/openssl/openssl.1 18 Jun 2015 10:21:53 - @@ -5509,7 +5509,7 @@ form, where file may be an algorithm parameter file, created by the .Cm genpkey -genparam -command or an X.509 certificate for a key with approriate algorithm. +command or an X.509 certificate for a key with appropriate algorithm. .Pp .Ar param : Ns Ar file generates a key using the parameter file or certificate @@ -7499,7 +7499,7 @@ Expects a signed mail message on input a Both clear text and opaque signing is supported. .El .Pp -The reamaining options are as follows: +The remaining options are as follows: .Bl -tag -width .It Xo .Fl aes128 | aes192 | aes256 | des | fixed, thanks. jmc
iwm(4): make iwm_newstate() interrupt safe
The net80211 stack assumes drivers will switch IEEE80211_S_* states in
interrupt context. iwm(4) does not follow this rule. Since it insists on
responses from firmware commands to look for success or failure and it
uses tsleep() to wait for responses it cannot switch state in interrupt
context. So currently, the entire state machine is deferred to process
context (big hammer solution) :-/
Complications arise in the suspend/resume path because of this, such as
http://marc.info/?l=openbsd-techm=143438073018743w=2 apart from several
other such issues where a failure on part of the firmware to respond will
deadlock the driver in an endless tsleep.
I would very much like iwm_newstate() to be interrupt safe and get rid of
the pesky newstate_cb task which wraps it. It makes debugging and following
the control flow difficult. And I hope the driver will be more stable overall.
There are two ways to approach this:
- Simply don't care about answers from firmware when in interrupt
(note that this is what iwn(4) does)
- Busy-wait for replies from the firmware when in interrupt
The diff below is an attempt at the first approach simply because it can
be written with less code (no busy waits). And if we ignore an error response
and the firmware freaks out, well, we'll eventually handle the problem
by resetting the hardware. There's nothing much else we could do if a
command fails to complete after busy-wait anyway.
I would very much like other people to test this change to ensure
I'm not breaking some other use case I can't cover. And perhaps there's
a condition where a busy-wait is necessary to ensure proper operation?
I've tested suspend/resume, and switching associations between a couple
of different APs, and interface down/up on the AP side. I'm not seeing
any regressions apart from the fact that the firmware will crash if a
scan is run while the interface is up -- bringing the interface back up
is possible so this is not entirely horrible.
Note that we must get rid of iwm_release() or we break suspend/resume and
de-auth from AP, because iwm_release() calls hw_init() which will tsleep()
for loading firmware. This is probably related to why scans don't work
while we're up. However, the way the driver currently handles RUN-SCAN
is pretty broken as well since it merely provides an illusion of it working
and doesn't actually know how to handle this transition in firmware/hardware.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_iwm.c
--- if_iwm.c15 Jun 2015 08:06:11 - 1.45
+++ if_iwm.c18 Jun 2015 13:29:46 -
@@ -195,14 +195,6 @@ const struct iwm_rate {
#define IWM_RIDX_IS_CCK(_i_) ((_i_) IWM_RIDX_OFDM)
#define IWM_RIDX_IS_OFDM(_i_) ((_i_) = IWM_RIDX_OFDM)
-struct iwm_newstate_state {
- struct task ns_wk;
- struct ieee80211com *ns_ic;
- enum ieee80211_state ns_nstate;
- int ns_arg;
- int ns_generation;
-};
-
intiwm_store_cscheme(struct iwm_softc *, uint8_t *, size_t);
intiwm_firmware_store_section(struct iwm_softc *, enum iwm_ucode_type,
uint8_t *, size_t);
@@ -338,9 +330,9 @@ int iwm_send_cmd(struct iwm_softc *, str
intiwm_mvm_send_cmd_pdu(struct iwm_softc *, uint8_t, uint32_t, uint16_t,
const void *);
intiwm_mvm_send_cmd_status(struct iwm_softc *, struct iwm_host_cmd *,
- uint32_t *);
+ uint32_t *, int);
intiwm_mvm_send_cmd_pdu_status(struct iwm_softc *, uint8_t,
- uint16_t, const void *, uint32_t *);
+ uint16_t, const void *, uint32_t *,
int);
void iwm_free_resp(struct iwm_softc *, struct iwm_host_cmd *);
void iwm_cmd_done(struct iwm_softc *, struct iwm_rx_packet *);
void iwm_update_sched(struct iwm_softc *, int, int, uint8_t, uint16_t);
@@ -401,12 +393,10 @@ int iwm_mvm_mac_ctxt_changed(struct iwm_
intiwm_mvm_update_quotas(struct iwm_softc *, struct iwm_node *);
intiwm_auth(struct iwm_softc *);
intiwm_assoc(struct iwm_softc *);
-intiwm_release(struct iwm_softc *, struct iwm_node *);
struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
void iwm_calib_timeout(void *);
void iwm_setrates(struct iwm_node *);
intiwm_media_change(struct ifnet *);
-void iwm_newstate_cb(void *);
intiwm_newstate(struct ieee80211com *, enum ieee80211_state, int);
void iwm_endscan_cb(void *);
intiwm_init_hw(struct iwm_softc *);
@@ -2188,10 +2178,10 @@ iwm_mvm_send_time_event_cmd(struct iwm_s
if (sc-sc_capaflags IWM_UCODE_TLV_FLAGS_TIME_EVENT_API_V2)
return iwm_mvm_send_cmd_pdu(sc, IWM_TIME_EVENT_CMD,
- IWM_CMD_SYNC, sizeof(*cmd), cmd);
+ IWM_CMD_ASYNC, sizeof(*cmd), cmd);
Re: ed(1): keep custom prompt string that was specified by -p
On Thu, Jun 18, 2015 at 03:56:15PM +0200, Theo Buehler wrote: From looking at the source code, I'm quite sure that the other BSD's behavior is the same as the current behavior in OpenBSD. I agree that the formulations in the manpages and POSIX aren't explicit, let alone unambiguous, as to what exactly is supposed to happen when pressing P. However, what POSIX claims about P being a synonym of p is bogus: * BSD does not support the P command; moreover, in BSD it is synonymous with the p command. Compare this with the following session: $ ed p ? P *p ? *P q $ The source code in FreeBSD and NetBSD shows that the print command p and the prompt command P are treated completely differently there as well. the posix stuff no doubt relates to traditional bsd behaviour. obviously P is now supported. if other systems behave this way and no one steps up to support the idea of changing behaviour, i'll add a note to the doc. but i'll wait and see first. jmc
Re: ed(1): keep custom prompt string that was specified by -p
On Thu, Jun 18, 2015 at 02:16:08PM +0100, Jason McIntyre wrote:
On Thu, Jun 18, 2015 at 12:33:58PM +0200, Theo Buehler wrote:
Here's a silly ed(1) session:
$ ed -p :
: P
P
*q
$
Notice how the prompt string changed from the custom prompt : to
the default prompt *.
This behavior seems to contradict both the man page and POSIX:
From ed(1):
-p string Specifies a command prompt. This may be toggled on and off
with the P command.
From POSIX:
The P command shall cause ed to prompt with an asterisk ('*') (or
string, if -p is specified) for all subsequent commands. The P
command
alternatively shall turn this mode on and off; it shall be initially
on
if the -p option is specified; otherwise, off.
With the patch below, the above session becomes
$ ed -p :
: P
P
: q
$
which, I believe, is closer to both the documentation and POSIX.
This also matches the behavior of GNU Ed 1.10.
it does seem odd, yes.
still, i'd like to know how netbsd and freebsd behave: all 3 manuals use
the same (ambiguous) text. it could be that we want to document it as a
difference to posix rather than change the behaviour (i'm not the guy to
judge whether a change in behaviour is warranted).
note also:
- posix isn;t explicit (surprise, surprise)
- posix also documents bsd systems as (simultaneously!) not supporting
P and supporting P as a synonym for p
jmc
From looking at the source code, I'm quite sure that the other BSD's
behavior is the same as the current behavior in OpenBSD.
I agree that the formulations in the manpages and POSIX aren't explicit,
let alone unambiguous, as to what exactly is supposed to happen when
pressing P.
However, what POSIX claims about P being a synonym of p is bogus:
* BSD does not support the P command; moreover, in BSD it is
synonymous with the p command.
Compare this with the following session:
$ ed
p
?
P
*p
?
*P
q
$
The source code in FreeBSD and NetBSD shows that the print command p
and the prompt command P are treated completely differently there as
well.
Index: bin/ed/main.c
===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.43
diff -u -p -r1.43 main.c
--- bin/ed/main.c 16 Jan 2015 06:39:32 - 1.43
+++ bin/ed/main.c 18 Jun 2015 10:33:21 -
@@ -110,7 +110,7 @@ top:
while ((c = getopt(argc, argv, p:sx)) != -1)
switch (c) {
case 'p': /* set prompt */
- prompt = optarg;
+ dps = prompt = optarg;
break;
case 's': /* run script */
scripted = 1;
Re: ed(1): keep custom prompt string that was specified by -p
On Thu, Jun 18, 2015 at 10:18 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Jun 18, 2015 at 03:56:15PM +0200, Theo Buehler wrote: From looking at the source code, I'm quite sure that the other BSD's behavior is the same as the current behavior in OpenBSD. I agree that the formulations in the manpages and POSIX aren't explicit, let alone unambiguous, as to what exactly is supposed to happen when pressing P. However, what POSIX claims about P being a synonym of p is bogus: * BSD does not support the P command; moreover, in BSD it is synonymous with the p command. Compare this with the following session: $ ed p ? P *p ? *P q $ The source code in FreeBSD and NetBSD shows that the print command p and the prompt command P are treated completely differently there as well. the posix stuff no doubt relates to traditional bsd behaviour. obviously P is now supported. if other systems behave this way and no one steps up to support the idea of changing behaviour, i'll add a note to the doc. but i'll wait and see first. jmc I think Theo's proposed change is correct. ok daniel@
Re: ed(1): keep custom prompt string that was specified by -p
On 06/18/15 15:18, Jason McIntyre wrote: On Thu, Jun 18, 2015 at 03:56:15PM +0200, Theo Buehler wrote: From looking at the source code, I'm quite sure that the other BSD's behavior is the same as the current behavior in OpenBSD. I agree that the formulations in the manpages and POSIX aren't explicit, let alone unambiguous, as to what exactly is supposed to happen when pressing P. However, what POSIX claims about P being a synonym of p is bogus: * BSD does not support the P command; moreover, in BSD it is synonymous with the p command. Compare this with the following session: $ ed p ? P *p ? *P q $ The source code in FreeBSD and NetBSD shows that the print command p and the prompt command P are treated completely differently there as well. the posix stuff no doubt relates to traditional bsd behaviour. obviously P is now supported. if other systems behave this way and no one steps up to support the idea of changing behaviour, i'll add a note to the doc. but i'll wait and see first. jmc $ uname -a; ed -p :: FreeBSD s3 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 :: P P :: q $ FreeBSD ed follows the behaviour of Theo Buehler's patch. hth Fred
Re: softraid checksumming discipline.
On Wednesday 17 June 2015, Karel Gardas wrote: Hello, I'm curious if anybody is working on implementing block-level checksumming on softraid? Not that I'm aware of. Backgroud: I'm comming from Solaris 11/ZFS world and I like ZFS's focus on data integrity from drive level up to the RAM. I've been thinking about OpenBSD and how to get the same with minimalistic effort (not porting ZFS) and I've though that having checksumming implemented in a virtual drive (softraid) may be the most easiest way. I think more easier than for example enhance ffs to include file-based checksums. Another issue is how to propagate block failures up to the file level, but for me it would be enough to just know something bad happening with the drive. At least for now. I hope discipline may be stacked on top of another so there is a possibility of using RAID1 with checksumming disciplines on two drives, hence getting something similar to what I use now with ZFS (zpool with two drives in mirroring setup). If stacking is not possible for whatever reason, then I would probably go and clone and modify RAID1 to add checksum support (if feasible of course). Stacking in softraid does work, but it is not officially supported (there are number of gotchas that you need to be aware of, such as the need to manually reassemble the volumes). It was never really designed to work this way and it results in I/O going through multiple layers unnecessarily. At some point it needs to be rearchitected so that it is stackable internally, which will then allow for a set of fixed but flexible disciplines. Re adding some form of checksumming, it only seems to make sense in the case of RAID 1 where you can decide that the data on a disk is invalid, then fail the read and pull the data from another drive. That coupled with block level healing or similar could be interesting. Otherwise checksumming on its own is not overly useful at this level - you would simply fail a read, which then results in potentially worse than bit-flipping at higher layers. If you wanted to investigate this I would suggest considering it as an option to the existing RAID 1 implementation. The bulk of it would be calculating and adding a checksum to each write and offsetting each block accordingly, along with verification on read. The failure modes would need to be thought through and handled - the re-reading from a different disk is already there, however what you then do with the failure is an open question (failing the chunk entirely is the heavy handed but already supported approach). Any comment on this topic welcome. Thanks, Karel -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: [patch]diff: uninitialized values
On Wed, 17 Jun 2015 20:53:57 +0200, Fritjof Bornebusch wrote: *edp1* and *edp2* could be used uninitialized, if *goto closem;* is called. I don't think so. If dirp1 is non-NULL, so must edp1 be. Likewise for dirp2 and edp2. The compiler just doesn't know that scandir() does not modify its output argument on error. - todd
[patch] dig(1), host(1), nslookup(1) manpages
If an application (say, named) is removed from base, but still included in ports, it it the policy to remove references to that application from base applications' manpages? If yes, diff below. Index: dig.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.1,v retrieving revision 1.9 diff -u -p -u -r1.9 dig.1 --- dig.1 9 Dec 2007 13:39:42 - 1.9 +++ dig.1 18 Jun 2015 18:51:59 - @@ -544,7 +544,6 @@ runs. .SH SEE ALSO .PP \fBhost\fR(1), -\fBnamed\fR(8), \fBdnssec\-keygen\fR(8), RFC1035. .SH BUGS Index: host.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/host.1,v retrieving revision 1.6 diff -u -p -u -r1.6 host.1 --- host.1 9 Dec 2007 13:39:42 - 1.6 +++ host.1 18 Jun 2015 18:51:59 - @@ -210,8 +210,7 @@ runs. \fI/etc/resolv.conf\fR .SH SEE ALSO .PP -\fBdig\fR(1), -\fBnamed\fR(8). +\fBdig\fR(1) .SH COPYRIGHT Copyright \(co 2004, 2005, 2007 Internet Systems Consortium, Inc. (ISC) .br Index: nslookup.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/nslookup.1,v retrieving revision 1.7 diff -u -p -u -r1.7 nslookup.1 --- nslookup.1 20 Feb 2010 19:59:52 - 1.7 +++ nslookup.1 18 Jun 2015 18:51:59 - @@ -247,8 +247,7 @@ Try the next nameserver if a nameserver .SH SEE ALSO .PP \fBdig\fR(1), -\fBhost\fR(1), -\fBnamed\fR(8). +\fBhost\fR(1). .SH AUTHOR .PP Andrew Cherenson
Re: [patch] dig(1), host(1), nslookup(1) manpages
On Thu, Jun 18, 2015 at 02:50:48PM -0500, Dutch Ingraham wrote: If an application (say, named) is removed from base, but still included in ports, it it the policy to remove references to that application from base applications' manpages? generally, yes. but in this case i'm less sure...the bind pages were always pretty much 3rd party anyway, and perhaps there's little gain from disassociating these pages from named (they're all from the bind group, after all). If yes, diff below. i won;t touch this, but no objection if another developer feels it somehow worthwhile. jmc Index: dig.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.1,v retrieving revision 1.9 diff -u -p -u -r1.9 dig.1 --- dig.1 9 Dec 2007 13:39:42 - 1.9 +++ dig.1 18 Jun 2015 18:51:59 - @@ -544,7 +544,6 @@ runs. .SH SEE ALSO .PP \fBhost\fR(1), -\fBnamed\fR(8), \fBdnssec\-keygen\fR(8), RFC1035. .SH BUGS Index: host.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/host.1,v retrieving revision 1.6 diff -u -p -u -r1.6 host.1 --- host.19 Dec 2007 13:39:42 - 1.6 +++ host.118 Jun 2015 18:51:59 - @@ -210,8 +210,7 @@ runs. \fI/etc/resolv.conf\fR .SH SEE ALSO .PP -\fBdig\fR(1), -\fBnamed\fR(8). +\fBdig\fR(1) .SH COPYRIGHT Copyright \(co 2004, 2005, 2007 Internet Systems Consortium, Inc. (ISC) .br Index: nslookup.1 === RCS file: /cvs/src/usr.sbin/bind/bin/dig/nslookup.1,v retrieving revision 1.7 diff -u -p -u -r1.7 nslookup.1 --- nslookup.120 Feb 2010 19:59:52 - 1.7 +++ nslookup.118 Jun 2015 18:51:59 - @@ -247,8 +247,7 @@ Try the next nameserver if a nameserver .SH SEE ALSO .PP \fBdig\fR(1), -\fBhost\fR(1), -\fBnamed\fR(8). +\fBhost\fR(1). .SH AUTHOR .PP Andrew Cherenson
Re: ed(1): keep custom prompt string that was specified by -p
On Thu, Jun 18, 2015 at 01:22:31PM -0400, Daniel Dickman wrote: I think Theo's proposed change is correct. ok daniel@ just to be clear, i'm not looking for oks for theo's patch. i am waiting to see what happens, and then i'll decide if we need to do anything to the docs. as i said, i'm not the guy to decide whether we change this behaviour. jmc
Re: softraid checksumming discipline.
On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing j...@sing.id.au wrote: Re adding some form of checksumming, it only seems to make sense in the case of RAID 1 where you can decide that the data on a disk is invalid, then fail the read and pull the data from another drive. That coupled with block level healing or similar could be interesting. Otherwise checksumming on its own is not overly useful at this level - you would simply fail a read, which then results in potentially worse than bit-flipping at higher layers. Honestly speaking, I value reliability in extreme way so I would rather prefer failed read than silent bit-flip propagated up to the application level. If you wanted to investigate this I would suggest considering it as an option to the existing RAID 1 implementation. The bulk of it would be calculating and adding a checksum to each write and offsetting each block accordingly, along with verification on read. The failure modes would need to be thought through and handled - the re-reading from a different disk is already there, however what you then do with the failure is an open question (failing the chunk entirely is the heavy handed but already supported approach). I will see what I can do with it over the summer. There is indeed a lot of questions which will need to be solved, but let's see if I'm able to come up with some patch as a proof of concept first. Just for now thinking about propagating failures in some form into sensors value and showing to user without hard chunk failure -- at least up to some predefined threshold. Also what's I'm used to use is kind of scrub, which looks like is kind of supported in kernel, at least there are some signs of scrub support there, but I'm yet to find out for what reason since bioctl does not know about it (yet?). Anyway, correct scrubbing will require whole drive zeroing first, but then it may be enforced just by dd drive to /dev/null probably -- just a wild guess. Thanks for your information! Karel
Re: [patch]rcs: rlog manpage typo
On Thu, Jun 18, 2015 at 10:49:32PM +0200, Pablo Méndez Hernández wrote: Hi, El 18/6/2015 22:46, Fritjof Bornebusch frit...@alokat.org escribiA^3: Hi tech@, *logins is omitted* sounds a little strange, doesn't it? logins as a keyword? Yes, but if you read it, it sounds wrong in some way. Regards. Pablo Regards, --F. Regards, --F. Index: rlog.1 === RCS file: /cvs/src/usr.bin/rcs/rlog.1,v retrieving revision 1.24 diff -u -p -r1.24 rlog.1 --- rlog.1A A A 3 Sep 2010 11:09:29 -A A A A 1.24 +++ rlog.1A A A 18 Jun 2015 20:41:40 - @@ -145,7 +145,7 @@ Print information about revisions checke A in a comma-separated list. A If A .Ar logins -is omitted, the user's login is assumed. +are omitted, the user's login is assumed. A .It Fl x Ns Ar suffixes A Specifies the suffixes for RCS files. A Suffixes should be separated by the
[patch]rcs: merge typo
What about this comma. I saw a few manpages, having it at this location. Regards, --F. Index: merge.1 === RCS file: /cvs/src/usr.bin/rcs/merge.1,v retrieving revision 1.3 diff -u -p -r1.3 merge.1 --- merge.1 28 Oct 2010 15:08:50 - 1.3 +++ merge.1 18 Jun 2015 20:52:30 - @@ -45,7 +45,7 @@ for details. .It Fl e Same as .Fl E -but does not warn about conflicts. +, but does not warn about conflicts. .It Fl L Ar label Specifies labels to be used in place of corresponding file names in conflict reports.
Re: [patch]rcs: ci manpage typo
On Thu, Jun 18, 2015 at 09:48:23PM +0100, Jason McIntyre wrote: On Thu, Jun 18, 2015 at 10:33:53PM +0200, Fritjof Bornebusch wrote: Hi tech@, isn't there a comma missing? depends how you like your commas. if i were writing it, i'd have the comma. but many wouldn;t, and it's certainly not wrong. the reason i like that last comma is demonstrated with this wonderful dedication: To my parents, Ayn Rand and God. love it ;) jmc ps won;t be changing the doc though. i don;t see the point of enforcing this - it;s really a matter of preference. I see. Thanks for the explanation. Regards, --F. Index: ci.1 === RCS file: /cvs/src/usr.bin/rcs/ci.1,v retrieving revision 1.38 diff -u -p -r1.38 ci.1 --- ci.112 Aug 2013 14:19:53 - 1.38 +++ ci.118 Jun 2015 20:30:22 - @@ -102,7 +102,7 @@ Only do update check-in. Print error and refuse to do check-in if the RCS file does not already exist. .It Fl k Ns Op Ar rev Search the working file for keywords and set the revision number, -creation date, state and author to the values found in these keywords +creation date, state, and author to the values found in these keywords instead of computing them. .It Fl l Ns Op Ar rev The same as
[patch]rcs: ci manpage typo
Hi tech@, isn't there a comma missing? Regards, --F. Index: ci.1 === RCS file: /cvs/src/usr.bin/rcs/ci.1,v retrieving revision 1.38 diff -u -p -r1.38 ci.1 --- ci.112 Aug 2013 14:19:53 - 1.38 +++ ci.118 Jun 2015 20:30:22 - @@ -102,7 +102,7 @@ Only do update check-in. Print error and refuse to do check-in if the RCS file does not already exist. .It Fl k Ns Op Ar rev Search the working file for keywords and set the revision number, -creation date, state and author to the values found in these keywords +creation date, state, and author to the values found in these keywords instead of computing them. .It Fl l Ns Op Ar rev The same as
Re: [patch]rcs: ci manpage typo
On Thu, Jun 18, 2015 at 10:33:53PM +0200, Fritjof Bornebusch wrote: Hi tech@, isn't there a comma missing? depends how you like your commas. if i were writing it, i'd have the comma. but many wouldn;t, and it's certainly not wrong. the reason i like that last comma is demonstrated with this wonderful dedication: To my parents, Ayn Rand and God. love it ;) jmc ps won;t be changing the doc though. i don;t see the point of enforcing this - it;s really a matter of preference. Regards, --F. Index: ci.1 === RCS file: /cvs/src/usr.bin/rcs/ci.1,v retrieving revision 1.38 diff -u -p -r1.38 ci.1 --- ci.1 12 Aug 2013 14:19:53 - 1.38 +++ ci.1 18 Jun 2015 20:30:22 - @@ -102,7 +102,7 @@ Only do update check-in. Print error and refuse to do check-in if the RCS file does not already exist. .It Fl k Ns Op Ar rev Search the working file for keywords and set the revision number, -creation date, state and author to the values found in these keywords +creation date, state, and author to the values found in these keywords instead of computing them. .It Fl l Ns Op Ar rev The same as
Re: [patch]rcs: merge typo
On Thu, Jun 18, 2015 at 10:59:37PM +0200, Fritjof Bornebusch wrote: What about this comma. I saw a few manpages, having it at this location. Regards, --F. Index: merge.1 === RCS file: /cvs/src/usr.bin/rcs/merge.1,v retrieving revision 1.3 diff -u -p -r1.3 merge.1 --- merge.1 28 Oct 2010 15:08:50 - 1.3 +++ merge.1 18 Jun 2015 20:52:30 - @@ -45,7 +45,7 @@ for details. .It Fl e Same as .Fl E -but does not warn about conflicts. +, but does not warn about conflicts. .It Fl L Ar label Specifies labels to be used in place of corresponding file names in conflict reports. it would be .Fl E , if you wanted it...but again a matter of preference. the but makes it redundant really. jmc
[patch]rcs: rlog manpage typo
Hi tech@, *logins is omitted* sounds a little strange, doesn't it? Regards, --F. Index: rlog.1 === RCS file: /cvs/src/usr.bin/rcs/rlog.1,v retrieving revision 1.24 diff -u -p -r1.24 rlog.1 --- rlog.1 3 Sep 2010 11:09:29 - 1.24 +++ rlog.1 18 Jun 2015 20:41:40 - @@ -145,7 +145,7 @@ Print information about revisions checke in a comma-separated list. If .Ar logins -is omitted, the user's login is assumed. +are omitted, the user's login is assumed. .It Fl x Ns Ar suffixes Specifies the suffixes for RCS files. Suffixes should be separated by the
Re: softraid checksumming discipline.
Joel, yes, I will work on your recommended RAID1 with checksumming of course. Just forgotten to add that. Thanks, Karel On Thu, Jun 18, 2015 at 10:40 PM, Karel Gardas gard...@gmail.com wrote: On Thu, Jun 18, 2015 at 6:32 PM, Joel Sing j...@sing.id.au wrote: Re adding some form of checksumming, it only seems to make sense in the case of RAID 1 where you can decide that the data on a disk is invalid, then fail the read and pull the data from another drive. That coupled with block level healing or similar could be interesting. Otherwise checksumming on its own is not overly useful at this level - you would simply fail a read, which then results in potentially worse than bit-flipping at higher layers. Honestly speaking, I value reliability in extreme way so I would rather prefer failed read than silent bit-flip propagated up to the application level. If you wanted to investigate this I would suggest considering it as an option to the existing RAID 1 implementation. The bulk of it would be calculating and adding a checksum to each write and offsetting each block accordingly, along with verification on read. The failure modes would need to be thought through and handled - the re-reading from a different disk is already there, however what you then do with the failure is an open question (failing the chunk entirely is the heavy handed but already supported approach). I will see what I can do with it over the summer. There is indeed a lot of questions which will need to be solved, but let's see if I'm able to come up with some patch as a proof of concept first. Just for now thinking about propagating failures in some form into sensors value and showing to user without hard chunk failure -- at least up to some predefined threshold. Also what's I'm used to use is kind of scrub, which looks like is kind of supported in kernel, at least there are some signs of scrub support there, but I'm yet to find out for what reason since bioctl does not know about it (yet?). Anyway, correct scrubbing will require whole drive zeroing first, but then it may be enforced just by dd drive to /dev/null probably -- just a wild guess. Thanks for your information! Karel
Re: [patch]rcs: rlog manpage typo
Hi, El 18/6/2015 22:46, Fritjof Bornebusch frit...@alokat.org escribió: Hi tech@, *logins is omitted* sounds a little strange, doesn't it? logins as a keyword? Regards. Pablo Regards, --F. Index: rlog.1 === RCS file: /cvs/src/usr.bin/rcs/rlog.1,v retrieving revision 1.24 diff -u -p -r1.24 rlog.1 --- rlog.1 3 Sep 2010 11:09:29 - 1.24 +++ rlog.1 18 Jun 2015 20:41:40 - @@ -145,7 +145,7 @@ Print information about revisions checke in a comma-separated list. If .Ar logins -is omitted, the user's login is assumed. +are omitted, the user's login is assumed. .It Fl x Ns Ar suffixes Specifies the suffixes for RCS files. Suffixes should be separated by the
Re: [patch]rcs: rlog manpage typo
On Thu, Jun 18, 2015 at 10:44:07PM +0200, Fritjof Bornebusch wrote: Hi tech@, *logins is omitted* sounds a little strange, doesn't it? it does, because in your head you're thinking of logins as being the plural of login (i.e. more than one login). but you can also - correctly - think of logins as being the argument name. you could read the text below as: If [the argument] logins is omitted... sounds different now, eh? in the docs, there is often this overlap where we can think of the argument name in more than one way. it creates ambiguities, but there you go. it would be impractical to try and force one style, i think. still, for this reason i dislike argument names which take the plural form. jmc Regards, --F. Index: rlog.1 === RCS file: /cvs/src/usr.bin/rcs/rlog.1,v retrieving revision 1.24 diff -u -p -r1.24 rlog.1 --- rlog.13 Sep 2010 11:09:29 - 1.24 +++ rlog.118 Jun 2015 20:41:40 - @@ -145,7 +145,7 @@ Print information about revisions checke in a comma-separated list. If .Ar logins -is omitted, the user's login is assumed. +are omitted, the user's login is assumed. .It Fl x Ns Ar suffixes Specifies the suffixes for RCS files. Suffixes should be separated by the
Re: [patch]rcs: rlog manpage typo
On Thu, Jun 18, 2015 at 09:57:13PM +0100, Jason McIntyre wrote: On Thu, Jun 18, 2015 at 10:44:07PM +0200, Fritjof Bornebusch wrote: Hi tech@, *logins is omitted* sounds a little strange, doesn't it? it does, because in your head you're thinking of logins as being the plural of login (i.e. more than one login). but you can also - correctly - think of logins as being the argument name. you could read the text below as: If [the argument] logins is omitted... sounds different now, eh? in the docs, there is often this overlap where we can think of the argument name in more than one way. it creates ambiguities, but there you go. it would be impractical to try and force one style, i think. still, for this reason i dislike argument names which take the plural form. Yeah, this can cause some confusion. But if it's the style, I'm okay with it. ;) jmc Regards, --F. Regards, --F. Index: rlog.1 === RCS file: /cvs/src/usr.bin/rcs/rlog.1,v retrieving revision 1.24 diff -u -p -r1.24 rlog.1 --- rlog.1 3 Sep 2010 11:09:29 - 1.24 +++ rlog.1 18 Jun 2015 20:41:40 - @@ -145,7 +145,7 @@ Print information about revisions checke in a comma-separated list. If .Ar logins -is omitted, the user's login is assumed. +are omitted, the user's login is assumed. .It Fl x Ns Ar suffixes Specifies the suffixes for RCS files. Suffixes should be separated by the
Re: important audio simplifications to test and review
On 2015-06-13, Alexandre Ratchov a...@caoua.org wrote: Many thanks to all who tested, below is an updated diff with the missing i386 bits and working uaudio. I have run into a serious problem on sparc64 (but I haven't tested elsewhere). I've added -L- to the sndiod flags and I'm streaming audio from a remote machine (AUDIODEVICE=snd@host/0) to the sparc64. After a while, the network on the sparc64 locks up. Not just sndiod, all the network. I can't even ping the machine any longer. But it is only the network; the machine remains fully responsive over the serial console. Playing around with ping/ping6, I see that the machine still sends packets, but it doesn't see any incoming packets, including ARP and NDP replies. It appears reproducible. Details: Sun Blade 150 with on-board gem(4) and a cmpci(4) expansion card sndiod_flags=-r44100 -f rsnd/1 -L- -- Christian naddy Weisgerber na...@mips.inka.de
Re: samba4 slow startup, shared libs?
Sweet. I'll knockup a patch and send it upstream shortly.
Ian McWilliam
From: Jérémie Courrèges-Anglas [j...@wxcvbn.org]
Sent: Thursday, 18 June 2015 8:11 PM
To: Ian Mcwilliam
Cc: Stuart Henderson; Mark Kettenis; tech@openbsd.org
Subject: Re: samba4 slow startup, shared libs?
Ian Mcwilliam i.mcwill...@uws.edu.au writes:
Curiously from
--- samba-4.0.3/wscript Tue Dec 4 21:07:44 2012
+++ samba-4.0.26/wscript Mon Dec 8 18:46:38 2014
-if sys.platform != openbsd4:
+if not sys.platform.startswith(openbsd):
conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed',
testflags=True)
Here's the output of LD_DEBUG=1 time samba-tool:
ritchie /usr/ports/net/samba4$ tail before after
== before ==
doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740:
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0]
doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0]
251.92 real 251.96 user 0.19 sys
doing dtors
doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0]
== after ==
doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0xa6021425800 @0xa603fca0740:
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0]
doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0]
1.49 real 1.24 user 0.22 sys
doing dtors
doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0]
(with wip samba-4.1.18)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: samba4 slow startup, shared libs?
Ian Mcwilliam i.mcwill...@uws.edu.au writes:
Curiously from
--- samba-4.0.3/wscript Tue Dec 4 21:07:44 2012
+++ samba-4.0.26/wscript Mon Dec 8 18:46:38 2014
-if sys.platform != openbsd4:
+if not sys.platform.startswith(openbsd):
conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed',
testflags=True)
Here's the output of LD_DEBUG=1 time samba-tool:
ritchie /usr/ports/net/samba4$ tail before after
== before ==
doing dtors obj 0x76bdc238000 @0x76c004b0a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0x76bb7b3b000 @0x76bfbc6e740:
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0x76bb7b3b800 @0x76b8c3331b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0x76c1ede3400 @0x76bbadbc950: [/usr/lib/libc.so.79.0]
doing dtors obj 0x76c1ede3000 @0x76c333c5a40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0x76bdc238800 @0x76c0159b340: [/usr/lib/libm.so.9.0]
251.92 real 251.96 user 0.19 sys
doing dtors
doing dtors obj 0xf0ae0f94c00 @0xf0b5ec96950: [/usr/lib/libc.so.79.0]
== after ==
doing dtors obj 0xa6021425000 @0xa60bf833a90: [/usr/local/lib/libiconv.so.6.0]
doing dtors
doing dtors obj 0xa6021425800 @0xa603fca0740:
[/usr/local/lib/libpython2.7.so.0.0]
doing dtors obj 0xa6034d7e800 @0xa60c0c911b0: [/usr/lib/libstdc++.so.57.0]
doing dtors obj 0xa60a5bcf400 @0xa604a3e0950: [/usr/lib/libc.so.79.0]
doing dtors obj 0xa60a5bcf000 @0xa60eb3eba40: [/usr/lib/libutil.so.12.1]
doing dtors obj 0xa6021425400 @0xa610ba86340: [/usr/lib/libm.so.9.0]
1.49 real 1.24 user 0.22 sys
doing dtors
doing dtors obj 0x4e7a8e11c00 @0x4e767f81950: [/usr/lib/libc.so.79.0]
(with wip samba-4.1.18)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
openssl.1: two misspellings
Index: usr.bin/openssl/openssl.1 === RCS file: /cvs/src/usr.bin/openssl/openssl.1,v retrieving revision 1.13 diff -u -p -r1.13 openssl.1 --- usr.bin/openssl/openssl.1 28 Feb 2015 21:51:56 - 1.13 +++ usr.bin/openssl/openssl.1 18 Jun 2015 10:21:53 - @@ -5509,7 +5509,7 @@ form, where file may be an algorithm parameter file, created by the .Cm genpkey -genparam -command or an X.509 certificate for a key with approriate algorithm. +command or an X.509 certificate for a key with appropriate algorithm. .Pp .Ar param : Ns Ar file generates a key using the parameter file or certificate @@ -7499,7 +7499,7 @@ Expects a signed mail message on input a Both clear text and opaque signing is supported. .El .Pp -The reamaining options are as follows: +The remaining options are as follows: .Bl -tag -width .It Xo .Fl aes128 | aes192 | aes256 | des |
ed(1): keep custom prompt string that was specified by -p
Here's a silly ed(1) session:
$ ed -p :
: P
P
*q
$
Notice how the prompt string changed from the custom prompt : to
the default prompt *.
This behavior seems to contradict both the man page and POSIX:
From ed(1):
-p string Specifies a command prompt. This may be toggled on and off
with the P command.
From POSIX:
The P command shall cause ed to prompt with an asterisk ('*') (or
string, if -p is specified) for all subsequent commands. The P command
alternatively shall turn this mode on and off; it shall be initially on
if the -p option is specified; otherwise, off.
With the patch below, the above session becomes
$ ed -p :
: P
P
: q
$
which, I believe, is closer to both the documentation and POSIX.
This also matches the behavior of GNU Ed 1.10.
Index: bin/ed/main.c
===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.43
diff -u -p -r1.43 main.c
--- bin/ed/main.c 16 Jan 2015 06:39:32 - 1.43
+++ bin/ed/main.c 18 Jun 2015 10:33:21 -
@@ -110,7 +110,7 @@ top:
while ((c = getopt(argc, argv, p:sx)) != -1)
switch (c) {
case 'p': /* set prompt */
- prompt = optarg;
+ dps = prompt = optarg;
break;
case 's': /* run script */
scripted = 1;
