Re: [RFC PATCH v2] do_exit(): panic() recursion detected

2020-12-07 Thread Vladimir Kondratiev
red as well. Let's drop this patch. Thanks, Vladimir On 12/7/20 5:49 PM, Eric W. Biederman wrote: Vladimir Kondratiev writes: Please ignore version 1 of the patch - it was sent from wrong mail address. To clarify the reason: Situation where do_exit() re-entered, discovered by static code

Re: [RFC PATCH] do_exit(): panic() recursion detected

2020-12-07 Thread Vladimir Kondratiev
We do panic on oops as well. We panic on anything that may point to system stability issues. I can't proof this code can't be reached without oops, so I want to panic here as well. On 12/7/20 2:51 PM, Peter Zijlstra wrote: On Mon, Dec 07, 2020 at 02:40:49PM +0200, Vladimir Kondratiev wrote

Re: [RFC PATCH v2] do_exit(): panic() recursion detected

2020-12-07 Thread Vladimir Kondratiev
panic on fatal signal delivery - patch for this not submitted yet. On 12/7/20 2:44 PM, Vladimir Kondratiev wrote: Recursive do_exit() is symptom of compromised kernel integrity. For safety critical systems, it may be better to panic() in this case to minimize risk. Signed-off-by: Vladimir

[RFC PATCH v2] do_exit(): panic() recursion detected

2020-12-07 Thread Vladimir Kondratiev
Recursive do_exit() is symptom of compromised kernel integrity. For safety critical systems, it may be better to panic() in this case to minimize risk. Signed-off-by: Vladimir Kondratiev Change-Id: I42f45900a08c4282c511b05e9e6061360d07db60 --- Documentation/admin-guide/kernel-parameters.txt | 6

[RFC PATCH] do_exit(): panic() recursion detected

2020-12-07 Thread Vladimir Kondratiev
From: Vladimir Kondratiev Recursive do_exit() is symptom of compromised kernel integrity. For safety critical systems, it may be better to panic() in this case to minimize risk. Signed-off-by: Vladimir Kondratiev Change-Id: I42f45900a08c4282c511b05e9e6061360d07db60 --- Documentation/admin

[PATCH] do_exit(): panic() when double fault detected

2020-12-06 Thread Vladimir Kondratiev
Double fault detected in do_exit() is symptom of integrity compromised. For safety critical systems, it may be better to panic() in this case to minimize risk. Signed-off-by: Vladimir Kondratiev --- Documentation/admin-guide/kernel-parameters.txt | 5 + include/linux/kernel.h

[PATCH] mmc: sdhci-cadence: fix PHY write

2020-05-25 Thread Vladimir Kondratiev
detested by hardware. Signed-off-by: Vladimir Kondratiev --- drivers/mmc/host/sdhci-cadence.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c index e474d3fa099e..6b2e7c43cbc1 100644 --- a/drivers/mmc

[PATCH] mips: fix cacheinfo

2019-07-16 Thread Vladimir Kondratiev
: fix x86 with CONFIG_OF enabled") Utilize same mechanism to report that cacheinfo set by architecture specific function Signed-off-by: Vladimir Kondratiev --- arch/mips/kernel/cacheinfo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/c

[PATCH v3] mips: cm: reprime error cause

2019-02-06 Thread Vladimir Kondratiev
of cm_error may be safely written back; it clears error cause and keeps other bits untouched. Fixes: 3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors") Signed-off-by: Vladimir Kondratiev --- arch/mips/kernel/mips-cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2] mips: cm: reprime error cause

2019-02-06 Thread Vladimir Kondratiev
From: Vladimir Kondratiev Accordingly to the documentation ---cut--- The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE fields can be cleared by either a reset or by writing the current value of GCR_ERROR_CAUSE.ERR_TYPE to the GCR_ERROR_CAUSE.ERR_TYPE register. ---cut--- Do

[PATCH] mips: cm: reprime error cause

