Concluding Reminder: The New Marketing Game Changers Have Arrived.
The business world just went through some revolutionary changes and the resultant domain name expansion effect is changing the internet and the marketing landscape forever. ICANN (the Internet governing body) recently released the list of 1,930 gTLD dot names from around the world. Some 1,000 entities have already invested on average of million dollars in hard and soft costs for each single dot name. Each dot name identity is poised for market domination and capable of altering the market shares. The name centric agenda now reaches the boardrooms. The game changers have arrived. How will they impact your area of responsibility? What effect will they have on your business model? Find out at http://www.aarm.org/CMJ/index.php/executive-briefing-notices Robert T. Stacey President - AARM roberttsta...@aarm.org www.aarm.org ___ If you have received this email in error please accept my apologies. Insert removal in the subject line and reply it back to me. I'll see that appropriate action is taken asap. Thank you.
Re: [PATCH] group.c: group_autogroup looks for best match
On Fri 2012.10.26 at 11:25 -0500, Kent R. Spillner wrote:
> Merhaba-
Hi,
> Below is a new diff which only sets no if class matches and name is NULL or
> if class and name both match.
>
> Since we must explicitly check for name == NULL I decided to also go ahead
> and skip setting no if any previous class-only matches were found.
It's too bad the explicit class+name match is backwards in the config
grammar; I suppose we could reverse it and may make more sense going
generic to specific matches...but that's another topic.
However, in general, I do prefer last matching when it comes to the
matching options in the config. So the below allows for specific
matches of class+name or just class matches, but last matching in both
cases.
I use autogroup'ing only a little, so I used the following bits to test
autogroup 4 XTerm
autogroup 6 "YYY,XTerm"
autogroup 3 XTerm
autogroup 4 "XXX,XTerm"
autogroup 5 "YYY,XTerm"
...re-ordered them and got the autogrouping results I expect from just
reading the config.
Hopefully this is more clear and expected behavior.
Cheers,
Okan
Index: group.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.60
diff -u -p -r1.60 group.c
--- group.c 9 Sep 2012 20:52:57 - 1.60
+++ group.c 28 Oct 2012 21:05:47 -
@@ -429,11 +429,12 @@ group_autogroup(struct client_ctx *cc)
XFree(grpno);
} else {
TAILQ_FOREACH(aw, &Conf.autogroupq, entry) {
- if (strcmp(aw->class, cc->app_class) == 0 &&
- (aw->name == NULL ||
- strcmp(aw->name, cc->app_name) == 0)) {
- no = aw->num;
- break;
+ if (strcmp(aw->class, cc->app_class) == 0) {
+ if ((aw->name != NULL) &&
+ (strcmp(aw->name, cc->app_name) == 0))
+ no = aw->num;
+ else if (aw->name == NULL)
+ no = aw->num;
}
}
}
Re: [PATCH] cwmrc.5: rename autogroup parameter
On Sun 2012.10.28 at 02:43 -0500, Kent R. Spillner wrote: > Below is a new diff which incorporates your suggestion (plus a few > additions), and revises the rest of the description as well. Comments? A slightly altered version of your diff was applied -thanks!
Re: add support for elantech touchpads to pms(4)
On Sun, Oct 28, 2012 at 03:47:14PM +0100, Stefan Sperling wrote:
> On Mon, Oct 08, 2012 at 06:16:22PM +0200, Martin Pieuchot wrote:
> > I don't have any Elantech hardware to test but I can tell you that this
> > version doesn't introduce any regression with my ALPS touchpad. It could
> > be nice to hear from other touchpad owners too ;)
>
> I haven't received test reports from anyone else. I suspect many don't
> realise that their laptop contains an elantech touchpad.
>
> > > +int
> > > +pms_ioctl_elantech(struct pms_softc *sc, u_long cmd, caddr_t data, int
> > > flag,
> > > +struct proc *p)
> > > +{
> > > + struct elantech_softc *elantech = sc->elantech;
> > > + struct wsmouse_calibcoords *wsmc = (struct wsmouse_calibcoords *)data;
> > > + int wsmode;
> > > +
> > > + switch (cmd) {
> > > + case WSMOUSEIO_GTYPE:
> > > + *(u_int *)data = WSMOUSE_TYPE_SYNAPTICS;
> >
> > Here you may want to define a WSMOUSE_TYPE_ELANTECH, it is used in the
> > synaptics(4) driver to describe which "features" are supported by this
> > touchpad, see xenocara/driver/xf86-input-synaptics/src/wsconscomm.c
> >
> > But if you do so, you'll obviously need to rebuild the X driver too ;)
>
> Yes, I've done this now. The new kernel + X driver diff is below.
> The synaptics driver already has some elantech-specific code which
> gets activated with this change.
>
> > > +void
> > > +pms_proc_elantech_v3(struct pms_softc *sc)
> > > +{
> > > + const u_char debounce_pkt[] = { 0xc4, 0xff, 0xff, 0x02, 0xff, 0xff };
> > > + struct elantech_softc *elantech = sc->elantech;
> > > + u_int buttons;
> > > + int fingers, x, y, w, z;
> > > +
> > > + /* The hardware sends this packet when in debounce state.
> > > + * The packet should be ignored. */
> > > + if (!memcmp(sc->packet, debounce_pkt, sizeof(debounce_pkt)))
> > > + return;
> > > +
> > > + buttons = ((sc->packet[0] & 0x01 ? WSMOUSE_BUTTON(1) : 0) |
> > > + ((sc->packet[0] & 0x02) ? WSMOUSE_BUTTON(3): 0));
> > > + x = y = z = 0;
> > > + w = -1; /* corresponds to no finger, see synaptics */
> > > + fingers = (sc->packet[0] & 0xc0) >> 6;
> > > + if (fingers == 2) {
> > > + /* Two-finger touch causes two packets -- a head packet
> > > + * and a tail packet. */
> > > + if ((sc->packet[0] & 0x0c) == 0x04 &&
> > > + (sc->packet[3] & 0xfc) == 0x02) {
> > > + /* head packet */
> > > + x = ((sc->packet[1] & 0x0f) << 8 | sc->packet[2]);
> > > + y = ((sc->packet[4] & 0x0f) << 8 | sc->packet[5]);
> > > + } else if ((sc->packet[0] & 0x0c) == 0x0c &&
> > > + (sc->packet[3] & 0xce) == 0x0c) {
> > > + /* tail packet */
> > > + x = ((sc->packet[1] & 0x0f) << 8 | sc->packet[2]);
> > > + y = ((sc->packet[4] & 0x0f) << 8 | sc->packet[5]);
> >
> > Is it a typo or the 'x' and 'y' calculation are the same in both cases?
>
> Yes. There are two packets, one per finger.
>
> It turns out we can ignore the second packet. This makes two-finger scrolling
> smoother than it was before. Reporting both events was causing occasional
> jumps during two-finger scrolling.
>
> >
> > > + }
> > > + w = 0; /* force 2 fingers in synaptics */
> >
> > This isn't related to your diff, but we should add defines for
> > w = {-1, 0, 3, 4} because these values come from the synaptics devices.
>
> Indeed. I've added a comment to wsconscomm.c in synaptics.
>
> > > + } else if (fingers == 1 || fingers == 3) {
> > > + x = (sc->packet[1] & 0x0f) << 8 | sc->packet[2];
> > > + y = ((sc->packet[4] & 0x0f) << 8) | sc->packet[5];
> > > + w = (fingers == 3 ? 1 : 4); /* values for synaptics */
> > > + }
> >
> > Same here for the 'x' and 'y', maybe you just need to convert the value
> > you call 'fingers' to the corresponding 'w' (synaptics finger value).
>
> By reporting the touchpad as an Elantech pad to synaptics we can get
> rid of the 'fingers' variable and just assign the value to 'w' instead.
>
> > > +void
> > > +elantech_send_input(struct pms_softc *sc, u_int buttons, int x, int y,
> > > int z,
> > > +int w)
> > > + {
> > > + struct elantech_softc *elantech = sc->elantech;
> > > + int dx, dy;
> > > +
> > > + if (elantech->wsmode == WSMOUSE_NATIVE) {
> > > + if ((x > 0 && y > 0) || buttons)
> >
> > I think this condition is always true, or does the elantech touchpads
> > generate packets without position nor buttons pressed? Plus in case of
> > the v3 if x or y are null you explicitly force them to their previous
> > know position.
>
> Yes, this check is bogus. I've removed it.
>
> > > +/* Hardware version 1 has hard-coded axis range values.
> > > + * X axis range is 0 to 576, Y axis range is 0 to 384.
> > > + * Edge offset accounts for bezel around the touchpad. */
> > > +#define ELANTECH_V1_EDGE_OFFSET 32
> > > +#define ELANTECH_V1_X_MIN (0 + ELANTECH_V1_EDGE_OFFSET)
> > > +#define ELANTECH
Re: add support for elantech touchpads to pms(4)
On Mon, Oct 08, 2012 at 06:16:22PM +0200, Martin Pieuchot wrote:
> I don't have any Elantech hardware to test but I can tell you that this
> version doesn't introduce any regression with my ALPS touchpad. It could
> be nice to hear from other touchpad owners too ;)
I haven't received test reports from anyone else. I suspect many don't
realise that their laptop contains an elantech touchpad.
> > +int
> > +pms_ioctl_elantech(struct pms_softc *sc, u_long cmd, caddr_t data, int
> > flag,
> > +struct proc *p)
> > +{
> > + struct elantech_softc *elantech = sc->elantech;
> > + struct wsmouse_calibcoords *wsmc = (struct wsmouse_calibcoords *)data;
> > + int wsmode;
> > +
> > + switch (cmd) {
> > + case WSMOUSEIO_GTYPE:
> > + *(u_int *)data = WSMOUSE_TYPE_SYNAPTICS;
>
> Here you may want to define a WSMOUSE_TYPE_ELANTECH, it is used in the
> synaptics(4) driver to describe which "features" are supported by this
> touchpad, see xenocara/driver/xf86-input-synaptics/src/wsconscomm.c
>
> But if you do so, you'll obviously need to rebuild the X driver too ;)
Yes, I've done this now. The new kernel + X driver diff is below.
The synaptics driver already has some elantech-specific code which
gets activated with this change.
> > +void
> > +pms_proc_elantech_v3(struct pms_softc *sc)
> > +{
> > + const u_char debounce_pkt[] = { 0xc4, 0xff, 0xff, 0x02, 0xff, 0xff };
> > + struct elantech_softc *elantech = sc->elantech;
> > + u_int buttons;
> > + int fingers, x, y, w, z;
> > +
> > + /* The hardware sends this packet when in debounce state.
> > +* The packet should be ignored. */
> > + if (!memcmp(sc->packet, debounce_pkt, sizeof(debounce_pkt)))
> > + return;
> > +
> > + buttons = ((sc->packet[0] & 0x01 ? WSMOUSE_BUTTON(1) : 0) |
> > + ((sc->packet[0] & 0x02) ? WSMOUSE_BUTTON(3): 0));
> > + x = y = z = 0;
> > + w = -1; /* corresponds to no finger, see synaptics */
> > + fingers = (sc->packet[0] & 0xc0) >> 6;
> > + if (fingers == 2) {
> > + /* Two-finger touch causes two packets -- a head packet
> > +* and a tail packet. */
> > + if ((sc->packet[0] & 0x0c) == 0x04 &&
> > + (sc->packet[3] & 0xfc) == 0x02) {
> > + /* head packet */
> > + x = ((sc->packet[1] & 0x0f) << 8 | sc->packet[2]);
> > + y = ((sc->packet[4] & 0x0f) << 8 | sc->packet[5]);
> > + } else if ((sc->packet[0] & 0x0c) == 0x0c &&
> > + (sc->packet[3] & 0xce) == 0x0c) {
> > + /* tail packet */
> > + x = ((sc->packet[1] & 0x0f) << 8 | sc->packet[2]);
> > + y = ((sc->packet[4] & 0x0f) << 8 | sc->packet[5]);
>
> Is it a typo or the 'x' and 'y' calculation are the same in both cases?
Yes. There are two packets, one per finger.
It turns out we can ignore the second packet. This makes two-finger scrolling
smoother than it was before. Reporting both events was causing occasional
jumps during two-finger scrolling.
>
> > + }
> > + w = 0; /* force 2 fingers in synaptics */
>
> This isn't related to your diff, but we should add defines for
> w = {-1, 0, 3, 4} because these values come from the synaptics devices.
Indeed. I've added a comment to wsconscomm.c in synaptics.
> > + } else if (fingers == 1 || fingers == 3) {
> > + x = (sc->packet[1] & 0x0f) << 8 | sc->packet[2];
> > + y = ((sc->packet[4] & 0x0f) << 8) | sc->packet[5];
> > + w = (fingers == 3 ? 1 : 4); /* values for synaptics */
> > + }
>
> Same here for the 'x' and 'y', maybe you just need to convert the value
> you call 'fingers' to the corresponding 'w' (synaptics finger value).
By reporting the touchpad as an Elantech pad to synaptics we can get
rid of the 'fingers' variable and just assign the value to 'w' instead.
> > +void
> > +elantech_send_input(struct pms_softc *sc, u_int buttons, int x, int y, int
> > z,
> > +int w)
> > + {
> > + struct elantech_softc *elantech = sc->elantech;
> > + int dx, dy;
> > +
> > + if (elantech->wsmode == WSMOUSE_NATIVE) {
> > + if ((x > 0 && y > 0) || buttons)
>
> I think this condition is always true, or does the elantech touchpads
> generate packets without position nor buttons pressed? Plus in case of
> the v3 if x or y are null you explicitly force them to their previous
> know position.
Yes, this check is bogus. I've removed it.
> > +/* Hardware version 1 has hard-coded axis range values.
> > + * X axis range is 0 to 576, Y axis range is 0 to 384.
> > + * Edge offset accounts for bezel around the touchpad. */
> > +#define ELANTECH_V1_EDGE_OFFSET32
> > +#defineELANTECH_V1_X_MIN (0 + ELANTECH_V1_EDGE_OFFSET)
> > +#defineELANTECH_V1_X_MAX (576 - ELANTECH_V1_EDGE_OFFSET)
> > +#defineELANTECH_V1_Y_MIN (0 + ELANTECH_V1_EDGE_OFFSET)
> > +#defineELANTECH_V1_Y_MAX (384 - ELANTECH_V1_EDGE_OFFSET)
>
> Some nitpi
Re: sndio: protocol change - diff to test
On Sun, Oct 28, 2012 at 06:45:59PM +1100, Jonathan Gray wrote:
> On Sat, Oct 27, 2012 at 03:14:07PM +0200, Alexandre Ratchov wrote:
> > Hi,
> >
> > This diff is to use dedicated messages for flow control instead of
> > abusing clock tick messages and to enable flow control for MIDI.
> > There should be no change in behaviour, but this change is
> > necessary for future developpement of sndiod.
> >
> > any regression? ok?
>
> This seems to break seeking in mplayer (both audio and video files),
> after using the right arrow key to skip ahead it just stops.
>
thanks! ... stupid mistake. I hope the diff in my other mail works
better ;)
On Sat, Oct 27, 2012 at 03:14:07PM +0200, Alexandre Ratchov wrote:
>
> @@ -551,14 +549,15 @@ sock_attach(struct sock *f, int force)
>* get the current position, the origin is when
>* the first sample is played/recorded
>*/
> - f->startpos = dev_getpos(f->dev) * (int)f->round / (int)f->dev->round;
> - f->startpending = 1;
> + f->delta = dev_getpos(f->dev) *
> + (int)f->round / (int)f->dev->round;
> + f->fillpending = f->delta;
^^
this should be zero
> f->pstate = SOCK_RUN;
> #ifdef DEBUG
> if (debug_level >= 3) {
> sock_dbg(f);
> dbg_puts(": attaching at ");
> - dbg_puti(f->startpos);
> + dbg_puti(f->delta);
> dbg_puts("\n");
> }
> #endif
Re: sndio: protocol change - diff to test
On Sat, Oct 27, 2012 at 03:14:07PM +0200, Alexandre Ratchov wrote:
> Hi,
>
> This diff is to use dedicated messages for flow control instead of
> abusing clock tick messages and to enable flow control for MIDI.
> There should be no change in behaviour, but this change is
> necessary for future developpement of sndiod.
>
> any regression? ok?
>
sorry; the previous diff is wrong, please consider the one
below (thanks jsg@)
-- Alexandre
Index: lib/libsndio/amsg.h
===
RCS file: /cvs/src/lib/libsndio/amsg.h,v
retrieving revision 1.4
diff -u -p -r1.4 amsg.h
--- lib/libsndio/amsg.h 15 Nov 2011 08:05:22 - 1.4
+++ lib/libsndio/amsg.h 28 Oct 2012 12:28:51 -
@@ -42,7 +42,7 @@ struct amsg {
#define AMSG_START 3 /* request the server to start the stream */
#define AMSG_STOP 4 /* request the server to stop the stream */
#define AMSG_DATA 5 /* data block */
-#define AMSG_POS 6 /* initial position */
+#define AMSG_FLOWCTL 6 /* feedback about buffer usage */
#define AMSG_MOVE 7 /* position changed */
#define AMSG_SETVOL9 /* set volume */
#define AMSG_HELLO 10 /* say hello, check versions and so ... */
@@ -80,7 +80,7 @@ struct amsg {
} vol;
struct amsg_hello {
uint16_t mode; /* bitmap of MODE_XXX */
-#define AMSG_VERSION 5
+#define AMSG_VERSION 6
uint8_t version;/* protocol version */
uint8_t devnum; /* device number */
uint32_t _reserved[1]; /* for future use */
Index: lib/libsndio/aucat.c
===
RCS file: /cvs/src/lib/libsndio/aucat.c,v
retrieving revision 1.54
diff -u -p -r1.54 aucat.c
--- lib/libsndio/aucat.c11 Apr 2012 06:05:43 - 1.54
+++ lib/libsndio/aucat.c28 Oct 2012 12:28:51 -
@@ -463,6 +463,7 @@ aucat_open(struct aucat *hdl, const char
hdl->rtodo = sizeof(struct amsg);
hdl->wstate = WSTATE_IDLE;
hdl->wtodo = 0xdeadbeef;
+ hdl->maxwrite = 0;
/*
* say hello to server
Index: lib/libsndio/aucat.h
===
RCS file: /cvs/src/lib/libsndio/aucat.h,v
retrieving revision 1.4
diff -u -p -r1.4 aucat.h
--- lib/libsndio/aucat.h15 Nov 2011 08:05:22 - 1.4
+++ lib/libsndio/aucat.h28 Oct 2012 12:28:51 -
@@ -14,6 +14,7 @@ struct aucat {
#define WSTATE_MSG 3 /* message being transferred */
#define WSTATE_DATA4 /* data being transferred */
unsigned wstate;/* one of above */
+ unsigned maxwrite; /* bytes we're allowed to write */
};
int aucat_rmsg(struct aucat *, int *);
Index: lib/libsndio/mio_aucat.c
===
RCS file: /cvs/src/lib/libsndio/mio_aucat.c,v
retrieving revision 1.8
diff -u -p -r1.8 mio_aucat.c
--- lib/libsndio/mio_aucat.c27 Oct 2012 12:08:25 - 1.8
+++ lib/libsndio/mio_aucat.c28 Oct 2012 12:28:51 -
@@ -54,6 +54,35 @@ static struct mio_ops mio_aucat_ops = {
mio_aucat_revents
};
+/*
+ * execute the next message, return 0 if blocked
+ */
+static int
+mio_aucat_runmsg(struct mio_aucat_hdl *hdl)
+{
+ int delta;
+
+ if (!aucat_rmsg(&hdl->aucat, &hdl->mio.eof))
+ return 0;
+ switch (ntohl(hdl->aucat.rmsg.cmd)) {
+ case AMSG_DATA:
+ return 1;
+ case AMSG_FLOWCTL:
+ delta = ntohl(hdl->aucat.rmsg.u.ts.delta);
+ hdl->aucat.maxwrite += delta;
+ DPRINTF("aucat: flowctl = %d, maxwrite = %d\n",
+ delta, hdl->aucat.maxwrite);
+ break;
+ default:
+ DPRINTF("mio_aucat_runmsg: unhandled message %u\n",
hdl->aucat.rmsg.cmd);
+ hdl->mio.eof = 1;
+ return 0;
+ }
+ hdl->aucat.rstate = RSTATE_MSG;
+ hdl->aucat.rtodo = sizeof(struct amsg);
+ return 1;
+}
+
struct mio_hdl *
mio_aucat_open(const char *str, unsigned int mode,
int nbio, unsigned int type)
@@ -91,7 +120,7 @@ mio_aucat_read(struct mio_hdl *sh, void
struct mio_aucat_hdl *hdl = (struct mio_aucat_hdl *)sh;
while (hdl->aucat.rstate == RSTATE_MSG) {
- if (!aucat_rmsg(&hdl->aucat, &hdl->mio.eof))
+ if (!mio_aucat_runmsg(hdl))
return 0;
}
return aucat_rdata(&hdl->aucat, buf, len, &hdl->mio.eof);
@@ -101,8 +130,15 @@ static size_t
mio_aucat_write(struct mio_hdl *sh, const void *buf, size_t len)
{
struct mio_aucat_hdl *hdl = (struct mio_aucat_hdl *)sh;
+ size_t n;
- return aucat_wdata(&hdl->aucat, buf, len, 1, &hdl->mio.eof);
+ if (len <= 0 || hdl->aucat
Re: bgpd filter and reload diff
On Sat, Oct 13, 2012 at 08:40:35PM +0200, Claudio Jeker wrote:
> Hi,
>
> this is the first step in making bgpd faster and non locking on reloads.
> The filters are now split into input and output chains. The input chains
> are also split per RIB. This should result in faster filtering and allows
> to only run softreconfig on those tables that need it. People with
> multiple RIBs will benefit the most at the moment.
>
> I did some basic tests and I'm fairly confident that it should work but
> this is a huge change in the reload logic and needs a good broad testing
> and I don't mind some review of the code.
>
No comments on this? Should I just commit it?
> --
> :wq Claudio
>
> Index: bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.273
> diff -u -p -r1.273 bgpd.h
> --- bgpd.h18 Sep 2012 10:10:00 - 1.273
> +++ bgpd.h20 Sep 2012 08:06:06 -
> @@ -103,6 +103,7 @@ enum reconf_action {
> RECONF_NONE,
> RECONF_KEEP,
> RECONF_REINIT,
> + RECONF_RELOAD,
> RECONF_DELETE
> };
>
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.321
> diff -u -p -r1.321 rde.c
> --- rde.c 18 Sep 2012 10:10:00 - 1.321
> +++ rde.c 12 Oct 2012 06:27:52 -
> @@ -85,12 +85,11 @@ void rde_dump_mrt_new(struct mrt *, pi
> void rde_dump_done(void *);
>
> int rde_rdomain_import(struct rde_aspath *, struct rdomain *);
> -void rde_up_dump_upcall(struct rib_entry *, void *);
> +void rde_reload_done(void);
> void rde_softreconfig_out(struct rib_entry *, void *);
> void rde_softreconfig_in(struct rib_entry *, void *);
> -void rde_softreconfig_load(struct rib_entry *, void *);
> -void rde_softreconfig_load_peer(struct rib_entry *, void *);
> void rde_softreconfig_unload_peer(struct rib_entry *, void *);
> +void rde_up_dump_upcall(struct rib_entry *, void *);
> void rde_update_queue_runner(void);
> void rde_update6_queue_runner(u_int8_t);
>
> @@ -119,7 +118,7 @@ struct bgpd_config*conf, *nconf;
> time_treloadtime;
> struct rde_peer_head peerlist;
> struct rde_peer *peerself;
> -struct filter_head *rules_l, *newrules;
> +struct filter_head *out_rules, *out_rules_tmp;
> struct rdomain_head *rdomains_l, *newdomains;
> struct imsgbuf *ibuf_se;
> struct imsgbuf *ibuf_se_ctl;
> @@ -224,10 +223,10 @@ rde_main(int pipe_m2r[2], int pipe_s2r[2
> nexthop_init(nexthophashsize);
> peer_init(peerhashsize);
>
> - rules_l = calloc(1, sizeof(struct filter_head));
> - if (rules_l == NULL)
> + out_rules = calloc(1, sizeof(struct filter_head));
> + if (out_rules == NULL)
> fatal(NULL);
> - TAILQ_INIT(rules_l);
> + TAILQ_INIT(out_rules);
> rdomains_l = calloc(1, sizeof(struct rdomain_head));
> if (rdomains_l == NULL)
> fatal(NULL);
> @@ -645,11 +644,11 @@ rde_dispatch_imsg_parent(struct imsgbuf
> struct rde_rib rn;
> struct rde_peer *peer;
> struct peer_config *pconf;
> + struct filter_head *nr;
> struct filter_rule *r;
> struct filter_set *s;
> struct nexthop *nh;
> - int n, fd, reconf_in = 0, reconf_out = 0,
> - reconf_rib = 0;
> + int n, fd;
> u_int16_trid;
>
> if ((n = imsg_read(ibuf)) == -1)
> @@ -693,10 +692,10 @@ rde_dispatch_imsg_parent(struct imsgbuf
> sizeof(struct bgpd_config))
> fatalx("IMSG_RECONF_CONF bad len");
> reloadtime = time(NULL);
> - newrules = calloc(1, sizeof(struct filter_head));
> - if (newrules == NULL)
> + out_rules_tmp = calloc(1, sizeof(struct filter_head));
> + if (out_rules_tmp == NULL)
> fatal(NULL);
> - TAILQ_INIT(newrules);
> + TAILQ_INIT(out_rules_tmp);
> newdomains = calloc(1, sizeof(struct rdomain_head));
> if (newdomains == NULL)
> fatal(NULL);
> @@ -746,7 +745,19 @@ rde_dispatch_imsg_parent(struct imsgbuf
> TAILQ_INIT(&r->set);
> r->peer.ribid = rib_find(r->rib);
> parent_set = &r->set;
> - TAILQ_INSERT_TAIL(newrules, r, entry);
> + if (r->dir == DIR_IN) {
> + nr = ribs[r->peer.ribid].in_rules_tmp;
> + if (nr == NULL) {
Re: [PATCH] ln: support -L|-P options (from FreeBSD)
Bump.
On Sun, Feb 19, 2012 at 10:23:41AM -0600, Kent R. Spillner wrote:
> Howdy-
>
> This patch adds support for the -L|-P options to ln; see:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html
>
> Based on FreeBSD's code & manpage
> (http://svnweb.freebsd.org/base/head/bin/ln/),
> except the regress stuff (which is all my fault).
>
> Best,
> Kent
>
> Index: bin/ln/ln.1
> ===
> RCS file: /cvs/src/bin/ln/ln.1,v
> retrieving revision 1.29
> diff -p -u -r1.29 ln.1
> --- bin/ln/ln.1 2 Mar 2011 07:47:21 - 1.29
> +++ bin/ln/ln.1 18 Feb 2012 02:54:43 -
> @@ -41,11 +41,11 @@
> .Nd make hard and symbolic links to files
> .Sh SYNOPSIS
> .Nm ln
> -.Op Fl fhns
> +.Op Fl LPfhns
> .Ar source
> .Op Ar target
> .Nm ln
> -.Op Fl fs
> +.Op Fl LPfs
> .Ar source ...\&
> .Op Ar directory
> .Sh DESCRIPTION
> @@ -64,6 +64,19 @@ to a file is one of the differences betw
> .Pp
> The options are as follows:
> .Bl -tag -width Ds
> +.It Fl L
> +When creating a hard link to a symbolic link,
> +create a hard link to the target of the symbolic link.
> +This is the default.
> +This option cancels the
> +.Fl P
> +option.
> +.It Fl P
> +When creating a hard link to a symbolic link,
> +create a hard link to the symbolic link itself.
> +This option cancels the
> +.Fl L
> +option.
> .It Fl f
> Unlink any already existing file, permitting the link to occur.
> .It Fl h
> Index: bin/ln/ln.c
> ===
> RCS file: /cvs/src/bin/ln/ln.c,v
> retrieving revision 1.18
> diff -p -u -r1.18 ln.c
> --- bin/ln/ln.c 27 Oct 2009 23:59:21 - 1.18
> +++ bin/ln/ln.c 18 Feb 2012 02:54:43 -
> @@ -35,6 +35,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -44,9 +45,8 @@
> int dirflag;/* Undocumented directory flag. */
> int fflag; /* Unlink existing files. */
> int hflag; /* Check new name for symlink first. */
> +int Pflag; /* Hard link to symlink. */
> int sflag; /* Symbolic, not hard, link. */
> - /* System link call. */
> -int (*linkf)(const char *, const char *);
>
> int linkit(char *, char *, int);
> void usage(void) __dead;
> @@ -58,7 +58,7 @@ main(int argc, char *argv[])
> int ch, exitval;
> char *sourcedir;
>
> - while ((ch = getopt(argc, argv, "Ffhns")) != -1)
> + while ((ch = getopt(argc, argv, "FLPfhns")) != -1)
> switch (ch) {
> case 'F':
> dirflag = 1;/* XXX: deliberately undocumented. */
> @@ -66,6 +66,12 @@ main(int argc, char *argv[])
> case 'f':
> fflag = 1;
> break;
> + case 'L':
> + Pflag = 0;
> + break;
> + case 'P':
> + Pflag = 1;
> + break;
> case 'h':
> case 'n':
> hflag = 1;
> @@ -80,8 +86,6 @@ main(int argc, char *argv[])
> argv += optind;
> argc -= optind;
>
> - linkf = sflag ? symlink : link;
> -
> switch(argc) {
> case 0:
> usage();
> @@ -118,7 +122,7 @@ linkit(char *target, char *source, int i
>
> if (!sflag) {
> /* If target doesn't exist, quit now. */
> - if (stat(target, &sb)) {
> + if ((Pflag ? lstat : stat)(target, &sb)) {
> warn("%s", target);
> return (1);
> }
> @@ -177,7 +181,9 @@ linkit(char *target, char *source, int i
>* Attempt the link.
>*/
> if ((fflag && unlink(source) < 0 && errno != ENOENT) ||
> - (*linkf)(target, source)) {
> + sflag ? symlink(target, source) :
> + linkat(AT_FDCWD, target, AT_FDCWD, source,
> + Pflag ? 0 : AT_SYMLINK_FOLLOW)) {
> warn("%s", source);
> return (1);
> }
> @@ -191,8 +197,8 @@ usage(void)
> extern char *__progname;
>
> (void)fprintf(stderr,
> - "usage: %s [-fhns] source [target]\n"
> - " %s [-fs] source ... [directory]\n",
> + "usage: %s [-LPfhns] source [target]\n"
> + " %s [-LPfs] source ... [directory]\n",
> __progname, __progname);
> exit(1);
> }
> Index: regress/bin/ln/Makefile
> ===
> RCS file: regress/bin/ln/Makefile
> diff -N regress/bin/ln/Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ regress/bin/ln/Makefile 18 Feb 2012 02:54:50 -
> @@ -0,0 +1,18 @@
> +#$OpenBSD$
> +
> +regress: compare_dirents recursive links/source
> + @sh ${.CURDIR}/test_ln.sh
> +
> +clean:
> + rm -rf compare_dire
Re: [PATCH] cwmrc.5: rename autogroup parameter
Hey, dude- > -Control automatic window grouping, based on the name and/or class > -properties, where > +Control automatic window grouping based on either the class property, > +or on the name and class properties, where I like your wording, and I think it is clearer. However, after this change now I think the "Control automatic window grouping" could use a little attention. What do you think about completely revising the whole autogroup description? (This bikeshed needs another wing) Below is a new diff which incorporates your suggestion (plus a few additions), and revises the rest of the description as well. Comments? Thanks again! Best, Kent Index: cwmrc.5 === RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v retrieving revision 1.43 diff -N -p -u cwmrc.5 --- cwmrc.5 6 Jul 2012 08:41:29 - 1.43 +++ cwmrc.5 28 Oct 2012 07:29:30 - @@ -39,19 +39,30 @@ Arguments containing whitespace should be surrounded b The following options are accepted: .Pp .Bl -tag -width Ds -compact -.It Ic autogroup Ar group windowname +.It Ic autogroup Ar group windowclass .It Ic autogroup Ar group windowname,windowclass -Control automatic window grouping, based on the name and/or class -properties, where +Automatically add new windows to .Ar group +if their class property matches +.Ar windowclass , +or name and class properties match +.Ar windowname +and +.Ar windowclass . +.Ar Group is a number between 0 and 9. -If the group number is 0, then the window will not be grouped; this to -allow for -.Dq sticky -windows in sticky group mode. +When +.Ar group +is 0 matching windows will not be added to any group; this may be +used to override +.Dq sticky group mode . .Pp -The name and class of a window may be obtained using -.Xr xprop 1 . +The name and class values for existing windows may be obtained using +.Xr xprop 1 +.Po see +.Xr XClassHint 3 +for details +.Pc . .Pp .It Ic bind Ar keys command Cause the creation of a keybinding, or replacement of a default
Re: DNS options for sppp(4)
On cs, okt 25, 2012 at 10:47:04 +0200, Gerhard Roth wrote:
[...]
> > Works for me.
> > Cool feature, I like it :)
> > Thanks!
> >
> >
> > Daniel
> >
>
> So anybody out there willing to give me an ok?
Sorry if I was too terse.
This was tested and now is being used on two separate i386 machines with
pppoe (different ISPs), running 5.1-stable.
Here are the two dmesgs:
OpenBSD 5.1-stable (GENERIC) #2: Wed Oct 24 21:10:21 CEST 2012
root@host:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.42 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
real mem = 1073213440 (1023MB)
avail mem = 1045561344 (997MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/02, BIOS32 rev. 0 @ 0xfdb60, SMBIOS
rev. 2.3 @ 0xf0630 (32 entries)
bios0: vendor American Megatrends Inc. version "V1.2 11" date 11/05/2002
bios0: MICRO-STAR INC. MS-6704
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices USB1(S3) USB2(S3) USB3(S3) EHCI(S3) ICHB(S4) PS2M(S4)
PS2K(S4) UAR1(S4) MC9_(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (ICHB)
acpicpu0 at acpi0
acpipwrres0 at acpi0: URP1
acpipwrres1 at acpi0: URP2
acpipwrres2 at acpi0: FDDP
acpipwrres3 at acpi0: LPTP
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xd000 0xcd000/0x4800 0xd1800/0x1000 0xe/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845G Host" rev 0x02
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe000, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82845G AGP" rev 0x02
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon 9600" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 16
drm0 at radeondrm0
"ATI Radeon 9600 XT Sec" rev 0x00 at pci1 dev 0 function 1 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x02: apic 2 int 18
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x82
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel PRO/1000GT (82541GI)" rev 0x05: apic 2 int
16, address 00:xx:xx:xx:xx:xx
pciide0 at pci2 dev 3 function 0 "CMD Technology SiI3512 SATA" rev 0x01: DMA
pciide0: using apic 2 int 19 for native-PCI interrupt
pciide0: port 0: device present, speed: 1.5Gb/s
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(pciide0:0:0): using BIOS timings, Ultra-DMA mode 5
pciide0: port 1: device present, speed: 1.5Gb/s
wd1 at pciide0 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd1(pciide0:1:0): using BIOS timings, Ultra-DMA mode 7
vge0 at pci2 dev 4 function 0 "VIA VT612x" rev 0x11: apic 2 int 16, address
00:xx:xx:xx:xx:xx
ciphy0 at vge0 phy 1: CS8201 10/100/1000TX PHY, rev. 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801DB LPC" rev 0x02
ichiic0 at pci0 dev 31 function 3 "Intel 82801DB SMBus" rev 0x02: apic 2 int 17
iic0 at ichiic0
iic0: addr 0x2f 00=00 02=0f 03=00 04=00 06=0f 07=00 08=00 0a=06 0b=00 0c=00
0d=07 0e=85 0f=00 10=c4 11=10 12=00 13=60 words 00=00ff 01= 02=0fff 03=00ff
04=00ff 05= 06=0fff 07=00ff
spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM non-parity PC3200CL3.0
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x17
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
root on wd0a (69dbc259cb64de66.a) swap on wd0b dump on wd0b
pppoe0: received unexpected PADO
pppoe0: received unexpected PADO
pppoe0: received unexpected PADO
pppoe0: rece
Re: sndio: protocol change - diff to test
On Sat, Oct 27, 2012 at 03:14:07PM +0200, Alexandre Ratchov wrote: > Hi, > > This diff is to use dedicated messages for flow control instead of > abusing clock tick messages and to enable flow control for MIDI. > There should be no change in behaviour, but this change is > necessary for future developpement of sndiod. > > any regression? ok? This seems to break seeking in mplayer (both audio and video files), after using the right arrow key to skip ahead it just stops. attaching from gdb it looks like: #0 0x197af601039a in poll () at :2 #1 0x197af6ce413d in poll (fds=0x7f7ba060, nfds=1, timeout=-1) at /usr/src/lib/librthread/rthread_cancel.c:331 #2 0x197af2c1c09f in sio_psleep (hdl=0x197afbd61600, event=4) at /usr/src/lib/libsndio/sio.c:220 #3 0x197af2c1c264 in sio_write (hdl=0x197afbd61600, buf=0x197af1d86000, len=7056) at /usr/src/lib/libsndio/sio.c:308 #4 0x1978eddecec5 in send_udp () from /usr/local/bin/mplayer #5 0x1978eddc6fae in main () from /usr/local/bin/mplayer
