[patch] Small input fixes for 2.5.29 [1/2]

[patch] Small input fixes for 2.5.29 [1/2]

[Vojtech Pavlik]

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

[patch] Small input fixes for 2.5.29 [2/2]

[Vojtech Pavlik]

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

[patch] Input cleanups for 2.5.29 [1/2]

[Vojtech Pavlik]

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

[patch] Input cleanups for 2.5.29 [2/2]

[Vojtech Pavlik]

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

[patch] Fix suspend of the kseriod thread

[Vojtech Pavlik]

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

[patch] Remove superfluous code that snuck back in PPC merge

[Vojtech Pavlik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Greg KH]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus Torvalds]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad Hards]

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.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus Torvalds]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech Pavlik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad Hards]

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.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech Pavlik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander Viro]

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?

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Jeff Garzik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus Torvalds]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Brad Hards]

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.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Ben Pfaff]

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

Re: [patch] Fix suspend of the kseriod thread

[Russell King]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus Torvalds]

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

Re: [patch] Fix suspend of the kseriod thread

[Vojtech Pavlik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Vojtech Pavlik]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander Viro]

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.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander Viro]

On 30 Jul 2002, Ben Pfaff wrote:

> No.  See C99 7.18.1.1:

[snip]

I stand corrected.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Linus Torvalds]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alexander Viro]

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.

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Kai Henningsen]

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

Re: [patch] Fix suspend of the kseriod thread

[David Woodhouse]

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

Re: [patch] Fix suspend of the kseriod thread

[Vojtech Pavlik]

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

Re: [patch] Fix suspend of the kseriod thread

[David Woodhouse]

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

Re: [patch] Fix suspend of the kseriod thread

[Vojtech Pavlik]

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

sleep_on() DIE DIE DIE (was Re: [patch] Fix suspend of the kseriod thread)

[David Woodhouse]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Andreas Schwab]

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."

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Alan Cox]

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

extended integer types (was Re: [patch] Input cleanups for 2.5.29 [2/2])

[Bill Rugolsky Jr.]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Pavel Machek]

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

Re: [patch] Input cleanups for 2.5.29 [2/2]

[Sean Neakums]

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.
 \                          |