2019-02-06 Thread Vladimir Kondratiev
("MIPS: CM: Add support for reporting CM cache errors") Signed-off-by: Vladimir Kondratiev --- arch/mips/kernel/mips-cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c index 8f5bd04f320a..f54ba99dc7d9 100644

RFC: striving for automotive grade certification

2019-02-04 Thread Vladimir Kondratiev
Hi, I am looking how can we get kernel certified for life critical applications, in particular for automotive industry. Mean drive train, not infotainment. To begin with, all certification processes are talking about cleaning compilation warnings at level higher then usual. Example would

Re: [PATCH] kbuild: gitignore output directory

2019-02-03 Thread Vladimir Kondratiev
Agree; sending v2 On 2/1/19 6:18 AM, Masahiro Yamada wrote: On Wed, Jan 30, 2019 at 8:15 PM Vladimir Kondratiev wrote: When compiling into output directory using O=, many files created under KBUILD_OUTPUT that git considers as new ones; git clients, ex. "git gui" lists it, and i

[PATCH v2] kbuild: gitignore output directory

2019-02-03 Thread Vladimir Kondratiev
From: Vladimir Kondratiev When compiling into output directory using O=, many files created under KBUILD_OUTPUT that git considers as new ones; git clients, ex. "git gui" lists it, and it clutters file list making it difficult to see what was really changed Generate .gitignore

[PATCH] kbuild: gitignore output directory

2019-01-30 Thread Vladimir Kondratiev
es all its content Signed-off-by: Vladimir Kondratiev --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 141653226f3c..ee66ea28869b 100644 --- a/Makefile +++ b/Makefile @@ -483,10 +483,13 @@ PHONY += outputmakefile # outputmakefile generates a Makefile in

Re: [PATCH] lib: 64bit IO

2019-01-29 Thread Vladimir Kondratiev
On 1/29/19 6:01 PM, Greg Kroah-Hartman wrote: On Tue, Jan 29, 2019 at 05:41:02PM +0200, Vladimir Kondratiev wrote: implement missing io{read|write}64 For 64-bit platforms, these 64-bit io functions are defined in include/asm-generic/iomap.h, but actual implementation missing. Provide

[PATCH] lib: 64bit IO

2019-01-29 Thread Vladimir Kondratiev
implement missing io{read|write}64 For 64-bit platforms, these 64-bit io functions are defined in include/asm-generic/iomap.h, but actual implementation missing. Provide it. Signed-off-by: Vladimir Kondratiev --- lib/iomap.c | 46 ++ 1 file changed

[PATCH] rmem: support for dma_addr different from phys_addr

2017-07-04 Thread Vladimir Kondratiev
(). This assumes the whole buffer has same offset between physical and dma addresses. Signed-off-by: Vladimir Kondratiev <vladimir.kondrat...@intel.com> --- drivers/base/dma-coherent.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/ba

[PATCH] rmem: support for dma_addr different from phys_addr

2017-07-04 Thread Vladimir Kondratiev
(). This assumes the whole buffer has same offset between physical and dma addresses. Signed-off-by: Vladimir Kondratiev --- drivers/base/dma-coherent.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 640a7e63c453

[PATCH] rmem: support for dma_addr different from phys_addr

2017-07-04 Thread Vladimir Kondratiev
(). This assumes the whole buffer has same offset between physical and dma addresses. Change-Id: Ic709312941ee4e1a37afb2ea25cbd759eabc009b Signed-off-by: Vladimir Kondratiev <vladimir.kondrat...@intel.com> --- drivers/base/dma-coherent.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH] rmem: support for dma_addr different from phys_addr

2017-07-04 Thread Vladimir Kondratiev
(). This assumes the whole buffer has same offset between physical and dma addresses. Change-Id: Ic709312941ee4e1a37afb2ea25cbd759eabc009b Signed-off-by: Vladimir Kondratiev --- drivers/base/dma-coherent.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b

Re: [PATCH] wil6210: increase cmd buffer size to avoid sscanf buffer overflow

