Remove unused variable in arch/i386/i386/lapic.c
Hi I have noted that scaled_pentium_mhz variable in i386/lapic.c is defined and initialized, but never used anywhere (grep -R scaled_pentium_mhz /usr/src say nothing [after patch applied]). Remove it ? -- Sébastien Marie Index: arch/i386/i386/lapic.c === RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v retrieving revision 1.32 diff -u -p -r1.32 lapic.c --- arch/i386/i386/lapic.c 2 Jun 2013 18:16:42 - 1.32 +++ arch/i386/i386/lapic.c 26 Oct 2013 14:35:03 - @@ -234,7 +234,6 @@ u_int32_t lapic_per_second; u_int32_t lapic_frac_usec_per_cycle; u_int64_t lapic_frac_cycle_per_usec; u_int32_t lapic_delaytab[26]; -u_int64_t scaled_pentium_mhz; void lapic_clockintr(void *arg) @@ -368,8 +367,6 @@ lapic_calibrate_timer(struct cpu_info *c tmp = (lapic_per_second * (u_int64_t)1 32) / 100; lapic_frac_cycle_per_usec = tmp; - - scaled_pentium_mhz = (1ULL 32) / cpuspeed; /* * Compute delay in cycles for likely short delays in usec.
Re: Stairstep mouse motion
On Fri, Oct 25, 2013 at 11:41:25AM +0100, Edd Barrett wrote:
On Thu, Oct 24, 2013 at 10:33:22PM +0300, Henri Kemppainen wrote:
What happens when priv-swap_axes is set, and the ax ay branch is
taken along with the wsWheelEmuFilterMotion() branch. Following
continue another event is processed and now the axes are swapped again
(ax and ay were not reset after use) and then what? Not very likely
I know.
Ah, yes, there is the possibility of posting an inconsistent pointer sample
in this case. Perhaps we should only update the old_ax/old_ay if the
wsWheelEmuFilterMotion branch is not taken?
What do you think? And yes, this is a very very unlikely case. You could
argue it wouldn't matter even if it did happen.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Alternative solution without extra magic (need rebuild kernel).
Before (on example pms(4)):
* user move mouse
* pms(4) read state mouse and process it
* pms(4) send dx, dy and buttons in wscons
* wscons generate simple events
* ws(4) reads one event and process it immediately
After applying diff:
* user move mouse
* pms(4) read state mouse and process it
* pms(4) send dx, dy and buttons in wscons
* wscons generate simple events and adds SYNC event
* ws(4) reads events until it receives SYNC, and only then begins processing
Tested on mouse.
Comments ?
PS:
synaptics(4) is working on a similar basis
--
Alexandr Shadchin
Index: dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.48
diff -u -p -r1.48 pms.c
--- dev/pckbc/pms.c 20 Sep 2013 14:07:30 - 1.48
+++ dev/pckbc/pms.c 26 Oct 2013 15:09:53 -
@@ -1155,8 +1155,7 @@ pms_proc_synaptics(struct pms_softc *sc)
if (syn-wsmode == WSMOUSE_NATIVE) {
wsmouse_input(sc-sc_wsmousedev, buttons, x, y, z, w,
WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
- WSMOUSE_INPUT_ABSOLUTE_Z | WSMOUSE_INPUT_ABSOLUTE_W |
- WSMOUSE_INPUT_SYNC);
+ WSMOUSE_INPUT_ABSOLUTE_Z | WSMOUSE_INPUT_ABSOLUTE_W);
} else {
dx = dy = 0;
if (z SYNAPTICS_PRESSURE) {
@@ -1470,8 +1469,7 @@ pms_proc_alps(struct pms_softc *sc)
wsmouse_input(sc-sc_wsmousedev, buttons, x, y, z, w,
WSMOUSE_INPUT_ABSOLUTE_X | WSMOUSE_INPUT_ABSOLUTE_Y |
- WSMOUSE_INPUT_ABSOLUTE_Z | WSMOUSE_INPUT_ABSOLUTE_W |
- WSMOUSE_INPUT_SYNC);
+ WSMOUSE_INPUT_ABSOLUTE_Z | WSMOUSE_INPUT_ABSOLUTE_W);
alps-old_fin = fin;
} else {
@@ -2321,8 +2319,7 @@ elantech_send_input(struct pms_softc *sc
WSMOUSE_INPUT_ABSOLUTE_X |
WSMOUSE_INPUT_ABSOLUTE_Y |
WSMOUSE_INPUT_ABSOLUTE_Z |
- WSMOUSE_INPUT_ABSOLUTE_W |
- WSMOUSE_INPUT_SYNC);
+ WSMOUSE_INPUT_ABSOLUTE_W);
} else {
dx = dy = 0;
Index: dev/wscons/wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.24
diff -u -p -r1.24 wsmouse.c
--- dev/wscons/wsmouse.c18 Oct 2013 13:54:09 - 1.24
+++ dev/wscons/wsmouse.c26 Oct 2013 15:09:55 -
@@ -452,13 +452,11 @@ wsmouse_input(struct device *wsmousedev,
ub ^= d;
}
- if (flags WSMOUSE_INPUT_SYNC) {
- NEXT;
- ev-type = WSCONS_EVENT_SYNC;
- ev-value = 0;
- TIMESTAMP;
- ADVANCE;
- }
+ NEXT;
+ ev-type = WSCONS_EVENT_SYNC;
+ ev-value = 0;
+ TIMESTAMP;
+ ADVANCE;
/* XXX fake wscons_event notifying wsmoused(8) to close mouse device */
if (flags WSMOUSE_INPUT_WSMOUSED_CLOSE) {
Index: dev/wscons/wsmousevar.h
===
RCS file: /cvs/src/sys/dev/wscons/wsmousevar.h,v
retrieving revision 1.6
diff -u -p -r1.6 wsmousevar.h
--- dev/wscons/wsmousevar.h 22 Jul 2012 18:28:36 - 1.6
+++ dev/wscons/wsmousevar.h 26 Oct 2013 15:09:55 -
@@ -74,7 +74,6 @@ int wsmousedevprint(void *, const char *
#define WSMOUSE_INPUT_WSMOUSED_CLOSE (13) /* notify wsmoused(8) to close
mouse device */
#define WSMOUSE_INPUT_ABSOLUTE_W (14)
-#define WSMOUSE_INPUT_SYNC (15)
void wsmouse_input(struct device *kbddev, u_int btns,
int x, int y, int z, int w, u_int flags);
Index: ws.c
===
RCS file: /cvs/xenocara/driver/xf86-input-ws/src/ws.c,v
retrieving revision 1.58
diff -u -p -r1.58 ws.c
--- ws.c20 Jul 2013 13:24:50 - 1.58
+++ ws.c26 Oct 2013 16:03:01 -
@@
Re: Remove unused variable in arch/i386/i386/lapic.c
Hi I have noted that scaled_pentium_mhz variable in i386/lapic.c is defined and initialized, but never used anywhere (grep -R scaled_pentium_mhz /usr/src say nothing [after patch applied]). Remove it ? Good cache. Committed. Thanks. Index: arch/i386/i386/lapic.c === RCS file: /cvs/src/sys/arch/i386/i386/lapic.c,v retrieving revision 1.32 diff -u -p -r1.32 lapic.c --- arch/i386/i386/lapic.c2 Jun 2013 18:16:42 - 1.32 +++ arch/i386/i386/lapic.c26 Oct 2013 14:35:03 - @@ -234,7 +234,6 @@ u_int32_t lapic_per_second; u_int32_t lapic_frac_usec_per_cycle; u_int64_t lapic_frac_cycle_per_usec; u_int32_t lapic_delaytab[26]; -u_int64_t scaled_pentium_mhz; void lapic_clockintr(void *arg) @@ -368,8 +367,6 @@ lapic_calibrate_timer(struct cpu_info *c tmp = (lapic_per_second * (u_int64_t)1 32) / 100; lapic_frac_cycle_per_usec = tmp; - - scaled_pentium_mhz = (1ULL 32) / cpuspeed; /* * Compute delay in cycles for likely short delays in usec.
date(1) STANDARDS bump
hi! further to another discussion on tech, i'm looking to document those options which posix say we should, but we do not. it should be only for a very small number of utilities, and pretty straightforward (famous last...) anyway, i wanted to post the date(1) part since it's a bit more controversial. posix lists this format as an xsi extension: mmddhhmm[[cc]yy] however we support this format: [cc]yy]mm]dd]HH]MM[.SS] just posting in case i've horribly misunderstood something. i'll commit, barring objection. jmc Index: date.1 === RCS file: /cvs/src/bin/date/date.1,v retrieving revision 1.59 diff -u -r1.59 date.1 --- date.1 31 Aug 2011 08:48:40 - 1.59 +++ date.1 26 Oct 2013 17:09:59 - @@ -224,6 +224,14 @@ The flags .Op Fl adjrtz are extensions to that specification. +.Pp +The order of the components of the argument +.Dq ccyymmddHHMM.SS +differs between this implementation and +.St -p1003.1-2008 . +In fact the standard does not recognise the +.Dq SS +component at all. .Sh HISTORY A .Nm
Re: date(1) STANDARDS bump
Date: Sat, 26 Oct 2013 18:16:50 +0059 From: Jason McIntyre j...@kerhand.co.uk hi! further to another discussion on tech, i'm looking to document those options which posix say we should, but we do not. it should be only for a very small number of utilities, and pretty straightforward (famous last...) anyway, i wanted to post the date(1) part since it's a bit more controversial. posix lists this format as an xsi extension: mmddhhmm[[cc]yy] however we support this format: [cc]yy]mm]dd]HH]MM[.SS] just posting in case i've horribly misunderstood something. i'll commit, barring objection. I have to disagree with this change. It sounds too much like we're making excuses. The XSI extensions are not really part of POSIX. They're just part of the recent POSIX documents because X/Open and POSIX were merged. X/Open has always bean biased towards System V, and one of thereasons why the XSI extension option exists in the current joint standard is that X/Open sometimes conflicts with traditional BSD behaviour. So a better way to document this would be to say that we don't support the XSI extension format mmddhhmm[[cc]yy] and instead supports the traditional BSD format [cc]yy]mm]dd]HH]MM[.SS] which is obviously superior. Cheers, Mark Index: date.1 === RCS file: /cvs/src/bin/date/date.1,v retrieving revision 1.59 diff -u -r1.59 date.1 --- date.131 Aug 2011 08:48:40 - 1.59 +++ date.126 Oct 2013 17:09:59 - @@ -224,6 +224,14 @@ The flags .Op Fl adjrtz are extensions to that specification. +.Pp +The order of the components of the argument +.Dq ccyymmddHHMM.SS +differs between this implementation and +.St -p1003.1-2008 . +In fact the standard does not recognise the +.Dq SS +component at all. .Sh HISTORY A .Nm
Re: date(1) STANDARDS bump
On Sat, Oct 26, 2013 at 07:48:03PM +0200, Mark Kettenis wrote: Date: Sat, 26 Oct 2013 18:16:50 +0059 From: Jason McIntyre j...@kerhand.co.uk hi! further to another discussion on tech, i'm looking to document those options which posix say we should, but we do not. it should be only for a very small number of utilities, and pretty straightforward (famous last...) anyway, i wanted to post the date(1) part since it's a bit more controversial. posix lists this format as an xsi extension: mmddhhmm[[cc]yy] however we support this format: [cc]yy]mm]dd]HH]MM[.SS] just posting in case i've horribly misunderstood something. i'll commit, barring objection. I have to disagree with this change. It sounds too much like we're making excuses. The XSI extensions are not really part of POSIX. They're just part of the recent POSIX documents because X/Open and POSIX were merged. X/Open has always bean biased towards System V, and one of thereasons why the XSI extension option exists in the current joint standard is that X/Open sometimes conflicts with traditional BSD behaviour. So a better way to document this would be to say that we don't support the XSI extension format mmddhhmm[[cc]yy] and instead supports the traditional BSD format [cc]yy]mm]dd]HH]MM[.SS] which is obviously superior. Cheers, Mark yes, fair point. how about the following: Index: date.1 === RCS file: /cvs/src/bin/date/date.1,v retrieving revision 1.59 diff -u -r1.59 date.1 --- date.1 31 Aug 2011 08:48:40 - 1.59 +++ date.1 26 Oct 2013 18:30:23 - @@ -224,6 +224,14 @@ The flags .Op Fl adjrtz are extensions to that specification. +.Pp +This implementation supports the traditional +.Bx +date format +.Dq ccyymmddHHMM.SS , +which differs from the +.St -xpg4 +specification. .Sh HISTORY A .Nm
Re: Stairstep mouse motion
From: Alexandr Shadchin Before (on example pms(4)): * user move mouse * pms(4) read state mouse and process it * pms(4) send dx, dy and buttons in wscons * wscons generate simple events * ws(4) reads one event and process it immediately After applying diff: * user move mouse * pms(4) read state mouse and process it * pms(4) send dx, dy and buttons in wscons * wscons generate simple events and adds SYNC event * ws(4) reads events until it receives SYNC, and only then begins processing Tested on mouse. Comments ? PS: synaptics(4) is working on a similar basis Absolutely yes for this. This is one of the approaches I originally considered, but then feared it'd be too intrusive. I didn't realize WS_INPUT_SYNC was already a thing and that we're doing this with synaptics. This'll also fix another downside which I mentioned with the previous approach (that it could join two unrelated x y events if they follow each other). I'm busy crossing the time_t chasm and compiling ports because the packages on mirrors haven't gotten across the libstdc++ bump (damnit). I'll try take a better look at your diff and test it tomorrow.
unable to down vlan(4) interfaces in 5.4-RELEASE
In 5.4-RELEASE, I just noticed that even when an interface is down (i.e. ifconfig vlan7 down), the link-local route remains active. According to ifconfig(8), in the section talking about the down subcommand: This action automatically disables routes using the interface. ...yet that isn't happening for me. Here's (hopefully) all the information anyone's going to ask for right now ===hostname.vlan7=== description MBIX_BGP vlan 7 vlandev trunk0 inet 206.72.208.16/24 inet6 2001:504:26::6:2752:1/64 down ===netstat -rn -f inet=== Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default198.51.75.2UGS4 1745 - 8 vlan5 10.0.1/24 link#16UC 00 - 4 vlan6 127/8 127.0.0.1 UGRS 00 33144 8 lo0 127.0.0.1 127.0.0.1 UH 00 33144 4 lo0 184.70.48.184/29 link#12C 00 - 4 vlan2 192.168.160/24 link#15UC 10 - 4 vlan4 192.168.160.88 00:24:a5:af:25:18 UHLc 0 14 - 4 vlan4 198.51.75/24 link#9 UC 10 - 4 vlan5 198.51.75.2f2:f2:be:d0:0e:67 UHLc 10 - 4 vlan5 204.16.160.160/29 link#14UC 00 - 4 vlan207 206.72.208/24 link#17C 00 - 4 vlan7 224/4 127.0.0.1 URS00 33144 8 lo0 **Note 206.72.208/24 route via vlan7 is still present. ** ===ping 206.72.208.12 [which is up and alive at the moment]=== PING 206.72.208.12 (206.72.208.12): 56 data bytes ping: sendto: Network is down ping: wrote 206.72.208.12 64 chars, ret=-1 ===ping 8.8.8.8 [just to prove my default gateway works]=== PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=48 time=49.026 ms ===ifconfig vlan7=== vlan7: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:26:6c:f1:58:b4 description: MBIX_BGP priority: 0 vlan: 7 parent interface: trunk0 groups: vlan status: active inet6 fe80::226:6cff:fef1:58b4%vlan7 prefixlen 64 scopeid 0x11 inet 206.72.208.16 netmask 0xff00 broadcast 206.72.208.255 inet6 2001:504:26::6:2752:1 prefixlen 64 **Note distinct lack of UP flag. I'm not sure why status=active, nor precisely what that means.** Weirder... if I re-display the v4 routes, I now see 206.72.208/24 link#17C 30 - 4 vlan7 206.72.208.1 link#17HLc01 - 4 vlan7 206.72.208.11 link#17HLc03 - 4 vlan7 206.72.208.12 link#17HLc01 - 4 vlan7 That's definitely not supposed to happen on a down'ed interface. Ah, crap. And arp(8) is showing me incompletes. So, basically, you can't ever down a vlan(4) interface??? (Yeah, I just tried ifconfig vlan7 down and re-tested. Same results. Ack.) I want the link down because my layer 1 connection to that network doesn't exist right now but I don't want to completely remove the interface configuration. I must be missing something here... (I don't have any other multihomed hosts to test this on at the moment. 5.4-RELEASE installed from CD.) Help!? -- -Adam Thompson athom...@athompso.net
