* [patch] Small input fixes for 2.5.29 [1/2] @ 2002-07-30 10:26 Vojtech Pavlik 2002-07-30 10:29 ` [patch] Small input fixes for 2.5.29 [2/2] Vojtech Pavlik 0 siblings, 1 reply; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 10:26 UTC (permalink / raw) To: torvalds, linux-kernel, linuxconsole-dev, vojtech 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, johann.deneux@it.uu.se 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [patch] Small input fixes for 2.5.29 [2/2] 2002-07-30 10:26 [patch] Small input fixes for 2.5.29 [1/2] Vojtech Pavlik @ 2002-07-30 10:29 ` Vojtech Pavlik 2002-07-30 13:22 ` [patch] Input cleanups for 2.5.29 [1/2] Vojtech Pavlik 0 siblings, 1 reply; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 10:29 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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, vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [patch] Input cleanups for 2.5.29 [1/2] 2002-07-30 10:29 ` [patch] Small input fixes for 2.5.29 [2/2] Vojtech Pavlik @ 2002-07-30 13:22 ` Vojtech Pavlik 2002-07-30 13:23 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 0 siblings, 1 reply; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 13:22 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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, bhards@bigpond.net.au 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 13:22 ` [patch] Input cleanups for 2.5.29 [1/2] Vojtech Pavlik @ 2002-07-30 13:23 ` Vojtech Pavlik 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH 0 siblings, 2 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 13:23 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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, vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [patch] Fix suspend of the kseriod thread 2002-07-30 13:23 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik @ 2002-07-30 20:17 ` Vojtech Pavlik 2002-07-30 20:18 ` [patch] Remove superfluous code that snuck back in PPC merge Vojtech Pavlik ` (2 more replies) 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH 1 sibling, 3 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 20:17 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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, pavel@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [patch] Remove superfluous code that snuck back in PPC merge 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik @ 2002-07-30 20:18 ` Vojtech Pavlik 2002-07-30 21:57 ` [patch] Fix suspend of the kseriod thread Russell King 2002-07-31 9:55 ` David Woodhouse 2 siblings, 0 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 20:18 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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, Franz.Sirl@lauterbach.com 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik 2002-07-30 20:18 ` [patch] Remove superfluous code that snuck back in PPC merge Vojtech Pavlik @ 2002-07-30 21:57 ` Russell King 2002-07-30 22:00 ` Vojtech Pavlik 2002-07-31 9:55 ` David Woodhouse 2 siblings, 1 reply; 37+ messages in thread From: Russell King @ 2002-07-30 21:57 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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 (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-30 21:57 ` [patch] Fix suspend of the kseriod thread Russell King @ 2002-07-30 22:00 ` Vojtech Pavlik 0 siblings, 0 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 22:00 UTC (permalink / raw) To: Russell King; +Cc: Vojtech Pavlik, torvalds, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik 2002-07-30 20:18 ` [patch] Remove superfluous code that snuck back in PPC merge Vojtech Pavlik 2002-07-30 21:57 ` [patch] Fix suspend of the kseriod thread Russell King @ 2002-07-31 9:55 ` David Woodhouse 2002-07-31 9:58 ` Vojtech Pavlik 2002-07-31 10:07 ` David Woodhouse 2 siblings, 2 replies; 37+ messages in thread From: David Woodhouse @ 2002-07-31 9:55 UTC (permalink / raw) To: Russell King; +Cc: Vojtech Pavlik, torvalds, linux-kernel, linuxconsole-dev rmk@arm.linux.org.uk 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-31 9:55 ` David Woodhouse @ 2002-07-31 9:58 ` Vojtech Pavlik 2002-07-31 10:07 ` David Woodhouse 1 sibling, 0 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-31 9:58 UTC (permalink / raw) To: David Woodhouse Cc: Russell King, Vojtech Pavlik, linux-kernel, linuxconsole-dev On Wed, Jul 31, 2002 at 10:55:54AM +0100, David Woodhouse wrote: > rmk@arm.linux.org.uk 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-31 9:55 ` David Woodhouse 2002-07-31 9:58 ` Vojtech Pavlik @ 2002-07-31 10:07 ` David Woodhouse 2002-07-31 10:10 ` Vojtech Pavlik 2002-07-31 11:44 ` sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread) David Woodhouse 1 sibling, 2 replies; 37+ messages in thread From: David Woodhouse @ 2002-07-31 10:07 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Russell King, linux-kernel, linuxconsole-dev vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Fix suspend of the kseriod thread 2002-07-31 10:07 ` David Woodhouse @ 2002-07-31 10:10 ` Vojtech Pavlik 2002-07-31 11:44 ` sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread) David Woodhouse 1 sibling, 0 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-31 10:10 UTC (permalink / raw) To: David Woodhouse Cc: Vojtech Pavlik, Russell King, linux-kernel, linuxconsole-dev On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote: > vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread) 2002-07-31 10:07 ` David Woodhouse 2002-07-31 10:10 ` Vojtech Pavlik @ 2002-07-31 11:44 ` David Woodhouse 1 sibling, 0 replies; 37+ messages in thread From: David Woodhouse @ 2002-07-31 11:44 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Russell King, linux-kernel, linuxconsole-dev, torvalds vojtech@suse.cz said: > On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote: > > vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 13:23 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik @ 2002-07-30 21:09 ` Greg KH 2002-07-30 21:20 ` Linus Torvalds ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Greg KH @ 2002-07-30 21:09 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH @ 2002-07-30 21:20 ` Linus Torvalds 2002-07-30 21:35 ` Vojtech Pavlik 2002-07-30 21:38 ` Brad Hards 2002-07-30 21:26 ` Brad Hards 2002-07-30 21:45 ` Jeff Garzik 2 siblings, 2 replies; 37+ messages in thread From: Linus Torvalds @ 2002-07-30 21:20 UTC (permalink / raw) To: Greg KH; +Cc: Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:20 ` Linus Torvalds @ 2002-07-30 21:35 ` Vojtech Pavlik 2002-07-30 21:46 ` Linus Torvalds 2002-07-30 21:38 ` Brad Hards 1 sibling, 1 reply; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 21:35 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:35 ` Vojtech Pavlik @ 2002-07-30 21:46 ` Linus Torvalds 2002-07-30 22:02 ` Vojtech Pavlik 0 siblings, 1 reply; 37+ messages in thread From: Linus Torvalds @ 2002-07-30 21:46 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Greg KH, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:46 ` Linus Torvalds @ 2002-07-30 22:02 ` Vojtech Pavlik 0 siblings, 0 replies; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 22:02 UTC (permalink / raw) To: Linus Torvalds; +Cc: Vojtech Pavlik, Greg KH, linux-kernel, linuxconsole-dev 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, vojtech@suse.cz 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:20 ` Linus Torvalds 2002-07-30 21:35 ` Vojtech Pavlik @ 2002-07-30 21:38 ` Brad Hards 1 sibling, 0 replies; 37+ messages in thread From: Brad Hards @ 2002-07-30 21:38 UTC (permalink / raw) To: Linus Torvalds, Greg KH; +Cc: Vojtech Pavlik, linux-kernel, linuxconsole-dev 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH 2002-07-30 21:20 ` Linus Torvalds @ 2002-07-30 21:26 ` Brad Hards 2002-07-30 21:35 ` Linus Torvalds 2002-07-30 21:39 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 2002-07-30 21:45 ` Jeff Garzik 2 siblings, 2 replies; 37+ messages in thread From: Brad Hards @ 2002-07-30 21:26 UTC (permalink / raw) To: Greg KH, Vojtech Pavlik; +Cc: torvalds, linux-kernel, linuxconsole-dev 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:26 ` Brad Hards @ 2002-07-30 21:35 ` Linus Torvalds 2002-07-30 21:42 ` Alexander Viro 2002-07-30 21:39 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 1 sibling, 1 reply; 37+ messages in thread From: Linus Torvalds @ 2002-07-30 21:35 UTC (permalink / raw) To: Brad Hards; +Cc: Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:35 ` Linus Torvalds @ 2002-07-30 21:42 ` Alexander Viro 2002-07-30 21:47 ` Brad Hards 2002-07-30 21:55 ` Ben Pfaff 0 siblings, 2 replies; 37+ messages in thread From: Alexander Viro @ 2002-07-30 21:42 UTC (permalink / raw) To: Linus Torvalds Cc: Brad Hards, Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:42 ` Alexander Viro @ 2002-07-30 21:47 ` Brad Hards 2002-07-30 22:02 ` Alexander Viro 2002-07-30 22:04 ` Linus Torvalds 2002-07-30 21:55 ` Ben Pfaff 1 sibling, 2 replies; 37+ messages in thread From: Brad Hards @ 2002-07-30 21:47 UTC (permalink / raw) To: Alexander Viro, Linus Torvalds Cc: Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:47 ` Brad Hards @ 2002-07-30 22:02 ` Alexander Viro 2002-07-30 22:05 ` Alexander Viro 2002-07-30 22:04 ` Linus Torvalds 1 sibling, 1 reply; 37+ messages in thread From: Alexander Viro @ 2002-07-30 22:02 UTC (permalink / raw) To: Brad Hards Cc: Linus Torvalds, Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 22:02 ` Alexander Viro @ 2002-07-30 22:05 ` Alexander Viro 2002-08-01 10:49 ` Pavel Machek 0 siblings, 1 reply; 37+ messages in thread From: Alexander Viro @ 2002-07-30 22:05 UTC (permalink / raw) To: Brad Hards Cc: Linus Torvalds, Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 22:05 ` Alexander Viro @ 2002-08-01 10:49 ` Pavel Machek 2002-08-01 12:17 ` Sean Neakums 0 siblings, 1 reply; 37+ messages in thread From: Pavel Machek @ 2002-08-01 10:49 UTC (permalink / raw) To: Alexander Viro Cc: Brad Hards, Linus Torvalds, Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-08-01 10:49 ` Pavel Machek @ 2002-08-01 12:17 ` Sean Neakums 0 siblings, 0 replies; 37+ messages in thread From: Sean Neakums @ 2002-08-01 12:17 UTC (permalink / raw) To: linux-kernel 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; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:47 ` Brad Hards 2002-07-30 22:02 ` Alexander Viro @ 2002-07-30 22:04 ` Linus Torvalds 1 sibling, 0 replies; 37+ messages in thread From: Linus Torvalds @ 2002-07-30 22:04 UTC (permalink / raw) To: Brad Hards Cc: Alexander Viro, Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:42 ` Alexander Viro 2002-07-30 21:47 ` Brad Hards @ 2002-07-30 21:55 ` Ben Pfaff 2002-07-30 22:03 ` Alexander Viro 2002-07-31 13:42 ` Alan Cox 1 sibling, 2 replies; 37+ messages in thread From: Ben Pfaff @ 2002-07-30 21:55 UTC (permalink / raw) To: linux-kernel Alexander Viro <viro@math.psu.edu> 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:55 ` Ben Pfaff @ 2002-07-30 22:03 ` Alexander Viro 2002-07-31 13:42 ` Alan Cox 1 sibling, 0 replies; 37+ messages in thread From: Alexander Viro @ 2002-07-30 22:03 UTC (permalink / raw) To: Ben Pfaff; +Cc: linux-kernel On 30 Jul 2002, Ben Pfaff wrote: > No. See C99 7.18.1.1: [snip] I stand corrected. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:55 ` Ben Pfaff 2002-07-30 22:03 ` Alexander Viro @ 2002-07-31 13:42 ` Alan Cox 2002-07-31 12:57 ` Andreas Schwab 2002-07-31 14:01 ` extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2]) Bill Rugolsky Jr. 1 sibling, 2 replies; 37+ messages in thread From: Alan Cox @ 2002-07-31 13:42 UTC (permalink / raw) To: blp; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-31 13:42 ` Alan Cox @ 2002-07-31 12:57 ` Andreas Schwab 2002-07-31 14:01 ` extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2]) Bill Rugolsky Jr. 1 sibling, 0 replies; 37+ messages in thread From: Andreas Schwab @ 2002-07-31 12:57 UTC (permalink / raw) To: Alan Cox; +Cc: blp, linux-kernel Alan Cox <alan@lxorguk.ukuu.org.uk> 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, schwab@suse.de 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." ^ permalink raw reply [flat|nested] 37+ messages in thread
* extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2]) 2002-07-31 13:42 ` Alan Cox 2002-07-31 12:57 ` Andreas Schwab @ 2002-07-31 14:01 ` Bill Rugolsky Jr. 1 sibling, 0 replies; 37+ messages in thread From: Bill Rugolsky Jr. @ 2002-07-31 14:01 UTC (permalink / raw) To: Alan Cox; +Cc: blp, linux-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:26 ` Brad Hards 2002-07-30 21:35 ` Linus Torvalds @ 2002-07-30 21:39 ` Vojtech Pavlik 2002-07-30 22:46 ` Kai Henningsen 1 sibling, 1 reply; 37+ messages in thread From: Vojtech Pavlik @ 2002-07-30 21:39 UTC (permalink / raw) To: Brad Hards Cc: Greg KH, Vojtech Pavlik, torvalds, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:39 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik @ 2002-07-30 22:46 ` Kai Henningsen 0 siblings, 0 replies; 37+ messages in thread From: Kai Henningsen @ 2002-07-30 22:46 UTC (permalink / raw) To: vojtech; +Cc: linux-kernel vojtech@suse.cz (Vojtech Pavlik) wrote on 30.07.02 in <20020730233907.B23181@ucw.cz>: > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH 2002-07-30 21:20 ` Linus Torvalds 2002-07-30 21:26 ` Brad Hards @ 2002-07-30 21:45 ` Jeff Garzik 2002-07-30 21:59 ` Linus Torvalds 2 siblings, 1 reply; 37+ messages in thread From: Jeff Garzik @ 2002-07-30 21:45 UTC (permalink / raw) To: Greg KH; +Cc: Vojtech Pavlik, torvalds, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [patch] Input cleanups for 2.5.29 [2/2] 2002-07-30 21:45 ` Jeff Garzik @ 2002-07-30 21:59 ` Linus Torvalds 0 siblings, 0 replies; 37+ messages in thread From: Linus Torvalds @ 2002-07-30 21:59 UTC (permalink / raw) To: Jeff Garzik; +Cc: Greg KH, Vojtech Pavlik, linux-kernel, linuxconsole-dev 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2002-08-01 12:15 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-30 10:26 [patch] Small input fixes for 2.5.29 [1/2] Vojtech Pavlik 2002-07-30 10:29 ` [patch] Small input fixes for 2.5.29 [2/2] Vojtech Pavlik 2002-07-30 13:22 ` [patch] Input cleanups for 2.5.29 [1/2] Vojtech Pavlik 2002-07-30 13:23 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 2002-07-30 20:17 ` [patch] Fix suspend of the kseriod thread Vojtech Pavlik 2002-07-30 20:18 ` [patch] Remove superfluous code that snuck back in PPC merge Vojtech Pavlik 2002-07-30 21:57 ` [patch] Fix suspend of the kseriod thread Russell King 2002-07-30 22:00 ` Vojtech Pavlik 2002-07-31 9:55 ` David Woodhouse 2002-07-31 9:58 ` Vojtech Pavlik 2002-07-31 10:07 ` David Woodhouse 2002-07-31 10:10 ` Vojtech Pavlik 2002-07-31 11:44 ` sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread) David Woodhouse 2002-07-30 21:09 ` [patch] Input cleanups for 2.5.29 [2/2] Greg KH 2002-07-30 21:20 ` Linus Torvalds 2002-07-30 21:35 ` Vojtech Pavlik 2002-07-30 21:46 ` Linus Torvalds 2002-07-30 22:02 ` Vojtech Pavlik 2002-07-30 21:38 ` Brad Hards 2002-07-30 21:26 ` Brad Hards 2002-07-30 21:35 ` Linus Torvalds 2002-07-30 21:42 ` Alexander Viro 2002-07-30 21:47 ` Brad Hards 2002-07-30 22:02 ` Alexander Viro 2002-07-30 22:05 ` Alexander Viro 2002-08-01 10:49 ` Pavel Machek 2002-08-01 12:17 ` Sean Neakums 2002-07-30 22:04 ` Linus Torvalds 2002-07-30 21:55 ` Ben Pfaff 2002-07-30 22:03 ` Alexander Viro 2002-07-31 13:42 ` Alan Cox 2002-07-31 12:57 ` Andreas Schwab 2002-07-31 14:01 ` extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2]) Bill Rugolsky Jr. 2002-07-30 21:39 ` [patch] Input cleanups for 2.5.29 [2/2] Vojtech Pavlik 2002-07-30 22:46 ` Kai Henningsen 2002-07-30 21:45 ` Jeff Garzik 2002-07-30 21:59 ` Linus Torvalds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).