2015-03-02 Thread Vladimir Kondratiev
ked-by: Vladimir Kondratiev Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] wil6210: increase cmd buffer size to avoid sscanf buffer overflow

2015-03-02 Thread Vladimir Kondratiev
) Thanks for finding this. Here is my Acked-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com Thanks, Vladimir -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [PATCH] ath: change logging functions to return void

2014-09-23 Thread Vladimir Kondratiev
On Monday, September 22, 2014 10:35:34 AM Joe Perches wrote: > Other miscellanea: > > o add __printf verification to wil6210 logging functions > No format/argument mismatches found > > Signed-off-by: Joe Perches > For wil6210: Acked-by: Vladimir Kondratiev -

Re: [PATCH] ath: change logging functions to return void

2014-09-23 Thread Vladimir Kondratiev
On Monday, September 22, 2014 10:35:34 AM Joe Perches wrote: Other miscellanea: o add __printf verification to wil6210 logging functions No format/argument mismatches found Signed-off-by: Joe Perches j...@perches.com For wil6210: Acked-by: Vladimir Kondratiev qca_vkond

Re: [PATCH] wil6210: Fix switch operator "missing break?" warning

2014-02-10 Thread Vladimir Kondratiev
On Friday, February 07, 2014 03:46:40 PM Alexander Gordeev wrote: > This update fixes a warning introduced with commit bc977ba1 > ("wil6210: Use pci_enable_msi_range() instead of pci_enable_msi_block()") > > drivers/net/wireless/ath/wil6210/pcie_bus.c:65 wil_if_pcie_enable() > warn: missing

Re: [PATCH] wil6210: Fix switch operator missing break? warning

2014-02-10 Thread Vladimir Kondratiev
On Friday, February 07, 2014 03:46:40 PM Alexander Gordeev wrote: This update fixes a warning introduced with commit bc977ba1 (wil6210: Use pci_enable_msi_range() instead of pci_enable_msi_block()) drivers/net/wireless/ath/wil6210/pcie_bus.c:65 wil_if_pcie_enable() warn: missing break?

Re: [PATCH 7/7] wil6210: Use new interfaces for MSI enablement

2014-01-08 Thread Vladimir Kondratiev
> pci_enable_msix_range()" > Thanks, see it. New code don't distinguish between negative and positive error values, same as old code. I'll fix it. Meanwhile, below my Acked-by: Vladimir Kondratiev -- To unsubscribe from this list: send the line "unsubscribe linux-ker

Re: [PATCH 7/7] wil6210: Use new interfaces for MSI enablement

2014-01-08 Thread Vladimir Kondratiev
On Tuesday, January 07, 2014 07:05:42 PM Alexander Gordeev wrote: > Signed-off-by: Alexander Gordeev > --- > drivers/net/wireless/ath/wil6210/pcie_bus.c | 36 ++ > 1 files changed, 19 insertions(+), 17 deletions(-) > Patch looks fine, but I can't validate it as I

Re: [PATCH 7/7] wil6210: Use new interfaces for MSI enablement

2014-01-08 Thread Vladimir Kondratiev
On Tuesday, January 07, 2014 07:05:42 PM Alexander Gordeev wrote: Signed-off-by: Alexander Gordeev agord...@redhat.com --- drivers/net/wireless/ath/wil6210/pcie_bus.c | 36 ++ 1 files changed, 19 insertions(+), 17 deletions(-) Patch looks fine, but I can't

Re: [PATCH 7/7] wil6210: Use new interfaces for MSI enablement

2014-01-08 Thread Vladimir Kondratiev
() Thanks, see it. New code don't distinguish between negative and positive error values, same as old code. I'll fix it. Meanwhile, below my Acked-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [ 044/102] ath: wil6210: Fix build error

2013-08-11 Thread Vladimir Kondratiev
On Thursday, August 08, 2013 06:57:20 PM Greg Kroah-Hartman wrote: > 3.10-stable review patch. If anyone has any objections, please let me know. This one is good for stable. I'd suggest to apply also commit c6c7788fe26fdc91e729f60742815ccdb505fd81 - wil6210: drop -Werror compiler flag it is not

