Re: event(3): add misssing prototypes / reorder
I think reordering and missing arguments etc is fine, but we shouldn't add the missing prototypes until we are adding documentation for them as well. Can you send a diff with just the fixes for the current prototypes first? Thanks On Tue, Feb 17, 2015 at 10:55:38PM +0100, Fabian Raetz wrote: > Hi tech@, > > below is a diff which > > 1) adds the following prototypes from event.h to event(3): > - event_reinit > - event_set_log_callback > - event_get_version > - event_get_method > > - event_base_new > - event_base_priority_init > > - bufferevent_priority_set > - bufferevent_setcb > - bufferevent_setfd > - bufferevent_setwatermark > > 2) I wasn't quite sure where to place them and i ended up with a little >reordering of the present prototypes. >Prototypes are now sorted loosely after their corresponding >chapters within event(3). > > 3) sprinkled some missing const keywords on timeval arguments. > > 4) sprinkled some missing argument names. > > > I'm planning to document these functions if this will get commited. > > Comments? ;) > > > Regards, > Fabian > > diff --git a/lib/libevent/Makefile b/lib/libevent/Makefile > index f1226a2..89bdf91 100644 > --- a/lib/libevent/Makefile > +++ b/lib/libevent/Makefile > @@ -8,25 +8,13 @@ SRCS= buffer.c evbuffer.c event.c event_tagging.c > evutil.c kqueue.c \ > HDRS=event.h evutil.h > MAN= event.3 evbuffer_new.3 > MLINKS= event.3 event_init.3 \ > + event.3 event_reinit.3 \ > event.3 event_dispatch.3 \ > - event.3 event_loop.3 \ > - event.3 event_loopexit.3 \ > - event.3 event_loopbreak.3 \ > event.3 event_set.3 \ > - event.3 event_base_dispatch.3 \ > - event.3 event_base_loop.3 \ > - event.3 event_base_loopexit.3 \ > - event.3 event_base_loopbreak.3 \ > - event.3 event_base_set.3 \ > - event.3 event_base_free.3 \ > event.3 event_add.3 \ > event.3 event_del.3 \ > - event.3 event_once.3 \ > - event.3 event_base_once.3 \ > event.3 event_pending.3 \ > event.3 event_initialized.3 \ > - event.3 event_priority_init.3 \ > - event.3 event_priority_set.3 \ > event.3 evtimer_set.3 \ > event.3 evtimer_add.3 \ > event.3 evtimer_del.3 \ > @@ -37,17 +25,40 @@ MLINKS= event.3 event_init.3 \ > event.3 signal_del.3 \ > event.3 signal_pending.3 \ > event.3 signal_initialized.3 \ > + event.3 event_once.3 \ > + event.3 event_loop.3 \ > + event.3 event_loopexit.3 \ > + event.3 event_loopbreak.3 \ > + event.3 event_asr_run.3 \ > + event.3 event_asr_abort.3 \ > + event.3 event_priority_init.3 \ > + event.3 event_priority_set.3 \ > + event.3 event_set_log_callback.3 \ > + event.3 event_get_version.3 \ > + event.3 event_get_method.3 \ > + event.3 event_base_new.3 \ > + event.3 event_base_dispatch.3 \ > + event.3 event_base_loop.3 \ > + event.3 event_base_loopexit.3 \ > + event.3 event_base_loopbreak.3 \ > + event.3 event_base_set.3 \ > + event.3 event_base_once.3 \ > + event.3 event_base_free.3 \ > + event.3 event_base_get_method.3 \ > + event.3 event_base_priority_init.3 \ > + event.3 bufferevent_base_set.3 \ > event.3 bufferevent_new.3 \ > + event.3 bufferevent_priority_set.3 \ > event.3 bufferevent_free.3 \ > + event.3 bufferevent_setcb.3 \ > + event.3 bufferevent_setfd.3 \ > event.3 bufferevent_write.3 \ > event.3 bufferevent_write_buffer.3 \ > event.3 bufferevent_read.3 \ > event.3 bufferevent_enable.3 \ > event.3 bufferevent_disable.3 \ > event.3 bufferevent_settimeout.3 \ > - event.3 bufferevent_base_set.3 \ > - event.3 event_asr_run.3 \ > - event.3 event_asr_abort.3 \ > + event.3 bufferevent_setwatermark.3 \ > evbuffer_new.3 evbuffer_free.3 \ > evbuffer_new.3 evbuffer_setcb.3 \ > evbuffer_new.3 evbuffer_expand.3 \ > diff --git a/lib/libevent/event.3 b/lib/libevent/event.3 > index 7354b1a..29e338b 100644 > --- a/lib/libevent/event.3 > +++ b/lib/libevent/event.3 > @@ -28,25 +28,13 @@ > .Os > .Sh NAME > .Nm event_init , > +.Nm event_reinit , > .Nm event_dispatch , > -.Nm event_loop , > -.Nm event_loopexit , > -.Nm event_loopbreak , > .Nm event_set , > -.Nm event_base_dispatch , > -.Nm event_base_loop , > -.Nm event_base_loopexit , > -.Nm event_base_loopbreak , > -.Nm event_base_set , > -.Nm event_base_free , > .Nm event_add , > .Nm event_del , > -.Nm event_once , > -.Nm event_base_once , > .Nm event_pending , > .Nm event_initialized , > -.Nm event_priority_init , > -.Nm event_priority_set , > .Nm evtimer_set , > .Nm evtimer_add , > .Nm evtimer_del , > @@ -57,17 +45,40 @@ > .Nm signal_del , > .Nm signal_pending , > .Nm signal_initialized , > +.Nm event_once , > +.Nm event_loop , > +.Nm event_loopexit , > +.Nm event_loopbreak , > +.Nm event_asr_run , > +.Nm event_asr_abort, > +.Nm event_priority_init , >
Re: ksh version lies
On 2015-02-17 08:06 PM, John Merriam wrote: I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. Jumping in late in the conversation... This is not an academic point; as an ISV, I've had to do this sort of thing in the past, and will have to do so again in the future. There is no "standard" or universal way to detect what version of what shell happened to get invoked on what operating system, so an ISV must rely on tricks and silliness like checking the version string to make what amounts to an educated guess. For example, I have a customer that must run a specific (non-current) version of HP-UX due to hard dependencies in a mission-critical line-of-business app. Yes, that means there's a foundational problem, but it would cost ~$100M to fix now. Not going to happen. "Report the bug to the author/maintainer" is all very well, but HP isn't going to issue a patch for an old version of HP-UX just because one customer complains about /bin/ksh behaving badly. (Actually, they very well might, given sufficient financial incentive, but that's another story altogether...) Meanwhile, portable shell scripts must continue to run - portably - across multiple OSes. Array handling is the big bugbear I run into; if I can handle arrays inside the shell, I don't have to resort to using tmpfiles and fork/exec'ing multiple external utilities to simulate the functionality. Which means, firstly, determining if I'm inside something ksh-like or bash-like, or if I'm running in a simple POSIX shell. There are virtually no safe assumptions that can be made in portable shell scripting - how was the script invoked? Sourced? Hash-bang? Explicit "/bin/sh script" invocation? It's a mess, despite POSIX' attempt to unify things; the choice is to either code for lowest-common-denominator, which typically results in payloads up to 10x larger and that run up to 10x slower, or to probe for advanced features and exit cleanly and safely if they're absent. -- -Adam Thompson athom...@athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax
Re: ksh version lies
On 2/17/2015 7:40 PM, Ted Unangst wrote: Jérémie Courrèges-Anglas wrote: "Ted Unangst" writes: [...] So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What does one do differently if that string is present or missing? sigh pdksh is not the same thing as ksh88 or ksh93. And not the same thing as mksh, which has grew features since it was based on pdksh from the OpenBSD tree. And you may want to avoid known problems in some of those, or use known nice features in others, whether it is in scripts or your dotfiles. But for this obviously you have to know which shell you're using. Your proposal to remove the variable or to change significantly its content breaks other people's way to use ksh. I'm asking specifically what those features are. Well, good luck with that. As things stand, we need to make a list of features *not* to implement, lest people's version tests become incorrect. Are you genuinely afraid that people won't be able to use the features you plan to implement in ksh? Do you actually think that third-party shell developers out there have stopped implementing features just because ill-oriented users may make bad uses of $WHATEVERSH_VERSION? In short, I think KSH_VERSION encompasses all the badness of web pages that check USER_AGENT. We should not perpetuatate such silliness. Feel free to send this straight to the circular file, but I have been watching this discussion with some interest and figured I would add a couple cents to it. From what I can see the options are: 1) Leave OpenBSD ksh version string as it is which references only PD KSH. 2) Remove it completely as proposed by tedu. 3) Change it to something else not referencing PD KSH like "OpenBSD ksh 5.7". 4) Change it to something else referencing PD KSH like "OpenBSD ksh 5.7; based on PD KSH v5.2.14" as proposed by djm. 5) Change it to something that does not include version numbers like "OpenBSD ksh" or "OpenBSD ksh based on PD KSH". I think option one is the least preferable if it isn't really PD KSH anymore. Options 2 and 5 are set and forget. Options 3 and 4 need to be bumped for each ksh/OpenBSD release. Personally I don't care what $???_VERSION is (or if it exists at all) in a shell I'm writing for. If I'm using #!/bin/sh, I'll stick to standard Bourne shell. If it's #!/bin/bash, it'll be Bash. If it's #!/bin/ksh, I'll try to stick with features common to all Korn shell variants. I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. -- John Merriam
Re: enable jumbos on newer re(4) devices
On Fri, Jan 23, 2015 at 11:26:53AM +1000, David Gwynne wrote:
> a compromise could be to advertise checksum offload to the stack,
> pass it on to the hardware for small frames but have the driver do
> it in software for the big ones?
greetings,
below are two diffs. the first allows re(4) chips to handle checksums
in software for large packets. this allows the chip to advertise hardware
checksums for regular packets and do it manually for jumbos, which the
the hardware cannot do properly (at least for 8168D and 8168E chips, which
i've tested).
the second diff is the same as the previous jumbo diff i sent through,
but does not disable hw csums for the 8168D and 8168E chips.
the first will do nothing without the second, but the diff's goals
are different enough that two make sense.
thanks dlg@ for the original concept and for hammering square pegs into
my round brain. feedback appreciated.
Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.175
diff -u -p -r1.175 re.c
--- re.c9 Feb 2015 03:09:57 - 1.175
+++ re.c18 Feb 2015 01:35:32 -
@@ -128,6 +128,8 @@
#include
#include
+#include
+#include
#include
#if NVLAN > 0
@@ -194,6 +196,8 @@ voidre_setup_intr(struct rl_softc *, in
intre_wol(struct ifnet*, int);
#endif
+void in_delayed_cksum(struct mbuf *);
+
struct cfdriver re_cd = {
0, "re", DV_IFNET
};
@@ -1601,7 +1605,10 @@ int
re_encap(struct rl_softc *sc, struct mbuf *m, int *idx)
{
bus_dmamap_tmap;
+ struct mbuf *mp, mh;
int error, seg, nsegs, uidx, startidx, curidx, lastidx, pad;
+ int off;
+ struct ip *ip;
struct rl_desc *d;
u_int32_t cmdstat, vlanctl = 0, csum_flags = 0;
struct rl_txq *txq;
@@ -1618,6 +1625,27 @@ re_encap(struct rl_softc *sc, struct mbu
* is requested. Otherwise, RL_TDESC_CMD_TCPCSUM/
* RL_TDESC_CMD_UDPCSUM does not take affect.
*/
+
+ if ((sc->rl_flags & RL_FLAG_JUMBOV2) &&
+ m->m_pkthdr.len > RL_MTU &&
+ (m->m_pkthdr.csum_flags &
+ (M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT)) != 0) {
+ mp = m_getptr(m, ETHER_HDR_LEN, &off);
+ mh.m_flags = 0;
+ mh.m_data = mtod(mp, caddr_t) + off;
+ mh.m_next = mp->m_next;
+ mh.m_pkthdr.len = mp->m_pkthdr.len - ETHER_HDR_LEN;
+ mh.m_len = mp->m_len - off;
+ ip = (struct ip *)mh.m_data;
+
+ if (m->m_pkthdr.csum_flags & M_IPV4_CSUM_OUT)
+ ip->ip_sum = in_cksum(&mh, sizeof(struct ip));
+ if (m->m_pkthdr.csum_flags & (M_TCP_CSUM_OUT|M_UDP_CSUM_OUT))
+ in_delayed_cksum(&mh);
+
+ m->m_pkthdr.csum_flags &=
+ ~(M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT);
+ }
if ((m->m_pkthdr.csum_flags &
(M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT)) != 0) {
Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.175
diff -u -p -r1.175 re.c
--- re.c9 Feb 2015 03:09:57 - 1.175
+++ re.c18 Feb 2015 01:41:03 -
@@ -171,6 +171,8 @@ voidre_watchdog(struct ifnet *);
intre_ifmedia_upd(struct ifnet *);
void re_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+void re_set_jumbo(struct rl_softc *);
+
void re_eeprom_putbyte(struct rl_softc *, int);
void re_eeprom_getword(struct rl_softc *, int, u_int16_t *);
void re_read_eeprom(struct rl_softc *, caddr_t, int, int);
@@ -206,6 +208,10 @@ struct cfdriver re_cd = {
CSR_WRITE_1(sc, RL_EECMD, \
CSR_READ_1(sc, RL_EECMD) & ~x)
+#define RL_FRAMELEN(mtu) \
+ (mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + \
+ ETHER_VLAN_ENCAP_LEN)
+
static const struct re_revision {
u_int32_t re_chipid;
const char *re_name;
@@ -1022,8 +1028,10 @@ re_attach(struct rl_softc *sc, const cha
/* Create DMA maps for RX buffers */
for (i = 0; i < RL_RX_DESC_CNT; i++) {
- error = bus_dmamap_create(sc->sc_dmat, MCLBYTES, 1, MCLBYTES,
- 0, 0, &sc->rl_ldata.rl_rxsoft[i].rxs_dmamap);
+ error = bus_dmamap_create(sc->sc_dmat,
+ RL_FRAMELEN(sc->rl_max_mtu), 1,
+ RL_FRAMELEN(sc->rl_max_mtu), 0, 0,
+ &sc->rl_ldata.rl_rxsoft[i].rxs_dmamap);
if (error) {
printf("%s: can't create DMA map for RX\n",
sc->sc_dev.dv_xname);
@@ -1038,8 +1046,7 @@ re_attach(struct rl_softc *sc, const cha
ifp->if_ioctl = re_ioctl;
ifp->if_start = re_start;
if
re(4) reads the pci-e max packet size wrongly
it looks like it reads the DCSR register and then keeps everything
except the MPS field.
this might cause it to erronously consider the mps to be much bigger
than 2048, which in turn could prevent it from setting it correctly.
i dont actually have one of these chips. can someone give it a spin?
Index: if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_re_pci.c
--- if_re_pci.c 26 Jan 2015 09:58:47 - 1.45
+++ if_re_pci.c 18 Feb 2015 01:12:22 -
@@ -182,7 +182,7 @@ re_pci_attach(struct device *parent, str
/* Set PCIe maximum read request size to 2048. */
reg = pci_conf_read(pa->pa_pc, pa->pa_tag,
sc->rl_expcap + PCI_PCIE_DCSR);
- reg = (reg & ~PCI_PCIE_DCSR_MPS);
+ reg &= PCI_PCIE_DCSR_MPS;
reg >>= 12;
rrs = (1 << (reg + 7));
if (rrs < 2048) {
Re: ksh version lies
Jérémie Courrèges-Anglas wrote: > "Ted Unangst" writes: > > [...] > > >> > So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What > >> > does > >> > one do differently if that string is present or missing? > >> > >> sigh > >> > >> pdksh is not the same thing as ksh88 or ksh93. And not the same thing as > >> mksh, which has grew features since it was based on pdksh from the > >> OpenBSD tree. And you may want to avoid known problems in some of those, > >> or use known nice features in others, whether it is in scripts or your > >> dotfiles. But for this obviously you have to know which shell you're > >> using. > >> > >> Your proposal to remove the variable or to change significantly its > >> content breaks other people's way to use ksh. > > > > I'm asking specifically what those features are. > > Well, good luck with that. > > > As things stand, we need to > > make a list of features *not* to implement, lest people's version > > tests become incorrect. > > Are you genuinely afraid that people won't be able to use the features > you plan to implement in ksh? Do you actually think that third-party > shell developers out there have stopped implementing features just > because ill-oriented users may make bad uses of $WHATEVERSH_VERSION? In short, I think KSH_VERSION encompasses all the badness of web pages that check USER_AGENT. We should not perpetuatate such silliness.
Re: ksh version lies
"Ted Unangst" writes: [...] >> > So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What >> > does >> > one do differently if that string is present or missing? >> >> sigh >> >> pdksh is not the same thing as ksh88 or ksh93. And not the same thing as >> mksh, which has grew features since it was based on pdksh from the >> OpenBSD tree. And you may want to avoid known problems in some of those, >> or use known nice features in others, whether it is in scripts or your >> dotfiles. But for this obviously you have to know which shell you're >> using. >> >> Your proposal to remove the variable or to change significantly its >> content breaks other people's way to use ksh. > > I'm asking specifically what those features are. Well, good luck with that. > As things stand, we need to > make a list of features *not* to implement, lest people's version > tests become incorrect. Are you genuinely afraid that people won't be able to use the features you plan to implement in ksh? Do you actually think that third-party shell developers out there have stopped implementing features just because ill-oriented users may make bad uses of $WHATEVERSH_VERSION? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ksh version lies
Jérémie Courrèges-Anglas wrote: > "Ted Unangst" writes: > > > Jérémie Courrèges-Anglas wrote: > >> Tristan Le Guern writes: > >> > >> > On 02/16/2015 05:22 PM, Todd C. Miller wrote: > >> >> There are scripts that use KSH_VERSION to determine whether they > >> >> are being run under ksh or a Bourne shell. That seems like a > >> >> reasonable thing to do. I don't really care what the version > >> >> number is set to. Using the OpenBSD version seems reasonable > >> >> and could be generated at build time. > >> > > >> > Same thing for me: I don't care about the content of this variable, just > >> > about its presence. The same for BASH_VERSION or ZSH_VERSION. > >> > >> Maybe you don't, but our ksh isn't the only ksh around. > >> > >> Removing "PD KSH" from KSH_VERSION would just break scripts that probe > >> the content of this variable. > > > > So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What > > does > > one do differently if that string is present or missing? > > sigh > > pdksh is not the same thing as ksh88 or ksh93. And not the same thing as > mksh, which has grew features since it was based on pdksh from the > OpenBSD tree. And you may want to avoid known problems in some of those, > or use known nice features in others, whether it is in scripts or your > dotfiles. But for this obviously you have to know which shell you're > using. > > Your proposal to remove the variable or to change significantly its > content breaks other people's way to use ksh. I'm asking specifically what those features are. As things stand, we need to make a list of features *not* to implement, lest people's version tests become incorrect.
Re: ksh version lies
"Ted Unangst" writes: > Jérémie Courrèges-Anglas wrote: >> Tristan Le Guern writes: >> >> > On 02/16/2015 05:22 PM, Todd C. Miller wrote: >> >> There are scripts that use KSH_VERSION to determine whether they >> >> are being run under ksh or a Bourne shell. That seems like a >> >> reasonable thing to do. I don't really care what the version >> >> number is set to. Using the OpenBSD version seems reasonable >> >> and could be generated at build time. >> > >> > Same thing for me: I don't care about the content of this variable, just >> > about its presence. The same for BASH_VERSION or ZSH_VERSION. >> >> Maybe you don't, but our ksh isn't the only ksh around. >> >> Removing "PD KSH" from KSH_VERSION would just break scripts that probe >> the content of this variable. > > So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What does > one do differently if that string is present or missing? sigh pdksh is not the same thing as ksh88 or ksh93. And not the same thing as mksh, which has grew features since it was based on pdksh from the OpenBSD tree. And you may want to avoid known problems in some of those, or use known nice features in others, whether it is in scripts or your dotfiles. But for this obviously you have to know which shell you're using. Your proposal to remove the variable or to change significantly its content breaks other people's way to use ksh. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ksh version lies
Jérémie Courrèges-Anglas wrote: > Tristan Le Guern writes: > > > On 02/16/2015 05:22 PM, Todd C. Miller wrote: > >> There are scripts that use KSH_VERSION to determine whether they > >> are being run under ksh or a Bourne shell. That seems like a > >> reasonable thing to do. I don't really care what the version > >> number is set to. Using the OpenBSD version seems reasonable > >> and could be generated at build time. > > > > Same thing for me: I don't care about the content of this variable, just > > about its presence. The same for BASH_VERSION or ZSH_VERSION. > > Maybe you don't, but our ksh isn't the only ksh around. > > Removing "PD KSH" from KSH_VERSION would just break scripts that probe > the content of this variable. So let's return to the top. What does "PD KSH" in KSH_VERSION mean? What does one do differently if that string is present or missing?
event(3): add misssing prototypes / reorder
Hi tech@, below is a diff which 1) adds the following prototypes from event.h to event(3): - event_reinit - event_set_log_callback - event_get_version - event_get_method - event_base_new - event_base_priority_init - bufferevent_priority_set - bufferevent_setcb - bufferevent_setfd - bufferevent_setwatermark 2) I wasn't quite sure where to place them and i ended up with a little reordering of the present prototypes. Prototypes are now sorted loosely after their corresponding chapters within event(3). 3) sprinkled some missing const keywords on timeval arguments. 4) sprinkled some missing argument names. I'm planning to document these functions if this will get commited. Comments? ;) Regards, Fabian diff --git a/lib/libevent/Makefile b/lib/libevent/Makefile index f1226a2..89bdf91 100644 --- a/lib/libevent/Makefile +++ b/lib/libevent/Makefile @@ -8,25 +8,13 @@ SRCS= buffer.c evbuffer.c event.c event_tagging.c evutil.c kqueue.c \ HDRS= event.h evutil.h MAN= event.3 evbuffer_new.3 MLINKS=event.3 event_init.3 \ + event.3 event_reinit.3 \ event.3 event_dispatch.3 \ - event.3 event_loop.3 \ - event.3 event_loopexit.3 \ - event.3 event_loopbreak.3 \ event.3 event_set.3 \ - event.3 event_base_dispatch.3 \ - event.3 event_base_loop.3 \ - event.3 event_base_loopexit.3 \ - event.3 event_base_loopbreak.3 \ - event.3 event_base_set.3 \ - event.3 event_base_free.3 \ event.3 event_add.3 \ event.3 event_del.3 \ - event.3 event_once.3 \ - event.3 event_base_once.3 \ event.3 event_pending.3 \ event.3 event_initialized.3 \ - event.3 event_priority_init.3 \ - event.3 event_priority_set.3 \ event.3 evtimer_set.3 \ event.3 evtimer_add.3 \ event.3 evtimer_del.3 \ @@ -37,17 +25,40 @@ MLINKS= event.3 event_init.3 \ event.3 signal_del.3 \ event.3 signal_pending.3 \ event.3 signal_initialized.3 \ + event.3 event_once.3 \ + event.3 event_loop.3 \ + event.3 event_loopexit.3 \ + event.3 event_loopbreak.3 \ + event.3 event_asr_run.3 \ + event.3 event_asr_abort.3 \ + event.3 event_priority_init.3 \ + event.3 event_priority_set.3 \ + event.3 event_set_log_callback.3 \ + event.3 event_get_version.3 \ + event.3 event_get_method.3 \ + event.3 event_base_new.3 \ + event.3 event_base_dispatch.3 \ + event.3 event_base_loop.3 \ + event.3 event_base_loopexit.3 \ + event.3 event_base_loopbreak.3 \ + event.3 event_base_set.3 \ + event.3 event_base_once.3 \ + event.3 event_base_free.3 \ + event.3 event_base_get_method.3 \ + event.3 event_base_priority_init.3 \ + event.3 bufferevent_base_set.3 \ event.3 bufferevent_new.3 \ + event.3 bufferevent_priority_set.3 \ event.3 bufferevent_free.3 \ + event.3 bufferevent_setcb.3 \ + event.3 bufferevent_setfd.3 \ event.3 bufferevent_write.3 \ event.3 bufferevent_write_buffer.3 \ event.3 bufferevent_read.3 \ event.3 bufferevent_enable.3 \ event.3 bufferevent_disable.3 \ event.3 bufferevent_settimeout.3 \ - event.3 bufferevent_base_set.3 \ - event.3 event_asr_run.3 \ - event.3 event_asr_abort.3 \ + event.3 bufferevent_setwatermark.3 \ evbuffer_new.3 evbuffer_free.3 \ evbuffer_new.3 evbuffer_setcb.3 \ evbuffer_new.3 evbuffer_expand.3 \ diff --git a/lib/libevent/event.3 b/lib/libevent/event.3 index 7354b1a..29e338b 100644 --- a/lib/libevent/event.3 +++ b/lib/libevent/event.3 @@ -28,25 +28,13 @@ .Os .Sh NAME .Nm event_init , +.Nm event_reinit , .Nm event_dispatch , -.Nm event_loop , -.Nm event_loopexit , -.Nm event_loopbreak , .Nm event_set , -.Nm event_base_dispatch , -.Nm event_base_loop , -.Nm event_base_loopexit , -.Nm event_base_loopbreak , -.Nm event_base_set , -.Nm event_base_free , .Nm event_add , .Nm event_del , -.Nm event_once , -.Nm event_base_once , .Nm event_pending , .Nm event_initialized , -.Nm event_priority_init , -.Nm event_priority_set , .Nm evtimer_set , .Nm evtimer_add , .Nm evtimer_del , @@ -57,17 +45,40 @@ .Nm signal_del , .Nm signal_pending , .Nm signal_initialized , +.Nm event_once , +.Nm event_loop , +.Nm event_loopexit , +.Nm event_loopbreak , +.Nm event_asr_run , +.Nm event_asr_abort, +.Nm event_priority_init , +.Nm event_priority_set , +.Nm event_set_log_callback , +.Nm event_get_version , +.Nm event_get_method , +.Nm event_base_new , +.Nm event_base_dispatch , +.Nm event_base_loop , +.Nm event_base_loopexit , +.Nm event_base_loopbreak , +.Nm event_base_set , +.Nm event_base_once , +.Nm event_base_free , +.Nm event_base_get_method , +.Nm event_base_priority_init , +.Nm bufferevent_base_set , .Nm bufferevent_new , +.Nm bufferevent_priority_set , .Nm bufferevent_free , +.Nm bufferev
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
On 02/17/15 08:52, Ingo Schwarze wrote: ... Shutting down stuff like pflogd and syslogd before the system is actually going down might even be harmful. you mean...like maybe when doing an upgrade where the newly installed binaries are not compatible with the running kernel? Considering the number of times base daemons have been shut down by halting the kernel and the lack of problems caused by this? no...I don't think this is a good idea at all. Nick.
Re: ksh version lies
Tristan Le Guern writes: > On 02/16/2015 05:22 PM, Todd C. Miller wrote: >> There are scripts that use KSH_VERSION to determine whether they >> are being run under ksh or a Bourne shell. That seems like a >> reasonable thing to do. I don't really care what the version >> number is set to. Using the OpenBSD version seems reasonable >> and could be generated at build time. > > Same thing for me: I don't care about the content of this variable, just > about its presence. The same for BASH_VERSION or ZSH_VERSION. Maybe you don't, but our ksh isn't the only ksh around. Removing "PD KSH" from KSH_VERSION would just break scripts that probe the content of this variable. ... -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ksh version lies
On 02/16/2015 05:22 PM, Todd C. Miller wrote: > There are scripts that use KSH_VERSION to determine whether they > are being run under ksh or a Bourne shell. That seems like a > reasonable thing to do. I don't really care what the version > number is set to. Using the OpenBSD version seems reasonable > and could be generated at build time. Same thing for me: I don't care about the content of this variable, just about its presence. The same for BASH_VERSION or ZSH_VERSION.
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
> I see how a clean shutdown might matter for, say, postgres. > But what is the point in shutting down cron, sshd, ntpd, or unbound > right before the system is going down anyway? > > Shutting down stuff like pflogd and syslogd before the system > is actually going down might even be harmful. > > If it turns out there are one or two base daemons where shutting > them down by running the rc.d(8) script is better than what > currently happens, those one or two could get special handling > in /etc/rc itself. But so far, i don't remember that anybody ever > saw a specific need for any of them. I fully agree. -- Antoine
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
Hi, Antoine Jacoutot wrote on Tue, Feb 17, 2015 at 02:24:56PM +0100: > On Tue, Feb 17, 2015 at 01:20:03PM +, Craig Skinner wrote: >> stopping base daemons: cron spamlogd spamd sshd ntpd unbound >> nsd pflogd syslogd. >> syncing disks... done > I cooked a patch for that a few months ago (actually >1 year ago iirc) > but we decided not to go down that road for a reason I cannot recall > right now. I guess the point was that it's nothing but useless complexity. I see how a clean shutdown might matter for, say, postgres. But what is the point in shutting down cron, sshd, ntpd, or unbound right before the system is going down anyway? Shutting down stuff like pflogd and syslogd before the system is actually going down might even be harmful. If it turns out there are one or two base daemons where shutting them down by running the rc.d(8) script is better than what currently happens, those one or two could get special handling in /etc/rc itself. But so far, i don't remember that anybody ever saw a specific need for any of them. Yours, Ingo
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
On 2015-02-17 Tue 14:24 PM |, Antoine Jacoutot wrote: > On Tue, Feb 17, 2015 at 01:20:03PM +, Craig Skinner wrote: > > Produces (on 5.6 release) - with start up order reversed: > > > > # halt -p > > stopping package daemons: greyscanner postfix sshguard. > > stopping base daemons: cron spamlogd spamd sshd ntpd unbound nsd pflogd > > syslogd. > > syncing disks... done > > I cooked a patch for that a few months ago (actually >1 year ago iirc) but we > decided not to go down that road for a reason I cannot recall right now. > And I was using the information from /var/run/rc.d instead to know what to > shutdown exactly instead of greping /etc/rc. > Would the reverse boot order be maintained by looking at items in /var/run/rc.d? -- The way to make a small fortune in the commodities market is to start with a large fortune.
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
On Tue, Feb 17, 2015 at 01:20:03PM +, Craig Skinner wrote:
> Produces (on 5.6 release) - with start up order reversed:
>
> # halt -p
> stopping package daemons: greyscanner postfix sshguard.
> stopping base daemons: cron spamlogd spamd sshd ntpd unbound nsd pflogd
> syslogd.
> syncing disks... done
I cooked a patch for that a few months ago (actually >1 year ago iirc) but we
decided not to go down that road for a reason I cannot recall right now.
And I was using the information from /var/run/rc.d instead to know what to
shutdown exactly instead of greping /etc/rc.
> Index: rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.447
> diff -u -p -r1.447 rc
> --- rc22 Jan 2015 19:00:24 - 1.447
> +++ rc17 Feb 2015 13:16:05 -
> @@ -131,17 +131,42 @@ fill_baddynamic()
> }
> }
>
> -start_daemon()
> +start_stop_daemon()
> {
> - local _n
> - for _n; do
> - eval _do=\${${_n}_flags}
> - if [ X"${_do}" != X"NO" ]; then
> - /etc/rc.d/${_n} start
> - fi
> + local _start_stop=$1
> + local _daemon _daemon_script
> + shift
> +
> + for _daemon
> + do
> + eval _do=\${${_daemon}_flags}
> + [[ ${_do} == 'NO' ]] && continue
> +
> + _daemon_script="/etc/rc.d/${_daemon}"
> + [[ -e ${_daemon_script} ]] ||
> + {
> + print -n -- " ${_daemon}(absent)"
> + continue
> + }
> + [[ -x ${_daemon_script} ]] ||
> + {
> + print -n -- " ${_daemon}(inexecutable)"
> + continue
> + }
> + ${_daemon_script} ${_start_stop}
> done
> }
>
> +start_daemon()
> +{
> + start_stop_daemon 'start' $*
> +}
> +
> +stop_daemon()
> +{
> + start_stop_daemon 'stop' $*
> +}
> +
> make_keys()
> {
> if [ ! -f /etc/isakmpd/private/local.key ]; then
> @@ -269,12 +294,24 @@ if [ X"$1" = X"shutdown" ]; then
> while [ -n "${pkg_scripts}" ]; do
> _r=${pkg_scripts##* }
> pkg_scripts=${pkg_scripts%%*( )${_r}}
> - [ -x /etc/rc.d/${_r} ] && /etc/rc.d/${_r} stop
> + stop_daemon ${_r}
> done
> echo '.'
> fi
>
> [ -f /etc/rc.shutdown ] && sh /etc/rc.shutdown
> +
> + print -n 'stopping base daemons:'
> + _daemons=$(egrep "start_daemon[[:blank:]][[:alnum:]]" /etc/rc |
> + sed s"/start_daemon//")
> + while [[ -n ${_daemons} ]]
> + do
> + _daemon=${_daemons##* }
> + _daemons=${_daemons%%*( )${_daemon}}
> + stop_daemon ${_daemon}
> + done
> + print '.'
> +
> else
> echo single user: not running shutdown scripts
> fi
> @@ -513,11 +550,7 @@ rm -f /etc/rc.firsttime.run
> if [ -n "${pkg_scripts}" ]; then
> echo -n 'starting package daemons:'
> for _r in $pkg_scripts; do
> - if [ -x /etc/rc.d/${_r} ]; then
> - start_daemon ${_r}
> - else
> - echo -n " ${_r}(absent)"
> - fi
> + start_daemon ${_r}
> done
> echo '.'
> fi
>
--
Antoine
[DIFF] /etc/rc: gracefully shut down base daemons too
Produces (on 5.6 release) - with start up order reversed:
# halt -p
stopping package daemons: greyscanner postfix sshguard.
stopping base daemons: cron spamlogd spamd sshd ntpd unbound nsd pflogd syslogd.
syncing disks... done
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.447
diff -u -p -r1.447 rc
--- rc 22 Jan 2015 19:00:24 - 1.447
+++ rc 17 Feb 2015 13:16:05 -
@@ -131,17 +131,42 @@ fill_baddynamic()
}
}
-start_daemon()
+start_stop_daemon()
{
- local _n
- for _n; do
- eval _do=\${${_n}_flags}
- if [ X"${_do}" != X"NO" ]; then
- /etc/rc.d/${_n} start
- fi
+ local _start_stop=$1
+ local _daemon _daemon_script
+ shift
+
+ for _daemon
+ do
+ eval _do=\${${_daemon}_flags}
+ [[ ${_do} == 'NO' ]] && continue
+
+ _daemon_script="/etc/rc.d/${_daemon}"
+ [[ -e ${_daemon_script} ]] ||
+ {
+ print -n -- " ${_daemon}(absent)"
+ continue
+ }
+ [[ -x ${_daemon_script} ]] ||
+ {
+ print -n -- " ${_daemon}(inexecutable)"
+ continue
+ }
+ ${_daemon_script} ${_start_stop}
done
}
+start_daemon()
+{
+ start_stop_daemon 'start' $*
+}
+
+stop_daemon()
+{
+ start_stop_daemon 'stop' $*
+}
+
make_keys()
{
if [ ! -f /etc/isakmpd/private/local.key ]; then
@@ -269,12 +294,24 @@ if [ X"$1" = X"shutdown" ]; then
while [ -n "${pkg_scripts}" ]; do
_r=${pkg_scripts##* }
pkg_scripts=${pkg_scripts%%*( )${_r}}
- [ -x /etc/rc.d/${_r} ] && /etc/rc.d/${_r} stop
+ stop_daemon ${_r}
done
echo '.'
fi
[ -f /etc/rc.shutdown ] && sh /etc/rc.shutdown
+
+ print -n 'stopping base daemons:'
+ _daemons=$(egrep "start_daemon[[:blank:]][[:alnum:]]" /etc/rc |
+ sed s"/start_daemon//")
+ while [[ -n ${_daemons} ]]
+ do
+ _daemon=${_daemons##* }
+ _daemons=${_daemons%%*( )${_daemon}}
+ stop_daemon ${_daemon}
+ done
+ print '.'
+
else
echo single user: not running shutdown scripts
fi
@@ -513,11 +550,7 @@ rm -f /etc/rc.firsttime.run
if [ -n "${pkg_scripts}" ]; then
echo -n 'starting package daemons:'
for _r in $pkg_scripts; do
- if [ -x /etc/rc.d/${_r} ]; then
- start_daemon ${_r}
- else
- echo -n " ${_r}(absent)"
- fi
+ start_daemon ${_r}
done
echo '.'
fi
Re: ftp less progress
On 02/17/15 09:07, Ted Unangst wrote:
It's sometimes helpful to run ftp -o - http://somwhat/ for debugging
purposes, but the progress bar gets in the way and makes it ugly. Even with -V
to disable verbose, it still prints progress. Add -M (complement of -m) to
always turn off progress.
I'm always annoyed by the workarounds required to get the desired output
from this program. Even if possibly not perfect, I'm sure this makes the
situation better, so ok halex@.
/Alexander
Index: ftp.1
===
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.96
diff -u -p -r1.96 ftp.1
--- ftp.1 31 Jan 2015 19:33:45 - 1.96
+++ ftp.1 17 Feb 2015 08:05:06 -
@@ -38,7 +38,7 @@
.Nd Internet file transfer program
.Sh SYNOPSIS
.Nm ftp
-.Op Fl 46AadEegimnptVv
+.Op Fl 46AadEegiMmnptVv
.Op Fl D Ar title
.Op Fl k Ar seconds
.Op Fl P Ar port
@@ -181,6 +181,11 @@ transfer.
By default,
.Nm
will send a byte every 60 seconds.
+.It Fl M
+Causes
+.Nm
+to never display the progress meter in cases where it would do
+so by default.
.It Fl m
Causes
.Nm
Index: main.c
===
RCS file: /cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.97
diff -u -p -r1.97 main.c
--- main.c 9 Feb 2015 08:24:21 - 1.97
+++ main.c 17 Feb 2015 08:04:14 -
@@ -202,7 +202,7 @@ main(volatile int argc, char *argv[])
httpuseragent = NULL;
while ((ch = getopt(argc, argv,
- "46AaCc:dD:Eegik:mno:pP:r:S:s:tU:vV")) != -1) {
+ "46AaCc:dD:Eegik:Mmno:pP:r:S:s:tU:vV")) != -1) {
switch (ch) {
case '4':
family = PF_INET;
@@ -267,6 +267,9 @@ main(volatile int argc, char *argv[])
optarg);
usage();
}
+ break;
+ case 'M':
+ progress = 0;
break;
case 'm':
progress = -1;
Re: ksh version lies
On 2015-02-16 Mon 09:22 AM |, Todd C. Miller wrote:
> There are scripts that use KSH_VERSION to determine whether they
> are being run under ksh or a Bourne shell. That seems like a
> reasonable thing to do. I don't really care what the version
> number is set to.
Korn scripts here that drive dump has a system that allows admins to
hook in per machine/partition scripts to shutdown databases, daemons,
before unmounting, for dumping.
They just check for ' KSH ' in $KSH_VERSION
Other scripts do this:
[[ -o sh ]] &&
{
print -u2 'Not Korn shell'
exit 70 #EX_SOFTWARE
}
Could there be an init set -o for ksh on, instead of $KSH_VERSION?
Re: unbound 1.5.2rc1
On 2015/02/17 01:01, Stuart Henderson wrote:
> This updates to the head of the unbound tree, adding Ilya Bakulin's code to
> support unbound-control over a unix domain socket rather than SSL. I don't
> see many standard cases needing the SSL socket any more, so I've removed
> the code from the rc.d script that automatically generates SSL keys when
> control-enable is used, if somebody wants to control from a remote machine
> they can always do this themselves.
>
> Any comments/OKs?
Brad suggested I split out the etc parts for this for separate discussion.
Rather than editing unbound.conf, another option might be to change the
code to allow using the unix socket by default. I'm reluctant to diverge
from upstream code as it's easier to miss during a merge, but perhaps we
could add an autoconf flag to allow setting this by default (which would
then be more palatable for inclusion in upstream code).
Index: etc/unbound.conf
===
RCS file: /cvs/src/etc/unbound.conf,v
retrieving revision 1.4
diff -u -p -r1.4 unbound.conf
--- etc/unbound.conf2 Apr 2014 21:43:30 - 1.4
+++ etc/unbound.conf17 Feb 2015 10:20:36 -
@@ -37,6 +37,11 @@ server:
#
#tcp-upstream: yes
+remote-control:
+ control-enable: yes
+ control-use-cert: no
+ control-interface: /var/run/unbound.sock
+
# Use an upstream forwarder (recursive resolver) for specific zones.
# Example addresses given below are public resolvers valid as of 2014/03.
#
Index: etc/rc.d/unbound
===
RCS file: /cvs/src/etc/rc.d/unbound,v
retrieving revision 1.2
diff -u -p -r1.2 unbound
--- etc/rc.d/unbound29 Dec 2014 11:17:43 - 1.2
+++ etc/rc.d/unbound17 Feb 2015 10:20:36 -
@@ -8,16 +8,9 @@ daemon_flags="-c /var/unbound/etc/unboun
. /etc/rc.d/rc.subr
pexp="unbound${daemon_flags:+ ${daemon_flags}}"
+rc_reload=NO
rc_pre() {
- if grep '^[[:space:]]*control-enable:[[:space:]]*yes' \
- /var/unbound/etc/unbound.conf > /dev/null 2>&1 && \
- ! [[ -f /var/unbound/etc/unbound_server.key ||
- -f /var/unbound/etc/unbound_server.pem ||
- -f /var/unbound/etc/unbound_control.key ||
- -f /var/unbound/etc/unbound_control.pem ]]; then
- /usr/sbin/unbound-control-setup 2> /dev/null
- fi
if grep '^[[:space:]]*auto-trust-anchor-file:' \
/var/unbound/etc/unbound.conf > /dev/null 2>&1; then
/usr/sbin/unbound-anchor -v || true
Re: ftp less progress
i like.
ok by me fwiw.
> On 17 Feb 2015, at 6:07 pm, Ted Unangst wrote:
>
> It's sometimes helpful to run ftp -o - http://somwhat/ for debugging
> purposes, but the progress bar gets in the way and makes it ugly. Even with -V
> to disable verbose, it still prints progress. Add -M (complement of -m) to
> always turn off progress.
>
>
> Index: ftp.1
> ===
> RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
> retrieving revision 1.96
> diff -u -p -r1.96 ftp.1
> --- ftp.1 31 Jan 2015 19:33:45 - 1.96
> +++ ftp.1 17 Feb 2015 08:05:06 -
> @@ -38,7 +38,7 @@
> .Nd Internet file transfer program
> .Sh SYNOPSIS
> .Nm ftp
> -.Op Fl 46AadEegimnptVv
> +.Op Fl 46AadEegiMmnptVv
> .Op Fl D Ar title
> .Op Fl k Ar seconds
> .Op Fl P Ar port
> @@ -181,6 +181,11 @@ transfer.
> By default,
> .Nm
> will send a byte every 60 seconds.
> +.It Fl M
> +Causes
> +.Nm
> +to never display the progress meter in cases where it would do
> +so by default.
> .It Fl m
> Causes
> .Nm
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/main.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 main.c
> --- main.c9 Feb 2015 08:24:21 - 1.97
> +++ main.c17 Feb 2015 08:04:14 -
> @@ -202,7 +202,7 @@ main(volatile int argc, char *argv[])
> httpuseragent = NULL;
>
> while ((ch = getopt(argc, argv,
> - "46AaCc:dD:Eegik:mno:pP:r:S:s:tU:vV")) != -1) {
> + "46AaCc:dD:Eegik:Mmno:pP:r:S:s:tU:vV")) != -1) {
> switch (ch) {
> case '4':
> family = PF_INET;
> @@ -267,6 +267,9 @@ main(volatile int argc, char *argv[])
> optarg);
> usage();
> }
> + break;
> + case 'M':
> + progress = 0;
> break;
> case 'm':
> progress = -1;
>
>
ftp less progress
It's sometimes helpful to run ftp -o - http://somwhat/ for debugging
purposes, but the progress bar gets in the way and makes it ugly. Even with -V
to disable verbose, it still prints progress. Add -M (complement of -m) to
always turn off progress.
Index: ftp.1
===
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.96
diff -u -p -r1.96 ftp.1
--- ftp.1 31 Jan 2015 19:33:45 - 1.96
+++ ftp.1 17 Feb 2015 08:05:06 -
@@ -38,7 +38,7 @@
.Nd Internet file transfer program
.Sh SYNOPSIS
.Nm ftp
-.Op Fl 46AadEegimnptVv
+.Op Fl 46AadEegiMmnptVv
.Op Fl D Ar title
.Op Fl k Ar seconds
.Op Fl P Ar port
@@ -181,6 +181,11 @@ transfer.
By default,
.Nm
will send a byte every 60 seconds.
+.It Fl M
+Causes
+.Nm
+to never display the progress meter in cases where it would do
+so by default.
.It Fl m
Causes
.Nm
Index: main.c
===
RCS file: /cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.97
diff -u -p -r1.97 main.c
--- main.c 9 Feb 2015 08:24:21 - 1.97
+++ main.c 17 Feb 2015 08:04:14 -
@@ -202,7 +202,7 @@ main(volatile int argc, char *argv[])
httpuseragent = NULL;
while ((ch = getopt(argc, argv,
- "46AaCc:dD:Eegik:mno:pP:r:S:s:tU:vV")) != -1) {
+ "46AaCc:dD:Eegik:Mmno:pP:r:S:s:tU:vV")) != -1) {
switch (ch) {
case '4':
family = PF_INET;
@@ -267,6 +267,9 @@ main(volatile int argc, char *argv[])
optarg);
usage();
}
+ break;
+ case 'M':
+ progress = 0;
break;
case 'm':
progress = -1;
