On Sat, 07 Jan 2006 23:11:07 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> wait_event(tty_ldisc_wait, tty_ldisc_try(tty));
That is more or less all right, I agree. It is still somewhat limited
because the lock cannot be held across the loop into its body, so
actions cannot be taken atomica
On Sad, 2006-01-07 at 14:18 -0800, Pete Zaitcev wrote:
> Using wait_for_event is never an improvement. It's just a retarded API,
> which allows you to save lines-of-code count at expense of being opaque
> and conflicting with proper locking.
Used properly it makes things very clear. In particular
On Sat, 7 Jan 2006, Pete Zaitcev wrote:
> Using wait_for_event is never an improvement. It's just a retarded API,
> which allows you to save lines-of-code count at expense of being opaque
> and conflicting with proper locking.
You know, it _is_ possible for the condition in wait_for_event to be a
Am Samstag, 7. Januar 2006 23:18 schrieb Pete Zaitcev:
> Using wait_for_event is never an improvement. It's just a retarded API,
Then go hence, code something better. The manual way made for to many
errors.
Regards
Oliver
-
On Sat, 7 Jan 2006 23:12:08 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> I can't argue personal taste. If you have better ideas about implementing
> waiting helpers, implement them and I'll use them. Until then what but
> the more or less canonical ways do you expect me to use? Compared to
>
Am Samstag, 7. Januar 2006 23:11 schrieb Pete Zaitcev:
> If it makes you feel better, find places which take sizeof of this
> structure and use defined size (which is there in headers specifically
> for this reason), like Stern said.
This is asking for trouble. If you want the size of a data struc
Am Samstag, 7. Januar 2006 23:05 schrieben Sie:
> On Sat, 7 Jan 2006 21:35:20 +0100 (CET), Oliver Neukum <[EMAIL PROTECTED]>
> wrote:
>
> > -general cleanup
>
> > It compiles and I am printing.
>
> Personallo, I cannot stand our wait_event interface. Its locking properties
> are extremely fishy
On Sat, 7 Jan 2006 21:52:04 +0100 (CET), Oliver Neukum <[EMAIL PROTECTED]>
wrote:
> after general heated discussion it seems that this is the
> save way to go. Please apply.
You still haven't demonstrated a failure case. Until proven, this
is absolutely unnecessary.
I actually paid attention to
Am Samstag, 7. Januar 2006 23:05 schrieb Pete Zaitcev:
> On Sat, 7 Jan 2006 21:35:20 +0100 (CET), Oliver Neukum <[EMAIL PROTECTED]>
> wrote:
>
> > -general cleanup
>
> > It compiles and I am printing.
>
> Personallo, I cannot stand our wait_event interface. Its locking properties
> are extremel
On Sat, 7 Jan 2006 21:35:20 +0100 (CET), Oliver Neukum <[EMAIL PROTECTED]>
wrote:
> -general cleanup
> It compiles and I am printing.
Personallo, I cannot stand our wait_event interface. Its locking properties
are extremely fishy and it adds insane obfuscation (basically people
who pass conditi
Hi,
after general heated discussion it seems that this is the
save way to go. Please apply.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- linux-2.6.15-vanilla/include/linux/usb_ch9.h2006-01-03
04:21:10.0 +0100
+++ linux-2.6.15/inclu
Hi,
this fixes
-potential hang by disconnecting through usbfs
-kzalloc
-general cleanup
-micro optimisation in interrupt handlers
It compiles and I am printing.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- a/drivers/usb/class/usblp.c 2006-01-03 04
For kernel versions starting at 2.6.14 my Saitek force-feedback driver
does not require this patch.
The particular bug it addresses was resolved with the inclusion of a
patch submitted by Vojtech Pavlik and Dmitry Torokhov on 10.09.2005:
[PATCH] Input: HID - fix URB success status handling
(htt
This patch has become mostly unnecessary with the changes included in
kernel 2.6.14.
Some of these changes were submitted in a patch with a similar title:
[PATCH 12/26] add HID simulation mappings
(http://lkml.org/lkml/2005/9/10/209)
I am surprised that Vojtech and Dmitry both did not mention t
On Sat, 7 Jan 2006, Helmut Toplitzer wrote:
I know nothing at all about this pvrusb driver. Your stack trace seems to
indicate that it might the problem (as opposed to any other part of the
USB stack).
OK. Maybe it's a pvrusb2 problem then. I'll cc to the pvrusb2-list.
Not to "toss this on
>
> I know nothing at all about this pvrusb driver. Your stack trace seems to
> indicate that it might the problem (as opposed to any other part of the
> USB stack).
OK. Maybe it's a pvrusb2 problem then. I'll cc to the pvrusb2-list.
The problem is that playing video stops sometimes. (Normaly af
On Sat, 7 Jan 2006, Helmut Toplitzer wrote:
> > Try doing this test in single-user mode. When you plug in the storage
> > device and it doesn't initialize, get a stack trace (Alt-SysRq-T). That
> > may help show where things are hanging up.
> >
>
> Sorry for the late answer. It was realy hard t
>
> Try doing this test in single-user mode. When you plug in the storage
> device and it doesn't initialize, get a stack trace (Alt-SysRq-T). That
> may help show where things are hanging up.
>
Sorry for the late answer. It was realy hard to reproduce today.
Sometimes it worked for more than 60
18 matches
Mail list logo