Re: [ 044/102] ath: wil6210: Fix build error

2013-08-11 Thread Vladimir Kondratiev
On Thursday, August 08, 2013 06:57:20 PM Greg Kroah-Hartman wrote: 3.10-stable review patch. If anyone has any objections, please let me know. This one is good for stable. I'd suggest to apply also commit c6c7788fe26fdc91e729f60742815ccdb505fd81 - wil6210: drop -Werror compiler flag it is not

Re: [PATCH] drivers/net/wireless/ath/wil6210: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

2013-02-27 Thread Vladimir Kondratiev
On Wednesday, February 27, 2013 04:56:57 PM Chen Gang wrote: > 于 2013年02月27日 16:45, Vladimir Kondratiev 写道: > > On Wednesday, February 27, 2013 02:55:06 PM Chen Gang wrote: > >> > >> When make with EXTRA_CFLAGS=-W, it will report error. > >> so give a che

Re: [PATCH] drivers/net/wireless/ath/wil6210: Makefile, only -Werror when no -W* in EXTRA_CFLAGS

2013-02-27 Thread Vladimir Kondratiev
On Wednesday, February 27, 2013 04:56:57 PM Chen Gang wrote: 于 2013年02月27日 16:45, Vladimir Kondratiev 写道: On Wednesday, February 27, 2013 02:55:06 PM Chen Gang wrote: When make with EXTRA_CFLAGS=-W, it will report error. so give a check in Makefile. Signed-off-by: Chen Gang gang.c

Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages

2013-02-09 Thread Vladimir Kondratiev
loc/memcpy to kmemdup. > Removed now unused stack variables. > Removed unnecessary parentheses. > Neatened alignment. > > Signed-off-by: Joe Perches > For wil6210: Acked--by: Vladimir Kondratiev Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linu

Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages

2013-02-09 Thread Vladimir Kondratiev
unused stack variables. Removed unnecessary parentheses. Neatened alignment. Signed-off-by: Joe Perches j...@perches.com For wil6210: Acked--by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com Thanks, Vladimir -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Vladimir Kondratiev
sier to undo later. Comments? >From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev Date: Wed, 21 Nov 2012 13:57:21 +0200 Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel Unless patch for dynamic hexdump merged into mainstream ke

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-12 Thread Vladimir Kondratiev
. Comments? From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com Date: Wed, 21 Nov 2012 13:57:21 +0200 Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel Unless patch for dynamic hexdump merged into mainstream kernel

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-04 Thread Vladimir Kondratiev
:35:40AM -0800, Joe Perches wrote: > > On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote: > > > In case this option wins, patch follows. There is no need for > > > 2-nd one to fix existing drivers. > > > > Thanks Vladimir. > > > > >

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-12-04 Thread Vladimir Kondratiev
:40AM -0800, Joe Perches wrote: On Sun, 2012-11-18 at 19:01 +0200, Vladimir Kondratiev wrote: In case this option wins, patch follows. There is no need for 2-nd one to fix existing drivers. Thanks Vladimir. Yes, thanks. I've pulled in this patch, and posted a dynamic debug tree

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 05:43:07 PM Vladimir Kondratiev wrote: > On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote: > > Another option could be testing __builtin_constant_p(prefix) > > You mean something like below? Yes, it will work as well. > > Pro: don't ne

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote: > Another option could be testing __builtin_constant_p(prefix) You mean something like below? Yes, it will work as well. Pro: don't need to change existing code (drop [PATCH 2/2] dynamic_debug: use constant format in

[PATCH 1/2] dynamic_debug: dynamic hex dump

2012-11-18 Thread Vladimir Kondratiev
>From 26bb3835fe438622d108716420c3cc191f2e881b Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev Date: Sun, 18 Nov 2012 15:37:20 +0200 Subject: [PATCH 1/2] dynamic_debug: dynamic hex dump Introduce print_hex_dump_debug() that can be dynamically controlled, similar to pr_debug. Also, m

[PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes()

2012-11-18 Thread Vladimir Kondratiev
>From cff77ecaa9a1f875327a0530f0ebc7998427bbf4 Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev Date: Sun, 18 Nov 2012 15:47:09 +0200 Subject: [PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes() In order to convert print_hex_dump_bytes() to dynamic debug, it sho

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 11:47:58 AM Vladimir Kondratiev wrote: > On Wednesday, November 14, 2012 07:27:47 PM Vladimir Kondratiev wrote: > > +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \ > > +groupsize, buf, len, ascii)

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 11:47:58 AM Vladimir Kondratiev wrote: On Wednesday, November 14, 2012 07:27:47 PM Vladimir Kondratiev wrote: +#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \ +groupsize, buf, len, ascii)\ +do

[PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes()

2012-11-18 Thread Vladimir Kondratiev
From cff77ecaa9a1f875327a0530f0ebc7998427bbf4 Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com Date: Sun, 18 Nov 2012 15:47:09 +0200 Subject: [PATCH 2/2] dynamic_debug: use constant format in print_hex_dump_bytes() In order to convert print_hex_dump_bytes

[PATCH 1/2] dynamic_debug: dynamic hex dump

2012-11-18 Thread Vladimir Kondratiev
From 26bb3835fe438622d108716420c3cc191f2e881b Mon Sep 17 00:00:00 2001 From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com Date: Sun, 18 Nov 2012 15:37:20 +0200 Subject: [PATCH 1/2] dynamic_debug: dynamic hex dump Introduce print_hex_dump_debug() that can be dynamically controlled, similar

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote: Another option could be testing __builtin_constant_p(prefix) You mean something like below? Yes, it will work as well. Pro: don't need to change existing code (drop [PATCH 2/2] dynamic_debug: use constant format in

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-18 Thread Vladimir Kondratiev
On Sunday, November 18, 2012 05:43:07 PM Vladimir Kondratiev wrote: On Sunday, November 18, 2012 06:38:51 AM Joe Perches wrote: Another option could be testing __builtin_constant_p(prefix) You mean something like below? Yes, it will work as well. Pro: don't need to change existing code

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 09:08:52 AM Joe Perches wrote: > On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote: > > And, here it goes (can I call it PATCH?): > Don't see why not. > > > From: Vladimir Kondratiev > > [] > > > Introduce debu

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 05:41:08 AM Joe Perches wrote: > On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote: > > Introduce debug_hex_dump() that can be dynamically controlled, similar to > > pr_debug. > > (added Jason Baron, Jim Cromie, Gr

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 05:41:08 AM Joe Perches wrote: On Wed, 2012-11-14 at 14:17 +0200, Vladimir Kondratiev wrote: Introduce debug_hex_dump() that can be dynamically controlled, similar to pr_debug. (added Jason Baron, Jim Cromie, GregKH and lkml to cc's) [] diff --git

Re: [RFC] dynamic_debug: introduce debug_hex_dump()

2012-11-14 Thread Vladimir Kondratiev
On Wednesday, November 14, 2012 09:08:52 AM Joe Perches wrote: On Wed, 2012-11-14 at 18:18 +0200, Vladimir Kondratiev wrote: And, here it goes (can I call it PATCH?): Don't see why not. From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com [] Introduce debug_hex_dump() that can

Re: wireless 2.6 work

2005-03-23 Thread Vladimir Kondratiev
I did posted once; it was long time ago. I am sure I sent it to Dave. I can resend if needed. Basically, I made Dave's stack work on 2.6 kernels; did some changes toward QoS and provided simple utility to imitate low level driver. I was concentrated on interfaces, it is still just skeleton. I

Re: wireless 2.6 work

2005-03-23 Thread Vladimir Kondratiev
I did posted once; it was long time ago. I am sure I sent it to Dave. I can resend if needed. Basically, I made Dave's stack work on 2.6 kernels; did some changes toward QoS and provided simple utility to imitate low level driver. I was concentrated on interfaces, it is still just skeleton. I