Hi!
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-28 14:04:15+03:00, [email protected]
Small fix to assign continuous values to KEY_*.
===================================================================
input.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
===================================================================
diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h Tue Jul 30 12:25:20 2002
+++ b/include/linux/input.h Tue Jul 30 12:25:20 2002
@@ -473,11 +473,11 @@
#define KEY_RESTART 0x198
#define KEY_SLOW 0x199
#define KEY_SHUFFLE 0x19a
-#define KEY_BREAK 0x1ab
+#define KEY_BREAK 0x19b
#define KEY_PREVIOUS 0x19c
#define KEY_DIGITS 0x19d
#define KEY_TEEN 0x19e
-#define KEY_TWEN 0x1af
+#define KEY_TWEN 0x19f
#define KEY_MAX 0x1ff
===================================================================
This BitKeeper patch contains the following changesets:
1.448.1.1
## Wrapped with gzip_uu ##
begin 664 bkpatch11183
M'XL(`)!I1CT``[64:VO;,!2&/UN_0I!O*Y$E6;[$D)%>PC92MI"NC'T:BBS'
M;ARY6'(NPS]^LM,TI;0-NUD&<:37Q^_1>5`/WFI9Q<ZZO#-29*`'/Y;:Q(ZN
MM43BIXUG96EC-RM7TGU0N?.EFZO[V@"[/^5&9'`M*QT[!'F/*V9W+V-G-OYP
M>WT^`V`XA)<95PMY(PT<#H$IJS4O$CWB)BM*A4S%E5Y)PY$H5\VCM*$84SM\
M$GK8#QH28!8V@B2$<$9D@BF+`@8>C(W,)B_R1690+3;6_O,\(?4)\P+L-S[U
M_!!<08(8BQ!!!&+JXM"E$20LQBPF_AGV8HSA76ES*)1()>OM*+>I:Z0E/".P
MC\$%_+=U7`(!;U:\*&":;VUNR+7.%PJ*4IE<U66MH?U;+76[-QE___$.@0GT
M*0D#,#T>,.C_Y@,`YAB\/U%-KD11)](MK)7MG@"4/:ULP$@3,$:B)O7H/*)>
M$*022XZC5X[QK90AC0C!#$<-]L-!T"'THOPT3G]A_%6TWG2^QXQ:YY'M3(L9
MH<\)P]$)PBCLT_]"V/Z;Y(!2F78H7<S&YQ/(5=)%7[^-/[>055);`_)`8&YV
MK7XI=P<2.P#;_GR!_6K3O9:GZ<NM^@,PKU@80`(^[:=>(M-<R:-AQ\%;,IA;
E680[63<]E;65[%7I\;X2F11+7:^&<^$-`C_$X!=E/SR="@4`````
`
end
--
Vojtech Pavlik
SuSE Labs
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-30 11:54:26+02:00, [email protected]
This simplifies the software autorepeat code in input/input.c,
also killing a race which could be the cause of autorepeat not
stopping after a key was released.
===================================================================
input.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
===================================================================
diff -Nru a/drivers/input/input.c b/drivers/input/input.c
--- a/drivers/input/input.c Tue Jul 30 12:26:59 2002
+++ b/drivers/input/input.c Tue Jul 30 12:26:59 2002
@@ -100,18 +100,14 @@
if (code > KEY_MAX || !test_bit(code, dev->keybit) || !!test_bit(code, dev->key) == value)
return;
- if (value == 2) break;
+ if (value == 2)
+ break;
change_bit(code, dev->key);
- if (test_bit(EV_REP, dev->evbit) && dev->timer.function) {
- if (value) {
- mod_timer(&dev->timer, jiffies + dev->rep[REP_DELAY]);
- dev->repeat_key = code;
- break;
- }
- if (dev->repeat_key == code)
- del_timer(&dev->timer);
+ if (test_bit(EV_REP, dev->evbit) && value) {
+ dev->repeat_key = code;
+ mod_timer(&dev->timer, jiffies + dev->rep[REP_DELAY]);
}
break;
@@ -204,8 +200,13 @@
static void input_repeat_key(unsigned long data)
{
struct input_dev *dev = (void *) data;
+
+ if (!test_bit(dev->repeat_key, dev->key))
+ return;
+
input_event(dev, EV_KEY, dev->repeat_key, 2);
input_sync(dev);
+
mod_timer(&dev->timer, jiffies + dev->rep[REP_PERIOD]);
}
@@ -268,6 +269,7 @@
*
* Returns nothing.
*/
+
#define input_find_and_remove(type, initval, targ, next) \
do { \
type **ptr; \
@@ -513,7 +515,7 @@
* Kill any pending repeat timers.
*/
- del_timer(&dev->timer);
+ del_timer_sync(&dev->timer);
/*
* Notify handlers.
===================================================================
This BitKeeper patch contains the following changesets:
1.527
## Wrapped with gzip_uu ##
begin 664 bkpatch11222
M'XL(`/-I1CT``[54?V_:,!#]&W^*[email protected]"J:C:#;15JS1$UTG3-B&3
M7)J4D+#8`;'EP\\)E'6H6[5?222?[;OG=W?/.8`;A7FOL<SN-/H1.8!7F=*]
MABH46OX7,Q]GF9EWHFR.G:U79SKKQ.FBT,3LCZ3V(UABKGH-9MF[%;U>8*\Q
M'KZ\N;H8$]+OPXM(IK=XC1KZ?:*S?"F30)U+'259:NE<IFJ.6EI^-B]WKB6G
ME)O789Y-';=D+A5>Z;.`,2D8!I2+KBO(EMCYEO9^O(FE7<I,O*!".&0`S'*X
M!Y1WJ->Q*3#6<T2/N\>4]RB%/3@X9M"FY#G\6](OB`]OHUB!BN>+)`YC5*`C
M!)6%>B5S!%F8`W&!4H.?!0AQ"G79-\6W_)8!D(G*8!8G29S>@H1<^@BK*#8-
M\+,B"6"*-:8O32J0A0\QTTP;`*6SQ:(.#C7F!F*&:UA)!3DF*!4&%GD-]HEK
M"S+ZWD+2_LV'$"HI.7NBA$$>5TKJ_)#F@W(*,Y2N<$^<D@==FP=!Z`6FLQBR
M_:;]"JO2PXDCF%T*P;E3J_-1]Z>5^A>,=ZK5JSB);R-M%?[J*>;<84;'7)3"
MHQZME<SXOI"9_5,A<VBS_R/EZXV*U_NR;8'Z7$@5W:O3R#''2E2;VK^!=KZJ
M/R.2T>-M^`.U#1BU@9'+:N"DT6C$(1R9C`LT/07>K)8:TQSE[+3R]:!K?)D`
M^]Y7H]*3::R/AN\FX^&H!0$NVV>X-$M-.#R$&JL)7VN@>F^3\Z2Z/_TZ\]-Z
M;YX%$QW/,3\ZK-UJNP5W<5C?^&.X#_Y@CID,AE<7[S\U3\DEIRX(\I'4;)[M
MZ.P=M>5EK&:54XZZR--3$V;BNZ8`E>'1VA@XS*U*LAD,YV3#:Z+6J?^0G#E]
9]QOW(_1GJICW`S>8^HQ2\@UFTX*M,P8`````
`
end
--
Vojtech Pavlik
SuSE Labs
On Tue, Jul 30, 2002 at 12:29:18PM +0200, Vojtech Pavlik wrote:
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-30 15:02:05+02:00, [email protected]
Change the EVIOC?ABS ioctls to use structs rather than arrays of ints.
===================================================================
drivers/input/evdev.c | 27 +++++++++++++++++----------
include/linux/input.h | 12 ++++++++++--
2 files changed, 27 insertions(+), 12 deletions(-)
===================================================================
diff -Nru a/drivers/input/evdev.c b/drivers/input/evdev.c
--- a/drivers/input/evdev.c Tue Jul 30 15:21:38 2002
+++ b/drivers/input/evdev.c Tue Jul 30 15:21:38 2002
@@ -233,6 +233,7 @@
struct evdev_list *list = file->private_data;
struct evdev *evdev = list->evdev;
struct input_dev *dev = evdev->handle.dev;
+ struct input_absinfo abs;
int t, u;
if (!evdev->exist) return -ENODEV;
@@ -378,11 +379,14 @@
int t = _IOC_NR(cmd) & ABS_MAX;
- if (put_user(dev->abs[t], ((int *) arg) + 0)) return -EFAULT;
- if (put_user(dev->absmin[t], ((int *) arg) + 1)) return -EFAULT;
- if (put_user(dev->absmax[t], ((int *) arg) + 2)) return -EFAULT;
- if (put_user(dev->absfuzz[t], ((int *) arg) + 3)) return -EFAULT;
- if (put_user(dev->absflat[t], ((int *) arg) + 4)) return -EFAULT;
+ abs.value = dev->abs[t];
+ abs.minimum = dev->absmin[t];
+ abs.maximum = dev->absmax[t];
+ abs.fuzz = dev->absfuzz[t];
+ abs.flat = dev->absflat[t];
+
+ if (copy_to_user((void *) arg, &abs, sizeof(struct input_absinfo)))
+ return -EFAULT;
return 0;
}
@@ -391,11 +395,14 @@
int t = _IOC_NR(cmd) & ABS_MAX;
- if (get_user(dev->abs[t], ((int *) arg) + 0)) return -EFAULT;
- if (get_user(dev->absmin[t], ((int *) arg) + 1)) return -EFAULT;
- if (get_user(dev->absmax[t], ((int *) arg) + 2)) return -EFAULT;
- if (get_user(dev->absfuzz[t], ((int *) arg) + 3)) return -EFAULT;
- if (get_user(dev->absflat[t], ((int *) arg) + 4)) return -EFAULT;
+ if (copy_from_user(&abs, (void *) arg, sizeof(struct input_absinfo)))
+ return -EFAULT;
+
+ dev->abs[t] = abs.value;
+ dev->absmin[t] = abs.minimum;
+ dev->absmax[t] = abs.maximum;
+ dev->absfuzz[t] = abs.fuzz;
+ dev->absflat[t] = abs.flat;
return 0;
}
diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h Tue Jul 30 15:21:38 2002
+++ b/include/linux/input.h Tue Jul 30 15:21:38 2002
@@ -63,6 +63,14 @@
__u16 version;
};
+struct input_absinfo {
+ int value;
+ int minimum;
+ int maximum;
+ int fuzz;
+ int flat;
+};
+
#define EVIOCGVERSION _IOR('E', 0x01, int) /* get driver version */
#define EVIOCGID _IOR('E', 0x02, struct input_id) /* get device ID */
#define EVIOCGREP _IOR('E', 0x03, int[2]) /* get repeat settings */
@@ -79,8 +87,8 @@
#define EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len) /* get all sounds status */
#define EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + ev, len) /* get event bits */
-#define EVIOCGABS(abs) _IOR('E', 0x40 + abs, int[5]) /* get abs value/limits */
-#define EVIOCSABS(abs) _IOW('E', 0xc0 + abs, int[5]) /* set abs value/limits */
+#define EVIOCGABS(abs) _IOR('E', 0x40 + abs, struct input_absinfo) /* get abs value/limits */
+#define EVIOCSABS(abs) _IOW('E', 0xc0 + abs, struct input_absinfo) /* set abs value/limits */
#define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) /* send a force effect to a force feedback device */
#define EVIOCRMFF _IOW('E', 0x81, int) /* Erase a force effect */
===================================================================
This BitKeeper patch contains the following changesets:
1.528
## Wrapped with gzip_uu ##
begin 664 bkpatch20030
M'XL(`.*21CT``\U6;6_;-A#^+/Z*`P*L=A)+)/7NP%W2).V,%4C@+-N';0AH
MB;+8VI(A48Z3:?]]U$L<VW.=-=V`R8:DXQV/#Q\]=](!W.8\ZVN+])/D08P.
MX(<TEWTM+W*N!X_*'J6ILHTXG7&CC3+&GPV1S`N)E/^:R2"&!<_ROD9T<S4B
M'^:\KXTN/]Q^/!LA-!C`><R2";_A$@8#)--LP:9A?LID/$T3768LR6=<,CU(
M9^4JM*084_6SB6MBVRF)@RVW#$A("+,(#S&U/,="+;#3%O;V?#47^[9%G=+T
M'=-"%T!TFWJ`J8%=P\1`[#ZF?6P?56<,XYAE"MI83.9I$NH)ESHKX(A"#Z-W
M\.]"/T=!RPS(F,/ES\.K\^_/WMV`2`,YS=5JH#8%N<R*0.:0J45YID)9`BS+
MV$,.:00BD;F.?@33I]1'U\]4H]Y7'@AAAM';%S8IDF!:A-R8BJ18-EK0X_4-
M^Q8I'<LB7AF9=.Q1TW$BCCG#WFYR]V54]!&SRJPHM'SW17!A)BHY-DD,O@CY
M0@_6P%GJ4CH*I%MRWXN('UCC,&"6ZT=?`+<GXS,X;%'LU$+?&?ZRZ+\!]ZH`
MY+V8BDDL]2*XKPIA'W)J$\MT*EJI;^.Z*(C]MYJ@^VN"N-`C_TU5C+@LLD0D
M$V"M_-MBR/(Y"SB('!(1\*P2?LW]%?2R^_JO='R]^S&\HB"&U+2!(*W%4*>[
M8^-<)%$*ZGJ"+DR/@(V&IF>#AS1UJ&%=T5%P4'+@B]Y;-?"K_/UDY9R)1,R*
MV9I;C6Q&L.5V!%MN1$3%X^.:NS(W_5,FU_W*K/V_U1$B@DZ0SA_N9'I7D=KI
M+%(1PF%7]97),7RG9AQ#+AYY&G5V;;W;[=9YM*Q^3M"[?']V^_&GB@W?JMGP
MO9:-U5)1ELZ:Q9KTFTN^9K%F+VL4JPVOR#_9<#8$M_Z6_ZV(FN"GB(;_S8B6
MXS:DLK;\#<=/?F6=U"UA9WM[N25\0Y]%GU)5<XD>\H07RU.A6D*AYWQOHZ4>
M(=C"7HEMUW>:CF!^=4?`T*/_[]=D\Q[9:A<[B7E-NW"J)K"S6?R!-`4!GK19
MW3_KL+96FJNL5E[U;:VD/RN]7W@4*!IZICH?A#P224O'!T5'1RW5U;2[X=6H
M\^;RS3'@I87A")IBWE58FF8<PD1]E*F!!IEB8"84AX?&9OZ;C?R_/.4/_D'^
=_`OY5U^+0<R#SWDQ&[B1XY*0,_07/W.9&9H*````
`
end
--
Vojtech Pavlik
SuSE Labs
Hi!
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-30 15:19:33+02:00, [email protected]
Use stdint.h types instead of __u16 et al in input.h, to make life
easier for userspace people, as Brad Hards has suggested.
===================================================================
input.h | 74 ++++++++++++++++++++++++++++++++--------------------------------
1 files changed, 37 insertions(+), 37 deletions(-)
===================================================================
diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h Tue Jul 30 15:21:51 2002
+++ b/include/linux/input.h Tue Jul 30 15:21:51 2002
@@ -32,7 +32,7 @@
#else
#include <sys/time.h>
#include <sys/ioctl.h>
-#include <asm/types.h>
+#include <stdint.h>
#endif
/*
@@ -41,9 +41,9 @@
struct input_event {
struct timeval time;
- unsigned short type;
- unsigned short code;
- unsigned int value;
+ uint16_t type;
+ uint16_t code;
+ int32_t value;
};
/*
@@ -57,10 +57,10 @@
*/
struct input_id {
- __u16 bustype;
- __u16 vendor;
- __u16 product;
- __u16 version;
+ uint16_t bustype;
+ uint16_t vendor;
+ uint16_t product;
+ uint16_t version;
};
struct input_absinfo {
@@ -611,62 +611,62 @@
*/
struct ff_replay {
- __u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
- __u16 delay; /* Time to wait before to start playing an effect */
+ uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
+ uint16_t delay; /* Time to wait before to start playing an effect */
};
struct ff_trigger {
- __u16 button; /* Number of button triggering an effect */
- __u16 interval; /* Time to wait before an effect can be re-triggered (ms) */
+ uint16_t button; /* Number of button triggering an effect */
+ uint16_t interval; /* Time to wait before an effect can be re-triggered (ms) */
};
struct ff_envelope {
- __u16 attack_length; /* Duration of attack (ms) */
- __u16 attack_level; /* Level at beginning of attack */
- __u16 fade_length; /* Duration of fade (ms) */
- __u16 fade_level; /* Level at end of fade */
+ uint16_t attack_length; /* Duration of attack (ms) */
+ uint16_t attack_level; /* Level at beginning of attack */
+ uint16_t fade_length; /* Duration of fade (ms) */
+ uint16_t fade_level; /* Level at end of fade */
};
/* FF_CONSTANT */
struct ff_constant_effect {
- __s16 level; /* Strength of effect. Negative values are OK */
+ int16_t level; /* Strength of effect. Negative values are OK */
struct ff_envelope envelope;
};
/* FF_RAMP */
struct ff_ramp_effect {
- __s16 start_level;
- __s16 end_level;
+ int16_t start_level;
+ int16_t end_level;
struct ff_envelope envelope;
};
/* FF_SPRING of FF_FRICTION */
struct ff_condition_effect {
- __u16 right_saturation; /* Max level when joystick is on the right */
- __u16 left_saturation; /* Max level when joystick in on the left */
+ uint16_t right_saturation; /* Max level when joystick is on the right */
+ uint16_t left_saturation; /* Max level when joystick in on the left */
- __s16 right_coeff; /* Indicates how fast the force grows when the
+ int16_t right_coeff; /* Indicates how fast the force grows when the
joystick moves to the right */
- __s16 left_coeff; /* Same for left side */
+ int16_t left_coeff; /* Same for left side */
- __u16 deadband; /* Size of area where no force is produced */
- __s16 center; /* Position of dead zone */
+ uint16_t deadband; /* Size of area where no force is produced */
+ int16_t center; /* Position of dead zone */
};
/* FF_PERIODIC */
struct ff_periodic_effect {
- __u16 waveform; /* Kind of wave (sine, square...) */
- __u16 period; /* in ms */
- __s16 magnitude; /* Peak value */
- __s16 offset; /* Mean value of wave (roughly) */
- __u16 phase; /* 'Horizontal' shift */
+ uint16_t waveform; /* Kind of wave (sine, square...) */
+ uint16_t period; /* in ms */
+ int16_t magnitude; /* Peak value */
+ int16_t offset; /* Mean value of wave (roughly) */
+ uint16_t phase; /* 'Horizontal' shift */
struct ff_envelope envelope;
/* Only used if waveform == FF_CUSTOM */
- __u32 custom_len; /* Number of samples */
- __s16 *custom_data; /* Buffer of samples */
+ uint32_t custom_len; /* Number of samples */
+ int16_t *custom_data; /* Buffer of samples */
/* Note: the data pointed by custom_data is copied by the driver. You can
* therefore dispose of the memory after the upload/update */
};
@@ -677,22 +677,22 @@
by the heavy motor.
*/
struct ff_rumble_effect {
- __u16 strong_magnitude; /* Magnitude of the heavy motor */
- __u16 weak_magnitude; /* Magnitude of the light one */
+ uint16_t strong_magnitude; /* Magnitude of the heavy motor */
+ uint16_t weak_magnitude; /* Magnitude of the light one */
};
/*
* Structure sent through ioctl from the application to the driver
*/
struct ff_effect {
- __u16 type;
+ uint16_t type;
/* Following field denotes the unique id assigned to an effect.
* If user sets if to -1, a new effect is created, and its id is returned in the same field
* Else, the user sets it to the effect id it wants to update.
*/
- __s16 id;
+ int16_t id;
- __u16 direction; /* Direction. 0 deg -> 0x0000 (down)
+ uint16_t direction; /* Direction. 0 deg -> 0x0000 (down)
90 deg -> 0x4000 (left)
180 deg -> 0x8000 (up)
270 deg -> 0xC000 (right)
===================================================================
This BitKeeper patch contains the following changesets:
1.529
## Wrapped with gzip_uu ##
begin 664 bkpatch20062
M'XL(`.^21CT``[5666_;.!!^MG[%`'WH&5FWCVR*'EYL@UY!LGT.:(F2V$BD
M2U)V4OC'[Y"2+<M-6NSE!*9YS#<?9[X9Z1%\453.1VOQ5=.T=![!.Z'T?*0:
M1=WT.\XOA<#YN!0U'7>GQLN;,>.K1CNX?T%T6L*:2C4?^6ZX7]%W*SH?7?[^
MQY</KR\=Y^P,WI:$%_2*:C@[<[20:U)EZA71926XJR7AJJ::N*FHM_NCV\#S
M`OR+_4GHQ<G63[QHLDW]S/=)Y-/,"Z)I$CG+DDC$6K)B)7CF<JI=TARC(((?
M&JQM.`N"F;,`WXV#&7C!V)N,0P_\>.[/YF'XW`OFG@?=;5]UL8#G/IQXSAOX
M;ZF_=5*3`U`Z8UR[;>`4,*XT)1F('*ZO&S\!#!NI<!ELY-WR!?*`FMQ0J%A.
M$802Q:B$7$A`PE*M2$IA1<6JHB^`*'@C$>Z=B1.4.%5-45#TD;G.>PBG$R]V
M+OH4.2=_\^,X'O&<E[\(#N-IU61T7#'>W(Z[FQP&:A;YVR2*_.DV#X/E-`B3
M)*<>)=[T.!T_P[*9]F>AMPVB"6;:J._>X[]6XK]@_(`J?\7;(*-8HMG$*M2/
M?A"H]Y!`PPF<A)/_1:(?Q9H:Q0UE:K33AO@SG,B-_4<M7-P?[7\@JD48@^^<
MV^]''2C\MB/QTEE$$83.>93@]ZC!13^YUI;;Z<$\%9F9XS0,<(JA:7"^2#R(
MG/,DQ._^[+)1Q^9KRC,A#U=64F1-JH>'I&*"&UA,68"X?HQ#?Z"BO-#E*8R?
MP:*11.-A4]V$`\USFFI3V[5RX755@=`EEK)F-78"(BE6OA)`;U>2*D6S]B0\
M&Q^@9[0B=Z=@T/]$,Y.J#6%X'8H-H<L<D<@<CS%>'+A%&*0\LY0#;T!YV6B-
M5P(+^ZFIET@**;?+H"7#%B)_0.OM<:1&B*</T>KM4ORYI"#I20>+UWQ2JZ<M
MO2"RF0HF@U01K4EZ<]T%=G0<6+N[![G';$TK:_7!_,)E)%`PSLV%>ON!:4XR
M^I`_LW>/M\[D!U^HJ;V5O6,8&*6WPZ@7C36$-@576EK?QK"-FPN?:($4L#BM
MJENY?'[?04YM5D.3W#VDU4''J%]%.KNU11+%U@ZKZE`-F)=27RNBNTO;K'XD
MMRU)V)24PU=QIS3#L#$%1B(E;<V&,:EH/@3Z*1+?(1FS]F+1U,;*#J,AOU1@
M9&RHSWG&4J(Q)J788*"5MB@H/'PP%E)L5.L)%Q$R]BRD'48#HCWB%:FM?<M$
ML5WJXL#&*PX'\<KP^;TD/&M-V7=J524I,6XQ2UQT7#!6;4-!S9LX[=L6-?5C
MS2^$8CNA&5SX+OC.^0QB=(YM+#YPOB%K4V*UM7[/6K&917BB&,<W`O6M02ZN
MZQ[I=845+5K.?9O9;=:DX$QC#VY)47+3RFYP2.2YHMJ>^$BQK-L3>_=2-$59
MW1V[Q7<21#5&C]\)R?!^FE2/095LE_2D57,RVT79-O,4^[6H35%:CWV74J3&
M5Q\%:#SJR3WKSF=$$VOPIL%"&AA89U//.IOZ@Y0J+04OKOLP=,KMI@;%2*RD
M9'T'M<#'\/"6&XS8P/I^^\J6S#[#TU;M=CA^R"V266AW[;"_)LOL5MQNQ0/#
MC$GL'*;N;`O;S5SP4%H%G+P$[];##SS)Q(8_[5_RTY*F-ZJISY8DRF=YD#M_
)`4P*E3<_#```
`
end
--
Vojtech Pavlik
SuSE Labs
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-30 22:04:17+02:00, [email protected]
Hi Vojtech,
some superflous keyboard stuff came back with the last PPC merge
to Linus. This patch fixes that. Please apply.
lopec_setup.c | 13 -------------
1 files changed, 13 deletions(-)
diff -Nru a/arch/ppc/platforms/lopec_setup.c b/arch/ppc/platforms/lopec_setup.c
--- a/arch/ppc/platforms/lopec_setup.c Tue Jul 30 22:17:44 2002
+++ b/arch/ppc/platforms/lopec_setup.c Tue Jul 30 22:17:44 2002
@@ -34,14 +34,9 @@
#include <asm/mpc10x.h>
#include <asm/hw_irq.h>
#include <asm/prep_nvram.h>
-#include <asm/keyboard.h>
extern char saved_command_line[];
extern void lopec_find_bridges(void);
-extern int pckbd_translate(unsigned char scancode, unsigned char *keycode,
- char raw_mode);
-extern char pckbd_unexpected_up(unsigned char keycode);
-extern unsigned char pckbd_sysrq_xlate[128];
/*
* Define all of the IRQ senses and polarities. Taken from the
@@ -384,14 +379,6 @@
ppc_md.find_end_of_memory = lopec_find_end_of_memory;
ppc_md.setup_io_mappings = lopec_map_io;
-#ifdef CONFIG_VT
- ppc_md.kbd_translate = pckbd_translate;
- ppc_md.kbd_unexpected_up = pckbd_unexpected_up;
-#ifdef CONFIG_MAGIC_SYSRQ
- ppc_md.ppc_kbd_sysrq_xlate = pckbd_sysrq_xlate;
-#endif /* CONFIG_MAGIC_SYSRQ */
-#endif /* CONFIG_VT */
-
ppc_md.time_init = todc_time_init;
ppc_md.set_rtc_time = todc_set_rtc_time;
ppc_md.get_rtc_time = todc_get_rtc_time;
===================================================================
This BitKeeper patch contains the following changesets:
1.531
## Wrapped with gzip_uu ##
begin 664 bkpatch22903
M'XL(`&CT1CT``]5486_3,!#]7/^*D_9Q-/'%3M)6*BILP"0F476,K\AQW"74
MJ2/;Z=8J/QZOA56`T#:$D$@BV3[[WEW>>\D)7#ME)X.W5JQWT55M-3F!"^/\
M9*!%YY4MA*PB:9H07A@3PG%E&A5OS!>O9!47J[A>MYTG87\NO*Q@HZR;##!B
M#Q&_;=5DL'CS[OKRU8*0Z13.*K&^45?*PW1*O+$;H4LW$[[29AWYT(IKE!?W
M9?N'HWU":1+N%'-&TZS'C/*\EU@B"HZJI`D?99RT8J/TS'5.17+W<W;(Q'&:
M4-:S/,M3<@X8I0R!)C'-8T8A22:43S`_I6%"X<C*[$<VX!1A2,EK^+O-GQ$)
M%S5\.I#[(JQ<(!M<URJ[U*9SL%+;P@A;@O/=<@E2A.W0U`IN:Q^8KA1HX3S,
MYV?0*'NC`H0W<%FO.Q?!QZIVT.XU6=9WRH7SPD<PUTHX!:)M]38B[X&-^"@G
M\Z-*9/C,BQ`J*'D9:G6Z<S,?<$QT6$1FIT41!GO3"QL<U+8R;K7P2V,;%VO3
M*OG9*=^UD?S&&E+$!%/L&4MPW)>295B6DLNDR)*4_UZE)Q8(DH21(^\SRCC?
M._2QS'OC_I.W^U[%B:80S\#-DXR.$%G`33,VWEL=?W4Z?]SI%(;([email protected]'XT>
MP)YH]8/@'V!H;_=/L.[\4>W_X',X9SD@.><(/,Q'.8R./TQ9*;ER73,MTIR/
-QV-)O@+`_N;.E04`````
`
end
--
Vojtech Pavlik
SuSE Labs
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
'bk pull bk://linux-input.bkbits.net/linux-input' should work as well.
===================================================================
[email protected], 2002-07-30 21:52:03+02:00, [email protected]
Move sleep_on() above refrigerator so that the kseriod thread
in serio.c doesn't exit on suspend because of a pending signal.
serio.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
--- a/drivers/input/serio/serio.c Tue Jul 30 22:15:57 2002
+++ b/drivers/input/serio/serio.c Tue Jul 30 22:15:57 2002
@@ -95,9 +95,9 @@
do {
serio_handle_events();
+ interruptible_sleep_on(&serio_wait);
if (current->flags & PF_FREEZE)
refrigerator(PF_IOTHREAD);
- interruptible_sleep_on(&serio_wait);
} while (!signal_pending(current));
printk(KERN_DEBUG "serio: kseriod exiting");
===================================================================
This BitKeeper patch contains the following changesets:
1.530
## Wrapped with gzip_uu ##
begin 664 bkpatch22848
M'XL(`/WS1CT``[64:V_:,!2&/^-?<:1*VZJ*Q,Z5,#%U:W?3-@U1]3,RSH&X
MA!C9#JQ5?OR<E-&UT^BN2619;W)>G^/SQ$=P:5`/>V\TKVZ\"ZE+<@3OE+'#
M7LEKBWK&1>$)M7+R1"DG^X5:H;]15Q9%X<^6OJS6M27N_9A;4<`&M1GVF!?N
M%7N]QF%O\OKMY<>7$T)&(S@K>+7`"[0P&A&K](:7N3GEMBA5Y5F7BEFAY>VR
MS?[3)J`T<'?,TI#&2<,2&J6-8#EC/&*8TR`:)!'9)79J:H.>N'D8[V)9R+(P
M;,)!2F-R#LR+0PHT\&GJNTG`AG$PI.$)=2.%-=]@^<T,3ACT*7D%_S;E,R+@
MD]H@F!)Q/575LV/@LU;0.-=R@9J[!<$HL`6W;D!8NJ9)E;NY1IZ[>%E!)WD"
M<H6F>FH!OT@+RNFU66.5PPP%=W6`F@.'5I'5`HQ<5+STR`<(TR2-R?BN-Z3_
MFQ<AE%/RXI'=R;5L$?%%P;5_I:Z-E6+I[Y+_;L<B2N.&1DF6-"[Q>);A/!^D
M#)'?;\K>L./PUNB^7=OS+';3QOG&24?@@:#'F?S[$O:8VJTLY:*P7BVVOU9,
M$`6,15&T*Z8%./L!7_I3?-E_QM=A-E?Z`+JWR#ZDU'GL.&U9["K[#'V][1Z'
MUOA0Q_Z`U/=9"HST>K)R9YRNUU;.2ISN?\`GG?-TRZ4]?@[DG+F]9'=GG"A0
4+$V]&L48\T'(./D**"&1[T@%````
`
end
--
Vojtech Pavlik
SuSE Labs
On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> -#include <asm/types.h>
> +#include <stdint.h>
Why? I thought we were not including any glibc (or any other libc)
header files when building the kernel?
> - __u16 bustype;
> - __u16 vendor;
> - __u16 product;
> - __u16 version;
> + uint16_t bustype;
> + uint16_t vendor;
> + uint16_t product;
> + uint16_t version;
{sigh} __u16 is _so_ much nicer, and tells the programmer, "Yes I know
this variable needs to be the same size in userspace and in
kernelspace."
Just my two cents.
greg k-h
On Tue, 30 Jul 2002, Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > -#include <asm/types.h>
> > +#include <stdint.h>
>
> Why? I thought we were not including any glibc (or any other libc)
> header files when building the kernel?
Indeed. This is unacceptable.
Especially as the standard types are total crap, and the u8 etc are a lot
more readable. People should realize:
- the "int" is superfluous. Of _course_ it's an integer. If it was a
floating point number, it would be fp16/fp32/fp64/fp80/whatever.
- the "_t" is there only for namespace collisions, sane people can chose
to ignore it.
What do you have left after you have removed the crap? Yup. u8, u16, etc.
And if you want to share with user space, there's?the long-accepted
namespace collision avoidance of prepending two underscores.
Fix it, Vojtech.
Linus
On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > -#include <asm/types.h>
> > +#include <stdint.h>
>
> Why? I thought we were not including any glibc (or any other libc)
> header files when building the kernel?
Should be <linux/types.h>
> > - __u16 bustype;
> > - __u16 vendor;
> > - __u16 product;
> > - __u16 version;
> > + uint16_t bustype;
> > + uint16_t vendor;
> > + uint16_t product;
> > + uint16_t version;
>
> {sigh} __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> this variable needs to be the same size in userspace and in
> kernelspace."
I'll harp some more.
1. __u16 isn't really any nicer - its just what you (as a kernel programmer) are used to.
2. uint16_t is a *standard* type. Userspace programmer know it, even if they don't know Linux.
We shouldn't arbitrarily invent new types that could be trivially done with
standard types. Maybe we could retain existing usage for ABIs that are
unchanged from 2.0 days, but we certainly shouldn't be making the ABI
any worse.
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Tue, Jul 30, 2002 at 02:20:36PM -0700, Linus Torvalds wrote:
> On Tue, 30 Jul 2002, Greg KH wrote:
>
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why? I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
>
> Indeed. This is unacceptable.
>
> Especially as the standard types are total crap, and the u8 etc are a lot
> more readable. People should realize:
>
> - the "int" is superfluous. Of _course_ it's an integer. If it was a
> floating point number, it would be fp16/fp32/fp64/fp80/whatever.
> - the "_t" is there only for namespace collisions, sane people can chose
> to ignore it.
>
> What do you have left after you have removed the crap? Yup. u8, u16, etc.
> And if you want to share with user space, there's?the long-accepted
> namespace collision avoidance of prepending two underscores.
>
> Fix it, Vojtech.
>
> Linus
I will, and will do so happily. I don't like the uint*_t types as well.
This change was pushed very heavily for by Brad Hards, based on a
conclusion of a rather lengthy discussion (I think on linux-usb) on
which types should be used.
Now the question remaining is how to fix that? You can just skip the
patch. I've tried a 'bk undo', but that complains about unmerged leaves
in that case (though really nothing depends on those changes). Or should
I just make another cset on top of all the previous?
--
Vojtech Pavlik
SuSE Labs
On Wed, 31 Jul 2002, Brad Hards wrote:
>
> We shouldn't arbitrarily invent new types that could be trivially done with
> standard types. Maybe we could retain existing usage for ABIs that are
> unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> any worse.
I disagree.
I actively _dislike_ those stupid standard typenames. I don't want them in
the kernel, and they have no advantages over the standard kernel types
that have been there for a _loong_ time.
Linus
On Tue, 30 Jul 2002, Vojtech Pavlik wrote:
>
> Now the question remaining is how to fix that? You can just skip the
> patch. I've tried a 'bk undo', but that complains about unmerged leaves
> in that case (though really nothing depends on those changes). Or should
> I just make another cset on top of all the previous?
Ugh. there's a few things you can do
- I often actually do a "bk undo -axxx" and then just re-do the parts I
want to re-do.
NOTE! This only works if you haven't already had people pull from your
repository (or you'll need to ask them to do the "bk undo" as well).
- You can reverse the cset, which means that it's still there, but there
is also a cset that says "undo that other cset". I prefer to not pull
those kinds of undo's, but they do happen, and I occasionally do them
myself. I try to avoid it, but it's very useful for debugging ("does
that problem go away if I undo just that one cset?"), and sometimes
it _is_ the sanest way to go.
So do "bk cset -xA.BBB"
- in this case, maybe just adding a new cset is the proper thing.
Especially as reversing the cset doesn't actually get you where you
want anyway, since you'd still have to do the "unsigned short" -> "u16"
translation as yet another cset.
I only get upset if the tree looks _really_ cluttered, in which case I may
ask you to re-do it (that's happened once with the reiserfs tree).
Linus
On Wed, 31 Jul 2002 07:20, Linus Torvalds wrote:
> On Tue, 30 Jul 2002, Greg KH wrote:
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why? I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
>
> Indeed. This is unacceptable.
Its a minor thinko - <linux/types.h> is the right definition.
> Especially as the standard types are total crap, and the u8 etc are a lot
> more readable. People should realize:
>
> - the "int" is superfluous. Of _course_ it's an integer. If it was a
> floating point number, it would be fp16/fp32/fp64/fp80/whatever.
> - the "_t" is there only for namespace collisions, sane people can chose
> to ignore it.
Sure, it is a convention that only a committee could love.
But it is at least widely understood by userspace programmers.
> What do you have left after you have removed the crap? Yup. u8, u16, etc.
Fine for internal to the kernel. Absolutely. Required knowledge to play
with the kernel.
> And if you want to share with user space, there's the long-accepted
> namespace collision avoidance of prepending two underscores.
This is where we disagree. __u8 requires the (userspace) programmer
to go off, find out that __u8 is really some wierd Linux-ism that he
can safely map to uint8_t, to use with the rest of the *standard* library
routines.
> Fix it, Vojtech.
Please don't be hasty.
This isn't about the kernel representation. It is about making ABIs as
easy as possible for userspace programmers to use. If there is an
ugly but standard way, and an almost-as-ugly and non-standard way,
I don't think that the standard way is too much to ask.
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
Greg KH wrote:
> On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
>>- __u16 bustype;
>>- __u16 vendor;
>>- __u16 product;
>>- __u16 version;
>>+ uint16_t bustype;
>>+ uint16_t vendor;
>>+ uint16_t product;
>>+ uint16_t version;
>
>
> {sigh} __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> this variable needs to be the same size in userspace and in
> kernelspace."
Agreed, but u16 is even better :) Why use the '__' prefix when standard
kernel types do not need them?
Jeff
On Wed, Jul 31, 2002 at 07:26:05AM +1000, Brad Hards wrote:
> On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > -#include <asm/types.h>
> > > +#include <stdint.h>
> >
> > Why? I thought we were not including any glibc (or any other libc)
> > header files when building the kernel?
> Should be <linux/types.h>
It's #ifndef __KERNEL__ and if we #include <linux/types.h> and the user
#includes <stdint.h> elsewhere, we're going to get collisions.
I guess __u16 is really the safe way here.
> > > - __u16 bustype;
> > > - __u16 vendor;
> > > - __u16 product;
> > > - __u16 version;
> > > + uint16_t bustype;
> > > + uint16_t vendor;
> > > + uint16_t product;
> > > + uint16_t version;
> >
> > {sigh} __u16 is _so_ much nicer, and tells the programmer, "Yes I know
> > this variable needs to be the same size in userspace and in
> > kernelspace."
> I'll harp some more.
> 1. __u16 isn't really any nicer - its just what you (as a kernel programmer) are used to.
> 2. uint16_t is a *standard* type. Userspace programmer know it, even if they don't know Linux.
>
> We shouldn't arbitrarily invent new types that could be trivially done with
> standard types. Maybe we could retain existing usage for ABIs that are
> unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> any worse.
--
Vojtech Pavlik
SuSE Labs
On Tue, 30 Jul 2002, Linus Torvalds wrote:
>
> On Wed, 31 Jul 2002, Brad Hards wrote:
> >
> > We shouldn't arbitrarily invent new types that could be trivially done with
> > standard types. Maybe we could retain existing usage for ABIs that are
> > unchanged from 2.0 days, but we certainly shouldn't be making the ABI
> > any worse.
>
> I disagree.
>
> I actively _dislike_ those stupid standard typenames. I don't want them in
> the kernel, and they have no advantages over the standard kernel types
> that have been there for a _loong_ time.
Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
stop gcc from
#define uint8_t unsigned long long /* it is at least 8 bits */
ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
On Wed, 31 Jul 2002 07:42, Alexander Viro wrote:
<snip>
> Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
> stop gcc from
> #define uint8_t unsigned long long /* it is at least 8 bits */
Here is an extract from <linux/types.h>
typedef __u8 uint8_t;
typedef __u16 uint16_t;
> ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
I am not sure I understand the point you are trying to make.
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Tue, Jul 30, 2002 at 10:17:22PM +0200, Vojtech Pavlik wrote:
> do {
> serio_handle_events();
> + interruptible_sleep_on(&serio_wait);
> if (current->flags & PF_FREEZE)
> refrigerator(PF_IOTHREAD);
> - interruptible_sleep_on(&serio_wait);
> } while (!signal_pending(current));
Isn't interruptible_sleep_on() taboo?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tue, Jul 30, 2002 at 10:57:36PM +0100, Russell King wrote:
> On Tue, Jul 30, 2002 at 10:17:22PM +0200, Vojtech Pavlik wrote:
> > do {
> > serio_handle_events();
> > + interruptible_sleep_on(&serio_wait);
> > if (current->flags & PF_FREEZE)
> > refrigerator(PF_IOTHREAD);
> > - interruptible_sleep_on(&serio_wait);
> > } while (!signal_pending(current));
>
> Isn't interruptible_sleep_on() taboo?
As far as I know it only implies a bug when used with some condition,
like "buffer non-empty" etc. As always, I may be wrong, of course.
--
Vojtech Pavlik
SuSE Labs
Alexander Viro <[email protected]> writes:
> Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
> stop gcc from
> #define uint8_t unsigned long long /* it is at least 8 bits */
> ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
No. See C99 7.18.1.1:
7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with
width N, no padding bits, and a two's complement
representation. Thus, int8_t denotes a signed integer type
with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type
with width N. Thus, uint24_t denotes an unsigned integer
type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation
provides integer types with widths of 8, 16, 32, or 64 bits,
it shall define the corresponding typedef names.
--
"To the engineer, the world is a toy box full of sub-optimized and
feature-poor toys."
--Scott Adams
On Tue, 30 Jul 2002, Jeff Garzik wrote:
>
> Agreed, but u16 is even better :) Why use the '__' prefix when standard
> kernel types do not need them?
The __ thing is actually fairly useful, for a few reasons
- "u16" is namespace pollution and mustn't be exported by standard
user-level header files, since a program might use it as a variable
name.
- it shows which things are purely krnel internal (u16 is
kernel-internal, but a structure with __u16 is in a structure exported
to user space. Of course, some people seem to think that you should
always use the __u16 form, which is wrong. The underscores have
meaning, and the meaning is exactly that: exported to user space
headers as a size)
- typedef's are nasty, in that you cannot mix them. With a #define, you
can just have
#ifndef NULL
#define NULL ((void *)0)
#endif
and if everybody follows that convention, duplicating a few #defines
isn't a problem.
The same is _not_ true of typedefs. With typedefs, there can be only
one, and trying to avoid duplication with magic preprocessor rules
easily gets nasty. Sure, you can make up a rule like
#ifndef __typedef_xxxx_t
typedef ... xxxx_t;
#endif
but it's nowhere near as convenient as for #defines, and there is no
standard for this.
This nastiness is why everybody (including things like glibc) ends up
having to have an internal type and an external type anyway. Have you
ever wondered by the glibc header files internally use things like
__off_t, __locale_t etc? This is why. To avoid duplicate defines,
especially in the presense of complex #ifdef __BSD_SOURCE__ etc, the
internal type is defined unconditionally. The externally visible type
is only defined if it should be.
See the crap in <linux/types.h> on how the linux headers define things
like u_int8_t int8_t uint8_t depending on different #defines. Which is why
it is so convenient to have _one_true_ internal type (__u8) which you can
always depend on, regardless of who compiles you and with what options.
All the other types (inluding the "standard" uint8_t) simply cannot be
depended on.
Linus
On 30 Jul 2002, Ben Pfaff wrote:
> No. See C99 7.18.1.1:
[snip]
I stand corrected.
On Wed, 31 Jul 2002, Brad Hards wrote:
> On Wed, 31 Jul 2002 07:42, Alexander Viro wrote:
> <snip>
> > Strictly speaking, there might be a DISadvantage - IIRC, there's nothing to
> > stop gcc from
> > #define uint8_t unsigned long long /* it is at least 8 bits */
> Here is an extract from <linux/types.h>
> typedef __u8 uint8_t;
> typedef __u16 uint16_t;
>
> > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> I am not sure I understand the point you are trying to make.
The difference between compiler's "unsigned at least n bits" and kernel's
"unsigned exactly n bits". They may very well be the same on all platforms
we are interested in presuming that compiler is sane, but at the very least
the implied meaning is different.
On Wed, 31 Jul 2002, Brad Hards wrote:
>
> Here is an extract from <linux/types.h>
> typedef __u8 uint8_t;
> typedef __u16 uint16_t;
Yes, and the thing you snipped from it was that it's inside a #ifdef.
Now, that #ifdef will be on for the __KERNEL__, but somebody else might
have compiled with some -traditional switch or other that disabled
"uint8_t" or just screwed it up some other way.
> > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> I am not sure I understand the point you are trying to make.
I think the point Viro is making is that uint8_t actually exists on things
like old cray's too, even if end sup being a 64-bit entity.
I don't think that is correct, though. I think that comes from another
(proposed but not implemented) C language extension that would have
allowed something like that, namely the
int X:17;
syntax, where X would be guaranteed to be "17 bits or more". I don't
remember.
Linus
On Tue, Jul 30, 2002 at 02:46:12PM -0700, Linus Torvalds wrote:
> - in this case, maybe just adding a new cset is the proper thing.
> Especially as reversing the cset doesn't actually get you where you
> want anyway, since you'd still have to do the "unsigned short" -> "u16"
> translation as yet another cset.
Ok, here you go:
===================================================================
[email protected], 2002-07-30 23:54:08+02:00, [email protected]
Revert input.h back to kernel types.
input.h | 84 ++++++++++++++++++++++++++++++++--------------------------------
1 files changed, 42 insertions(+), 42 deletions(-)
diff -Nru a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h Wed Jul 31 00:01:00 2002
+++ b/include/linux/input.h Wed Jul 31 00:01:00 2002
@@ -32,7 +32,7 @@
#else
#include <sys/time.h>
#include <sys/ioctl.h>
-#include <stdint.h>
+#include <asm/types.h>
#endif
/*
@@ -41,9 +41,9 @@
struct input_event {
struct timeval time;
- uint16_t type;
- uint16_t code;
- int32_t value;
+ __u16 type;
+ __u16 code;
+ __s32 value;
};
/*
@@ -57,18 +57,18 @@
*/
struct input_id {
- uint16_t bustype;
- uint16_t vendor;
- uint16_t product;
- uint16_t version;
+ __u16 bustype;
+ __u16 vendor;
+ __u16 product;
+ __u16 version;
};
struct input_absinfo {
- int value;
- int minimum;
- int maximum;
- int fuzz;
- int flat;
+ __s32 value;
+ __s32 minimum;
+ __s32 maximum;
+ __s32 fuzz;
+ __s32 flat;
};
#define EVIOCGVERSION _IOR('E', 0x01, int) /* get driver version */
@@ -611,62 +611,62 @@
*/
struct ff_replay {
- uint16_t length; /* Duration of an effect in ms. All other times are also expressed in ms */
- uint16_t delay; /* Time to wait before to start playing an effect */
+ __u16 length; /* Duration of an effect in ms. All other times are also expressed in ms */
+ __u16 delay; /* Time to wait before to start playing an effect */
};
struct ff_trigger {
- uint16_t button; /* Number of button triggering an effect */
- uint16_t interval; /* Time to wait before an effect can be re-triggered (ms) */
+ __u16 button; /* Number of button triggering an effect */
+ __u16 interval; /* Time to wait before an effect can be re-triggered (ms) */
};
struct ff_envelope {
- uint16_t attack_length; /* Duration of attack (ms) */
- uint16_t attack_level; /* Level at beginning of attack */
- uint16_t fade_length; /* Duration of fade (ms) */
- uint16_t fade_level; /* Level at end of fade */
+ __u16 attack_length; /* Duration of attack (ms) */
+ __u16 attack_level; /* Level at beginning of attack */
+ __u16 fade_length; /* Duration of fade (ms) */
+ __u16 fade_level; /* Level at end of fade */
};
/* FF_CONSTANT */
struct ff_constant_effect {
- int16_t level; /* Strength of effect. Negative values are OK */
+ __s16 level; /* Strength of effect. Negative values are OK */
struct ff_envelope envelope;
};
/* FF_RAMP */
struct ff_ramp_effect {
- int16_t start_level;
- int16_t end_level;
+ __s16 start_level;
+ __s16 end_level;
struct ff_envelope envelope;
};
/* FF_SPRING of FF_FRICTION */
struct ff_condition_effect {
- uint16_t right_saturation; /* Max level when joystick is on the right */
- uint16_t left_saturation; /* Max level when joystick in on the left */
+ __u16 right_saturation; /* Max level when joystick is on the right */
+ __u16 left_saturation; /* Max level when joystick in on the left */
- int16_t right_coeff; /* Indicates how fast the force grows when the
+ __s16 right_coeff; /* Indicates how fast the force grows when the
joystick moves to the right */
- int16_t left_coeff; /* Same for left side */
+ __s16 left_coeff; /* Same for left side */
- uint16_t deadband; /* Size of area where no force is produced */
- int16_t center; /* Position of dead zone */
+ __u16 deadband; /* Size of area where no force is produced */
+ __s16 center; /* Position of dead zone */
};
/* FF_PERIODIC */
struct ff_periodic_effect {
- uint16_t waveform; /* Kind of wave (sine, square...) */
- uint16_t period; /* in ms */
- int16_t magnitude; /* Peak value */
- int16_t offset; /* Mean value of wave (roughly) */
- uint16_t phase; /* 'Horizontal' shift */
+ __u16 waveform; /* Kind of wave (sine, square...) */
+ __u16 period; /* in ms */
+ __s16 magnitude; /* Peak value */
+ __s16 offset; /* Mean value of wave (roughly) */
+ __u16 phase; /* 'Horizontal' shift */
struct ff_envelope envelope;
/* Only used if waveform == FF_CUSTOM */
- uint32_t custom_len; /* Number of samples */
- int16_t *custom_data; /* Buffer of samples */
+ __u32 custom_len; /* Number of samples */
+ __s16 *custom_data; /* Buffer of samples */
/* Note: the data pointed by custom_data is copied by the driver. You can
* therefore dispose of the memory after the upload/update */
};
@@ -677,22 +677,22 @@
by the heavy motor.
*/
struct ff_rumble_effect {
- uint16_t strong_magnitude; /* Magnitude of the heavy motor */
- uint16_t weak_magnitude; /* Magnitude of the light one */
+ __u16 strong_magnitude; /* Magnitude of the heavy motor */
+ __u16 weak_magnitude; /* Magnitude of the light one */
};
/*
* Structure sent through ioctl from the application to the driver
*/
struct ff_effect {
- uint16_t type;
+ __u16 type;
/* Following field denotes the unique id assigned to an effect.
* If user sets if to -1, a new effect is created, and its id is returned in the same field
* Else, the user sets it to the effect id it wants to update.
*/
- int16_t id;
+ __s16 id;
- uint16_t direction; /* Direction. 0 deg -> 0x0000 (down)
+ __u16 direction; /* Direction. 0 deg -> 0x0000 (down)
90 deg -> 0x4000 (left)
180 deg -> 0x8000 (up)
270 deg -> 0xC000 (right)
===================================================================
This BitKeeper patch contains the following changesets:
1.533
## Wrapped with gzip_uu ##
begin 664 bkpatch24435
M'XL(`)P,1ST``[56V7+;.!!\%K]BJO*0:TV!IPZO4SFTF[ARN>S-LPLB(1$Q
M"2@$*-DN??P.`%*4;">I[&&[2.&8GIZ>!N1'\$6Q>CI8RZ^:987W"-Y)I:<#
MU2CF9[<X/I<2Q\-"5FS8[AK.KX9<K!KMX?H9U5D!:U:KZ2#PH]V,OEFQZ>#\
MC[=?/KPZ][R3$WA34+%D%TS#R8FG9;VF9:Y>4EV44OBZID)53%,_D]5VMW4;
M$A+B;Q*,(I*DVR`E\6B;!7D0T#[email protected]<1I[?V+TK7_!Z_)E21O-ZCG-BH>0
M$`7?XR#91NF$1-X,`C^)(B#AD(R&$8$PFB;QE(R?DW!*"+05OVSU@.<!'!'O
M-?RW]-]X&9PSU%"#U=4O``NXPBQPQ6K!2JNF\KWW8&BGWEDOIG?TBS^>1RCQ
M7ORD!"ZRLLG9L.2BN1ZVK/;+F<3!-HWC8+Q=1.%\'$9INF"$43*^*]J/L$P_
M@B0FR3:()NG8^N3![3_WS+]@[/T:XR`*)A'9AO$HG%@'!<D]`R7?,U`<PE$<
M_B\6>BMWMKF\;(+TGGF<QI_AJ-[8/S3#V<-R_P-7S:($`N_4/A^UH/`[5=70
MY2]>>+,XAL@[C5-\#AQ%LW;<#3*9NX&*0D!Q&AS-4@*Q=YI&^&RWS1MU$+9F
M(I?U;KBJ9=YD>F^Y5EP*`S6"Q#L=!?@\3-*.*BYXU53]F%X?C!?-[6T_**DV
MF$$,(?)##X1=QI*)I2Z.8?@,9DU--68'N0`J@"T6+#.G'"KEPZNR!*D+5H/F
M%5-`:P:T5!+8]:IF2K'<[81GPPXZ9R6].08#_1?&F%YO*-<P9PM9VZ'2%.^1
M%6[C8KF7$S&0[,22#4E/=MYHC>J`Q?S45'.D@V3=-.B:+Y>LO@?5!G.!ERV*
M>/P]0GU0AA_G#&IVU&)B=4\J]=01"V/;Y7#4MYEJC6Z^;,4<W!73KNX0[L:L
M66E#/IA/.(VIEUP(4T<?W,<M:,Z^E\FLW<W3[K^7!9VX"[%UH5$"XU[S,L:Q
M[K!AX!2_T+5-:\*<4CY\8DO,OF;.GLX7G]^W@&/;P6CB.F@`;<=;-MT<$NEF
M9FF<V!@\=[NN8PL*?:FH;@NU#?Q(KQT[V!1,P%=YHS1'G;@"8X6"N;`]'4JV
M.$3Y(8SH8$R8*R<>6WWLJZ7NJ&42U;#BGHJ<9U2C#H7<H+1*6PRT5\9@6<N-
M<GEP$@$38@'M:R?X8A_O@E8VVK%0O&M5$EJ5DJA7*6<TGU.1NSA^RZQY:D9-
M1FR*D"T-5,A=.VAJIXY)G#%S/&SPF52\,Y1!A5LINKP3<RNE>,,E7=X-79OC
M4]G0]]R9RDS"$\4%^PW4MP9I^+Z_;\H5GE/IN.Y?&X9)19>":[R1'1E&KYRW
M]K;(Q4(Q;=<_,CRK;GV7MY;-LBAO#O(55"&@B7C\3M8<2]*T?`RJX%U[4^?6
MM'5K@^<@P]M;5N:PV5S]C:-HM2JQRQ@YZ$@]:W?G5%.[_76#9^1@N\TS)C;/
M..A[IW0MQ?*RK[SU9CLT$,9&!:/K&Z@D?AWOE;9!A0Y"'PXN[7'8=7+LS#QN
MS=Q_O\W22627[*NMC>=V(7$+21^3\QJO`7.<[%74C7P@:)TE'+T`<DWP!Y[D
=<B.>]O^%9P7+KE13G:0Q96F>Q=[?IV!"D>`+````
`
end
--
Vojtech Pavlik
SuSE Labs
On Tue, 30 Jul 2002, Alexander Viro wrote:
> > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
As the matter of fact, IHBW.
> > I am not sure I understand the point you are trying to make.
[email protected] (Vojtech Pavlik) wrote on 30.07.02 in <[email protected]>:
> On Wed, Jul 31, 2002 at 07:26:05AM +1000, Brad Hards wrote:
> > On Wed, 31 Jul 2002 07:09, Greg KH wrote:
> > > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote:
> > > > -#include <asm/types.h>
> > > > +#include <stdint.h>
> > >
> > > Why? I thought we were not including any glibc (or any other libc)
> > > header files when building the kernel?
> > Should be <linux/types.h>
>
> It's #ifndef __KERNEL__ and if we #include <linux/types.h> and the user
> #includes <stdint.h> elsewhere, we're going to get collisions.
>
> I guess __u16 is really the safe way here.
Well then, I guess the thing to do for the poor ignorant user space
programmers is to have one standard header somewhere which maps the
standard Linux kernel types to standard ISO C types. No?
MfG Kai
On Wed, Jul 31, 2002 at 10:55:54AM +0100, David Woodhouse wrote:
> [email protected] said:
> > Isn't interruptible_sleep_on() taboo?
>
> With the demise of cli() and the continued removal of the BKL, all users of
> sleep_on() are probably buggy. We should remove it completely.
Ok. Is the use in drivers/input/serio.c buggy?
What should be it replaced with?
--
Vojtech Pavlik
SuSE Labs
[email protected] said:
> Isn't interruptible_sleep_on() taboo?
With the demise of cli() and the continued removal of the BKL, all users of
sleep_on() are probably buggy. We should remove it completely.
--
dwmw2
On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote:
> [email protected] said:
> > Ok. Is the use in drivers/input/serio.c buggy?
>
> If it matters that the thread can miss wakeup events and sleep indefinitely
> while there's a 'SERIO_RESCAN' event pending, then yes it looks buggy.
>
> serio_thread() serio_rescan()
> -------------- --------------
>
> serio_handle_events();
> serio->event |= SERIO_RESCAN;
> wake_up(&serio_wait);
> sleep_on(&serio_wait);
>
> ...sleeps...
>
> If both serio_thread() and serio_rescan() hold the BKL you're OK. It looks
> like serio_rescan() doesn't, though.
Thanks for the explanation. Yes, this could happen.
> > What should be it replaced with?
>
> In general, the response 'anything but sleep_on' is considered appropriate.
> Try wait_event().
--
Vojtech Pavlik
SuSE Labs
[email protected] said:
> Ok. Is the use in drivers/input/serio.c buggy?
If it matters that the thread can miss wakeup events and sleep indefinitely
while there's a 'SERIO_RESCAN' event pending, then yes it looks buggy.
serio_thread() serio_rescan()
-------------- --------------
serio_handle_events();
serio->event |= SERIO_RESCAN;
wake_up(&serio_wait);
sleep_on(&serio_wait);
...sleeps...
If both serio_thread() and serio_rescan() hold the BKL you're OK. It looks
like serio_rescan() doesn't, though.
> What should be it replaced with?
In general, the response 'anything but sleep_on' is considered appropriate.
Try wait_event().
--
dwmw2
[email protected] said:
> On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote:
> > [email protected] said:
> > > Ok. Is the use in drivers/input/serio.c buggy?
> >
> > If it matters that the thread can miss wakeup events and sleep
> > indefinitely while there's a 'SERIO_RESCAN' event pending, then
> > yes it looks buggy.
<...>
> Thanks for the explanation. Yes, this could happen.
Quod Erat Demonstrandum.
Even people who can be assumed to have a clue can make the mistake of using
sleep_on() in spite of the fact that it's almost impossible to use
correctly.
It can be removed from 2.5 without much pain -- half the drivers are broken
anyway due to the removal of cli(). I'm running a kernel with sleep_on()
removed quite happily.
At Stephen's request, I'll wait a couple of days for ext3 to remove all use
of sleep_on() before submitting the patch. NFS wants fixing too, but other
than that the breakage seems remarkably slight.
--
dwmw2
On Tue, 2002-07-30 at 22:55, Ben Pfaff wrote:
> 1 The typedef name intN_t designates a signed integer type with
> width N, no padding bits, and a two's complement
> representation. Thus, int8_t denotes a signed integer type
> with a width of exactly 8 bits.
And arbitary alignment requirements. At least I see nothing in C99
saying that
uint8_t foo;
uint8_t bar;
isnt allowed to give you interesting suprises
Alan Cox <[email protected]> writes:
|> On Tue, 2002-07-30 at 22:55, Ben Pfaff wrote:
|> > 1 The typedef name intN_t designates a signed integer type with
|> > width N, no padding bits, and a two's complement
|> > representation. Thus, int8_t denotes a signed integer type
|> > with a width of exactly 8 bits.
|>
|> And arbitary alignment requirements. At least I see nothing in C99
|> saying that
|>
|> uint8_t foo;
|> uint8_t bar;
|>
|> isnt allowed to give you interesting suprises
If it's part of a structure, then yes. The C standard has always allowed
arbitrary padding between structure members. It's an ABI issue.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Wed, Jul 31, 2002 at 02:42:58PM +0100, Alan Cox wrote:
> On Tue, 2002-07-30 at 22:55, Ben Pfaff wrote:
> > 1 The typedef name intN_t designates a signed integer type with
> > width N, no padding bits, and a two's complement
> > representation. Thus, int8_t denotes a signed integer type
> > with a width of exactly 8 bits.
>
> And arbitary alignment requirements. At least I see nothing in C99
> saying that
>
> uint8_t foo;
> uint8_t bar;
>
> isnt allowed to give you interesting suprises
The problem here is footnote 215, which says "Some of these types may
denote implementation-defined extended integer types." The rest of
section 7.18 is built around a conceptual model of the extended integer
types as aliases to the standard types.
The standard almost surely means the smallest such type, but does
not in fact say that. The standards language appears to conflate the
value semantics with the representation width. (However, see the
description of int_leastN.) I will consider filing a defect report.
The C99 <stdint.h> types are the bastard child of a paper by Frank
Farance and myself on extended integer type semantics, combined with an
earlier [u]intN_t proposal. Our input to the C9x process largely ended
with the discussion of the original paper, for unrelated reasons.
The intention was to remove the ambiguity in much legacy code that used
"long" in two ways: as the largest integral type, and as an exact 32-bit
container. IIRC, the original proposal described integral types with the
following semantics:
exact<n>
exact [un]signed n-bit arithmetic in the smallest supported
integral container, so that if a standard type of width <n> bits
exists, then exact<n> corresponds to it. Hence sizeof(exact<8>)
== 1 on all sane platforms. Think bitfields in auto-sized
containers.
least<n> -
[un]signed arithmetic with the smallest integral type >= n bits
that is "natural" to the platform, typically half-register,
register, or double-register width. least<n> corresponds to exact<m>
for some m >= n.
fast<n>
the fastest "natural" (i.e., [half-]register) width for the platform,
to be used for accumulators, etc., where external representation
is unimportant.
Humbly,
Bill Rugolsky
commence Pavel Machek quotation:
> Hi!
>
> > > > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
> >
> > As the matter of fact, IHBW.
>
> pavel@Elf:~$ wtf ICBW
> Gee... I don't know what ICBW means...
"I Could Be Wrong".
> pavel@Elf:~$ wtf IHBW
> Gee... I don't know what IHBW means...
"I Have Been Wrong". This is a guess; IHBW is a new one on me.
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <[email protected]> | answers a prison for oneself.
\ |
Hi!
> > > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits?
>
> As the matter of fact, IHBW.
pavel@Elf:~$ wtf ICBW
Gee... I don't know what ICBW means...
pavel@Elf:~$ wtf IHBW
Gee... I don't know what IHBW means...
pavel@Elf:~$
Would you care to submit patch for wtf(6)? ;-)
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]