Menu
▾
▴
linuxconsole-dev
|
From: Vojtech P. <vo...@su...> - 2002-07-30 10:27:59
|
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. =================================================================== ChangeSet@1.448.1.1, 2002-07-28 14:04:15+03:00, joh...@it... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 10:29:29
|
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. =================================================================== ChangeSet@1.527, 2002-07-30 11:54:26+02:00, vo...@su... 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^*FRI5185@.TY"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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 13:23:10
|
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. =================================================================== ChangeSet@1.528, 2002-07-30 15:02:05+02:00, bh...@bi... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 13:23:54
|
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. =================================================================== ChangeSet@1.529, 2002-07-30 15:19:33+02:00, vo...@su... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 20:17:45
|
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. =================================================================== ChangeSet@1.530, 2002-07-30 21:52:03+02:00, pa...@su... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 20:19:04
|
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. =================================================================== ChangeSet@1.531, 2002-07-30 22:04:17+02:00, Fra...@la... 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%(;(_@.K'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 |
|
From: Russell K. <rm...@ar...> - 2002-07-30 21:57:50
|
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 (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Vojtech P. <vo...@su...> - 2002-07-30 22:01:46
|
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
|
|
From: David W. <dw...@in...> - 2002-07-31 09:56:17
|
rm...@ar... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-31 09:58:56
|
On Wed, Jul 31, 2002 at 10:55:54AM +0100, David Woodhouse wrote: > rm...@ar... 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 |
|
From: David W. <dw...@in...> - 2002-07-31 10:17:39
|
vo...@su... 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 |
|
From: Vojtech P. <vo...@su...> - 2002-07-31 10:11:26
|
On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote: > vo...@su... 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 |
|
From: David W. <dw...@in...> - 2002-07-31 11:45:12
|
vo...@su... said: > On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote: > > vo...@su... 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 |
|
From: Greg KH <gr...@kr...> - 2002-07-30 21:11:01
|
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
|
|
From: Linus T. <tor...@tr...> - 2002-07-30 21:20:56
|
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> >=20 > 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= =20 more readable. People should realize: - the "int" is superfluous. Of _course_ it's an integer. If it was a=20 floating point number, it would be fp16/fp32/fp64/fp80/whatever. - the "_t" is there only for namespace collisions, sane people can chose= =20 to ignore it. What do you have left after you have removed the crap? Yup. u8, u16, etc.= =20 And if you want to share with user space, there's=A0the long-accepted=20 namespace collision avoidance of prepending two underscores. Fix it, Vojtech. Linus |
|
From: Vojtech P. <vo...@su...> - 2002-07-30 21:36:02
|
On Tue, Jul 30, 2002 at 02:20:36PM -0700, Linus Torvalds wrote: > On Tue, 30 Jul 2002, Greg KH wrote: >=20 > > On Tue, Jul 30, 2002 at 03:23:42PM +0200, Vojtech Pavlik wrote: > > > -#include <asm/types.h> > > > +#include <stdint.h> > >=20 > > Why? I thought we were not including any glibc (or any other libc) > > header files when building the kernel? >=20 > Indeed. This is unacceptable. >=20 > Especially as the standard types are total crap, and the u8 etc are a l= ot=20 > more readable. People should realize: >=20 > - the "int" is superfluous. Of _course_ it's an integer. If it was a=20 > floating point number, it would be fp16/fp32/fp64/fp80/whatever. > - the "_t" is there only for namespace collisions, sane people can cho= se=20 > to ignore it. >=20 > What do you have left after you have removed the crap? Yup. u8, u16, et= c.=20 > And if you want to share with user space, there's=A0the long-accepted=20 > namespace collision avoidance of prepending two underscores. >=20 > Fix it, Vojtech. >=20 > 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? --=20 Vojtech Pavlik SuSE Labs |
|
From: Linus T. <tor...@tr...> - 2002-07-30 21:46:17
|
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
|
|
From: Vojtech P. <vo...@su...> - 2002-07-30 22:03:10
|
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:
===================================================================
ChangeSet@1.533, 2002-07-30 23:54:08+02:00, vo...@su...
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#A@.0GC<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
|
|
From: Brad H. <bh...@bi...> - 2002-07-30 21:42:34
|
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. |
|
From: Brad H. <bh...@bi...> - 2002-07-30 21:31:01
|
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.
|
|
From: Linus T. <tor...@tr...> - 2002-07-30 21:35:36
|
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 |
|
From: Alexander V. <vi...@ma...> - 2002-07-30 21:42:38
|
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? |
|
From: Brad H. <bh...@bi...> - 2002-07-30 21:52:14
|
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. |
|
From: Alexander V. <vi...@ma...> - 2002-07-30 22:02:47
|
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. |
|
From: Alexander V. <vi...@ma...> - 2002-07-30 22:05:57
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X