于 2012年11月09日 04:35, Dave, Tushar N 写道:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
On Behalf Of Joe Jin
Sent: Wednesday, November 07, 2012 10:25 PM
To: e1000-de...@lists.sf.net
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Mary
于 2012年11月09日 04:35, Dave, Tushar N 写道:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
On Behalf Of Joe Jin
Sent: Wednesday, November 07, 2012 10:25 PM
To: e1000-de...@lists.sf.net
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Mary
于 2012年07月06日 17:38, Li Yu 写道:
于 2012年06月15日 16:51, Eric Dumazet 写道:
On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote:
Of course, I think that implementing them should not be a hard work :)
Em. I really do not know whether it is necessary to introduce to a new
syscall here. An alternative
于 2012年07月06日 17:38, Li Yu 写道:
于 2012年06月15日 16:51, Eric Dumazet 写道:
On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote:
Of course, I think that implementing them should not be a hard work :)
Em. I really do not know whether it is necessary to introduce to a new
syscall here. An alternative
Hi, all:
I encountered a problem of using sk_buff.
I used 2.4.20 kernel, when burst traffic come, the kernel will complain
a bug report at skbuff.c:316 later:
311 void __kfree_skb(struct sk_buff *skb)
312 {
313 if (skb->list) {
314 printk(KERN_WARNING "Warning: kfree_skb passed an skb still "
Hi, all:
I encountered a problem of using sk_buff.
I used 2.4.20 kernel, when burst traffic come, the kernel will complain
a bug report at skbuff.c:316 later:
311 void __kfree_skb(struct sk_buff *skb)
312 {
313 if (skb-list) {
314 printk(KERN_WARNING Warning: kfree_skb passed an skb still
315
t seem I should give TASK_3 some extra credits
in some ways.
Sorry for such long mail and so bad English.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
credits
in some ways.
Sorry for such long mail and so bad English.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this,
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heur
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heur
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq->curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing & 32))
return;
if (rq->nr_running) {
delt
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair = div64_s(delta
);
Ingo, should we be replace "rq->nr_running" with "rq->raw_load_weight" here?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
be replace rq-nr_running with rq-raw_load_weight here?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
Li Yu wrote:
But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I
found the all waiting fields often are more than zero, or less than zero.
IMHO, the sum of task_struct->wait_runtime just is the denominator of
all runnable time in some ways, is it right? if so, increas
Li Yu wrote:
But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I
found the all waiting fields often are more than zero, or less than zero.
IMHO, the sum of task_struct-wait_runtime just is the denominator of
all runnable time in some ways, is it right? if so, increasing
ise. so what's
meaning for keeping the wait_runtime is zero-sum?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
. so what's
meaning for keeping the wait_runtime is zero-sum?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
a doubt when read this patch: in update_stats_enqueue(), It seem
that these statements in two brances of "if (p->load_weight >
NICE_0_LOAD)" are same,
is it on purpose?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
a doubt when read this patch: in update_stats_enqueue(), It seem
that these statements in two brances of if (p-load_weight
NICE_0_LOAD) are same,
is it on purpose?
Good luck
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Steven Rostedt wrote:
> Li Yu wrote:
>
>>> Now since mutexes can be defined by user-land applications, we don't
>>>
>> want a DOS
>>
>>> type of application that nests large amounts of mutexes to create a large
>>> PI cha
as it walks the PI chain. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in advanced
as it walks the PI chain. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in advanced
. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in advanced.
Good luck.
- Li Yu
. More about this below.
After read the implementation of rt_mutex_adjust_prio_chain(), I found
the we really require maximin lock depth (1024 default), but I can not
see the check for more same locks duplication. Does this doc is
inconsistent with code?
Thanks in advanced.
Good luck.
- Li Yu
Steven Rostedt wrote:
Li Yu wrote:
Now since mutexes can be defined by user-land applications, we don't
want a DOS
type of application that nests large amounts of mutexes to create a large
PI chain, and have the code holding spin locks while looking at a large
amount
put_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hidinput->input = input_dev;
+ if (!(hid->quirks_QUIRK_MULTI_INPUT))
+ hid_ff_init(hid);
+ }
+ return 0;
+}
+
+void hidinput_reconnect_core(s
.orig/drivers/hid/hid-simple.c1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21.1.new/drivers/hid/hid-simple.c 2007-04-30 10:59:47.0
+0800
@@ -0,0 +1,334 @@
+/*
+ * HID Simple Driver Interface v0.5.0
+ *
+ * Copyright (c) 2006 Li Yu [EMAIL PROTECTED
Jiri Kosina wrote:
> On Mon, 16 Apr 2007, Li Yu wrote:
>
>
>> HID bus prototype 20070416
>>
>
> Hi Li,
>
> thanks for taking care. Well, the patch is quite huge, do you think you
> could split it into separate independent parts (use quilt or somet
Jiri Kosina wrote:
On Mon, 16 Apr 2007, Li Yu wrote:
HID bus prototype 20070416
Hi Li,
thanks for taking care. Well, the patch is quite huge, do you think you
could split it into separate independent parts (use quilt or something
similar for patch management) which could
view that.
My friend yanghong buy a new bluetooth mouse, so I can test bluetooth
nowadays, Thanks him here. :D
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
It seem the hid-pidff driver also should be sticky.
Good luck
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
Hi,
It seem the hid-pidff driver also should be sticky.
Good luck
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
puts
member to hid_device, not in hid_driver. so if we removed one
hid_device, it do not disconnect all devices which its driver bind, just
only itself.
Now, usbhid works fine.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Dmitry Torokhov wrote:
>>> +int hid_open(struct hid_device *hid)
>>> +{
>>> + struct hid_transport *tl;
>>> + int ret;
>>> +
>>> + if (hid->driver->open)
>>> + return hid->driver->open(hid);
>>> + ret = 0;
>>> + spin_lock(_lock);
>>> + tl = hid_transports[hid->bus];
>>> +
Dmitry Torokhov wrote:
>> +static int hid_bus_match(struct device *dev, struct device_driver
>> *drv) +{
>> +struct hid_driver *hid_drv;
>> +struct hid_device *hid_dev;
>> +
>> +hid_drv = to_hid_driver(drv);
>> +hid_dev = to_hid_device(dev);
>> +
>> +if
, just
only itself.
Now, usbhid works fine.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dmitry Torokhov wrote:
+static int hid_bus_match(struct device *dev, struct device_driver
*drv) +{
+struct hid_driver *hid_drv;
+struct hid_device *hid_dev;
+
+hid_drv = to_hid_driver(drv);
+hid_dev = to_hid_device(dev);
+
+if (is_hid_driver_sticky(hid_drv))
+
Dmitry Torokhov wrote:
+int hid_open(struct hid_device *hid)
+{
+ struct hid_transport *tl;
+ int ret;
+
+ if (hid-driver-open)
+ return hid-driver-open(hid);
+ ret = 0;
+ spin_lock(hid_lock);
+ tl = hid_transports[hid-bus];
+ if (tl-open)
+ ret =
y access likely, or I failed to understand USB core ?! FIXING, The
fun also here.
The hiddump is good idea, I like, however, I think hidraw just is it.
the hiddump is one application of hidraw. is it right?
Good luck.
- Li Yu
hidbus.prototype.070404.patch.gz
Description: GNU Zip compressed data
core ?! FIXING, The
fun also here.
The hiddump is good idea, I like, however, I think hidraw just is it.
the hiddump is one application of hidraw. is it right?
Good luck.
- Li Yu
hidbus.prototype.070404.patch.gz
Description: GNU Zip compressed data
g over code is
> usualy more efficient than just ranting random ideas :)
>
> Thanks,
>
>
Of course, It's no problem. but it must be tomorrow, two reasons:
1. The development PC is at my home, I am not SOHO.
2. After change from "flip-flopping", the patch need some clean
ranting random ideas :)
Thanks,
Of course, It's no problem. but it must be tomorrow, two reasons:
1. The development PC is at my home, I am not SOHO.
2. After change from flip-flopping, the patch need some cleaning.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe
Nicolas Mailhot wrote:
>> Er, I also want to know what are drawbacks of "flip-flopping" ?
>>
>
> This will cause major havoc as soon as hot-plugging and apps listening to
> HAL events (xorg eventually) enter in play.
>
>
~_~
It really need some extra works in user space, but I do not
Marcel Holtmann wrote:
> The cleanest solution without a layer violation is that you can
> register a driver for a specific VID/PID and then report id (one or
> more). All
> reports with ids that we don't have a special driver for are handled by
> the default HID->input driver or handed over to
Dmitry Torokhov wrote:
>
> No, please don't do that. As soon as there is a special driver written
> for a device that device's VID/PID should be added to generic HID
> blacklist. This way udev will load the proper driver right away and
> there will not be any flip-flopping of input devices.
>
Dmitry Torokhov wrote:
No, please don't do that. As soon as there is a special driver written
for a device that device's VID/PID should be added to generic HID
blacklist. This way udev will load the proper driver right away and
there will not be any flip-flopping of input devices.
Hi, I
Marcel Holtmann wrote:
The cleanest solution without a layer violation is that you can
register a driver for a specific VID/PID and then report id (one or
more). All
reports with ids that we don't have a special driver for are handled by
the default HID-input driver or handed over to hidraw
Nicolas Mailhot wrote:
Er, I also want to know what are drawbacks of flip-flopping ?
This will cause major havoc as soon as hot-plugging and apps listening to
HAL events (xorg eventually) enter in play.
~_~
It really need some extra works in user space, but I do not think this
is
There have another type driver: the sticky driver, they will attach each
working device without clone or create new hid_device or input_dev. the
example is hiddev and hidraw.
Yes, this model imply there need more uevents: add, remove. Is this
model suitable? I think the essence of our discussi
is how to handle
unknown abnormal device.
I had already ported this to 2.6.21-rc5-mm2, and spent almost two days
to find out one concurrency problem. I lucky known where have bug, but
not fixed it.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Dmitry Torokhov wrote:
> On Thursday 29 March 2007 23:06, Li Yu wrote:
>
>> Dmitry Torokhov wrote:
>>
>>> On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
>>>
>>>> The crucial thing here is that all reports but the one
PS: Have we need more than one shadow driver for same fundamental
driver? I do not think so.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
thing, and fundamental device silent,
even unregister it. I think this is best choice between them, this means
have a bit of complex.
Welcome for your words.
PS: Have we need more than one shadow driver for same fundamental
driver? I do not think so.
Good luck.
- Li Yu
-
To unsubscribe from
Dmitry Torokhov wrote:
On Thursday 29 March 2007 23:06, Li Yu wrote:
Dmitry Torokhov wrote:
On 3/28/07, Jiri Kosina [EMAIL PROTECTED] wrote:
The crucial thing here is that all reports but the ones that the driver
registered to will be processed in a standard way
Jiri Kosina wrote:
> JFYI the preliminary version of the hidraw interface is now in the
> hid/usbhid git tree, and has also been in a few recent -mm kernels
> already.
>
>
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any
Jiri Kosina wrote:
JFYI the preliminary version of the hidraw interface is now in the
hid/usbhid git tree, and has also been in a few recent -mm kernels
already.
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any bluetooth
uot; is
same with "shadow driver" too.
Er, What's mean of your "HUT", HID Usage Table? if so, I think I have already
explained we can do it.However, we should supply some convenient API for this
work. or HIT is other mysterious thing? ;)
> Regards
>
>
already
explained we can do it.However, we should supply some convenient API for this
work. or HIT is other mysterious thing? ;)
Regards
Marcel
Progress: It seem the shadow basic support works! but It still need more tests.
Good luck.
- Li Yu
-
To unsubscribe from this list: send the line
.
-Li Yu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
-Li Yu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do
dev);
+ hidinput_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hidinput->input = input_dev;
+ if (!(hid->quirks_QUIRK_MULTI_INPUT))
+ hid_ff_init(hid);
+ }
+ return 0;
+}
+
+v
if (!input_dev)
+ return -ENOMEM;
+ list_for_each_entry_safe(hidinput, next, >inputs, list) {
+ hidinput_input_init(hid, input_dev);
+ hidinput_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hi
-12 13:29:28.0
+0800
@@ -0,0 +1,252 @@
+/*
+ * Microsoft Natural Ergonomic Keyboard 4000 Driver
+ *
+ * Version: 0.4.0
+ *
+ * Copyright (c) 2006 Li Yu <[EMAIL PROTECTED]>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the term
:29:28.0
+0800
@@ -0,0 +1,252 @@
+/*
+ * Microsoft Natural Ergonomic Keyboard 4000 Driver
+ *
+ * Version: 0.4.0
+ *
+ * Copyright (c) 2006 Li Yu [EMAIL PROTECTED]
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU
/drivers/hid/hid-simple.c 2007-03-05 11:17:26.0
+0800
@@ -0,0 +1,334 @@
+/*
+ * HID Simple Driver Interface v0.5.0
+ *
+ * Copyright (c) 2006 Li Yu [EMAIL PROTECTED]
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU
/drivers/hid/hid-simple.c
--- linux-2.6.21-rc2.orig/drivers/hid/hid-simple.c 1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21-rc2/drivers/hid/hid-simple.c 2007-03-05 11:17:26.0
+0800
@@ -0,0 +1,334 @@
+/*
+ * HID Simple Driver Interface v0.5.0
+ *
+ * Copyright (c) 2006 Li Yu
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do
ure the performance of this patch ? I
have no any good idea for this.
Good luck.
Signed-off-by: Li Yu <[EMAIL PROTECTED]>
diff -Naurp linux-2.6.19/include/linux/prio_ceiling.h
linux-2.6.19.ceiling/include/linux/prio_ceiling.h
--- linux-2.6.19/include/linux/prio_ceiling.h 1970-01-01 08:00:00.
the performance of this patch ? I
have no any good idea for this.
Good luck.
Signed-off-by: Li Yu [EMAIL PROTECTED]
diff -Naurp linux-2.6.19/include/linux/prio_ceiling.h
linux-2.6.19.ceiling/include/linux/prio_ceiling.h
--- linux-2.6.19/include/linux/prio_ceiling.h 1970-01-01 08:00:00.0
turn -ENOMEM;
+ list_for_each_entry_safe(hidinput, next, >inputs, list) {
+ hidinput_input_init(hid, input_dev);
+ hidinput_lock_simple(hidinput);
+ input_unregister_device(hidinput->input);
+ hidinput->input = input_dev;
+
l_init(tmp_list.next);
+ }
+ if (!input_dev)
+ return -ENOMEM;
+ list_for_each_entry_safe(hidinput, next, >inputs, list) {
+ hidinput_input_init(hid, input_dev);
+ hidinput_lock_simple(hidinput);
+ input_unregis
Simple Driver Interface v0.4.1
+ *
+ * Copyright (c) 2006 Li Yu [EMAIL PROTECTED]
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2
/input/hid-simple.c
--- linux-2.6.19.orig/drivers/usb/input/hid-simple.c1970-01-01
08:00:00.0 +0800
+++ linux-2.6.19/drivers/usb/input/hid-simple.c 2006-12-06 17:42:14.0
+0800
@@ -0,0 +1,326 @@
+/*
+ * HID Simple Driver Interface v0.4.1
+ *
+ * Copyright (c) 2006 Li Yu [EMAIL
80 matches
Mail list logo
