-by: Benedikt Spranger <b.spran...@linutronix.de>
---
CREDITS | 5 +
MAINTAINERS | 4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/CREDITS b/CREDITS
index 2a3fbcd..93eef50 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1944,6 +1944,11 @@ E: kra...@bytesex.org
E: kra...@suse
-by: Benedikt Spranger
---
CREDITS | 5 +
MAINTAINERS | 4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/CREDITS b/CREDITS
index 2a3fbcd..93eef50 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1944,6 +1944,11 @@ E: kra...@bytesex.org
E: kra...@suse.de
D: video4linux, bttv
Am Wed, 12 Dec 2012 09:50:54 +0100
schrieb "Hans J. Koch" :
> On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote:
> > Yes, but what does that have to do with this in-kernel, internal api?
>
> Ah, OK. You're right, the commit message is confusing.
>
> Bene, it's enough to say we drop the
Am Wed, 12 Dec 2012 09:50:54 +0100
schrieb Hans J. Koch h...@hansjkoch.de:
On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote:
Yes, but what does that have to do with this in-kernel, internal api?
Ah, OK. You're right, the commit message is confusing.
Bene, it's enough to say we
On Tue, 11 Dec 2012 15:18:16 -0800
Greg KH wrote:
> > -open(), you will probably also want a custom
> > +release(), you will probably also want a
> > custom release() function.
> That sentance no longer makes sense.
DUH! will fix...
> > +CAVE: The release hook may be processed, even if a
> >
The inode parameter is unused by in kernel users of UIO. Also the inode
parameter makes it hard to resolve the existing open(), mmap() and close()
difficulty.
Signed-off-by: Benedikt Spranger
---
Documentation/DocBook/uio-howto.tmpl |4 ++--
drivers/uio/uio.c|4
. This would help to process
the release hook in an unmap context.
Benedikt Spranger (2):
uio: add warning to documentation
uio: do not expose inode to uio open/release hooks
Documentation/DocBook/uio-howto.tmpl | 11 ---
drivers/uio/uio.c|4 ++--
include/linux
The documentation has no clear statement to the POSIX 1003.1 mmap()
feature, wich allows open(), mmap(), close() while the mmaped pointer is valid.
The release() hook inveigled driver programmer to activate owermanagement
functuonality in the release hook. This may harm.
Signed-off-by: Benedikt
. This would help to process
the release hook in an unmap context.
Benedikt Spranger (2):
uio: add warning to documentation
uio: do not expose inode to uio open/release hooks
Documentation/DocBook/uio-howto.tmpl | 11 ---
drivers/uio/uio.c|4 ++--
include/linux
The documentation has no clear statement to the POSIX 1003.1 mmap()
feature, wich allows open(), mmap(), close() while the mmaped pointer is valid.
The release() hook inveigled driver programmer to activate owermanagement
functuonality in the release hook. This may harm.
Signed-off-by: Benedikt
The inode parameter is unused by in kernel users of UIO. Also the inode
parameter makes it hard to resolve the existing open(), mmap() and close()
difficulty.
Signed-off-by: Benedikt Spranger b.spran...@linutronix.de
---
Documentation/DocBook/uio-howto.tmpl |4 ++--
drivers/uio/uio.c
On Tue, 11 Dec 2012 15:18:16 -0800
Greg KH gre...@linuxfoundation.org wrote:
-functionopen()/function, you will probably also want a custom
+functionrelease()/function, you will probably also want a
custom functionrelease()/function function.
That sentance no longer makes sense.
DUH! will
After open(), mmap(), close() the mmaped pointer is valid. Removing the
underlaying module causes a Oops or other strange effects. Keep all structures
valid till the last user is gone.
Signed-off-by: Benedikt Spranger
---
drivers/uio/uio.c | 59
this.
Benedikt Spranger (2):
uio: be aware of open(), mmap(), close()
uio: avoid module unloding of in module created UIO devices
drivers/uio/uio.c | 67 -
drivers/uio/uio_pdrv_genirq.c |4 +--
include/linux/uio_driver.h|5 +--
3 files
A kernel module can create a uio device. Get a reference to the module, if the
UIO device is in use. Otherwise the device can be removed and a uio write or an
access to am mmaped memory can cause a kernel Oops or other strange effects.
Signed-off-by: Benedikt Spranger
---
drivers/uio/uio.c
A kernel module can create a uio device. Get a reference to the module, if the
UIO device is in use. Otherwise the device can be removed and a uio write or an
access to am mmaped memory can cause a kernel Oops or other strange effects.
Signed-off-by: Benedikt Spranger b.spran...@linutronix.de
this.
Benedikt Spranger (2):
uio: be aware of open(), mmap(), close()
uio: avoid module unloding of in module created UIO devices
drivers/uio/uio.c | 67 -
drivers/uio/uio_pdrv_genirq.c |4 +--
include/linux/uio_driver.h|5 +--
3 files
After open(), mmap(), close() the mmaped pointer is valid. Removing the
underlaying module causes a Oops or other strange effects. Keep all structures
valid till the last user is gone.
Signed-off-by: Benedikt Spranger b.spran...@linutronix.de
---
drivers/uio/uio.c | 59
On Fri, 09 Feb 2007 16:25:11 +0100
John <[EMAIL PROTECTED]> wrote:
> By the way, I have a question: when I compile glibc for this system,
> should I compile it against the vanilla 2.6.20 includes, or against
> the patched 2.6.20-rt includes?
That shouldn't make a difference. All of the
On Fri, 09 Feb 2007 16:25:11 +0100
John [EMAIL PROTECTED] wrote:
By the way, I have a question: when I compile glibc for this system,
should I compile it against the vanilla 2.6.20 includes, or against
the patched 2.6.20-rt includes?
That shouldn't make a difference. All of the
> And you certainly shouldn't be using gettid () syscall in NPTL, as it
> is just an implementation detail that there is a 1:1 mapping between
> NPTL threads and kernel threads. It can change at any time.
Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel
And you certainly shouldn't be using gettid () syscall in NPTL, as it
is just an implementation detail that there is a 1:1 mapping between
NPTL threads and kernel threads. It can change at any time.
Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel
Hi,
> Can anyone suggest me how to get the threadId using 2.6.x kernels.
> pthread_self() does not work and returns some -ve integer.
Let me guess: You are looking for get_tid() :-)
Bene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi,
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
Let me guess: You are looking for get_tid() :-)
Bene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
> Anyone could told me, why everyone, who wrote CANbus driver (peak,
> kvaser etc) always use char dev, but not netdev for it? May be exist
> some global pitfall, which I couldn't see, which prevent to use netdev?
Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff
Bene
-
Anyone could told me, why everyone, who wrote CANbus driver (peak,
kvaser etc) always use char dev, but not netdev for it? May be exist
some global pitfall, which I couldn't see, which prevent to use netdev?
Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff
Bene
-
To
Ben Dooks wrote:
> On Thu, Mar 10, 2005 at 05:45:22PM -0500, Rik van Riel wrote:
> > No, it wouldn't. I can use a source code driver on x86,
> > x86-64 and PPC64 systems, but a binary driver is only
> > usable on the architecture it was compiled for.
>
> Add to that the flavours of ARM and the
Ben Dooks wrote:
On Thu, Mar 10, 2005 at 05:45:22PM -0500, Rik van Riel wrote:
No, it wouldn't. I can use a source code driver on x86,
x86-64 and PPC64 systems, but a binary driver is only
usable on the architecture it was compiled for.
Add to that the flavours of ARM and the number of
28 matches
Mail list logo
