* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
>
> > I understand one still has to write a kernel driver to shut up the irq.
> > How about writing a small bytecode interpreter to make event than
> > unnecessary?
>
> if you do that why not do a real driver.
Because perhaps it is potentially
* Arjan van de Ven ([EMAIL PROTECTED]) wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
Because perhaps it is potentially very simple
linux-os (Dick Johnson) wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
If anyone has any questions on how to use this interface, or anything
else about it, please let me and Thomas know.
thanks,
greg k-h
[snip]
There are well thought-out methods of creating hardware interfaces that
> have a
On Thu, Dec 14, 2006 at 12:48:55PM +0200, Avi Kivity wrote:
> [why trim the cc?]
>
> Hans-J?rgen Koch wrote:
> >Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
> >
> >
> >>I understand one still has to write a kernel driver to shut up the irq.
> >>How about writing a small bytecode
On Dec 14 2006 15:38, Avi Kivity wrote:
> Jan Engelhardt wrote:
>> > It has to be written once, but compiled for every kernel
>> > version and $arch out there (for out of tree drivers), or it
>> > has to wait for the next kernel release and distro sync (for
>> > in-tree drivers).
>>
>> Still
On Thu, Dec 14, 2006 at 12:56:29PM +0200, Avi Kivity wrote:
> Arjan van de Ven wrote:
> >On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
> >
> >>Arjan van de Ven wrote:
> >>
> I understand one still has to write a kernel driver to shut up the irq.
> How about writing a small
On Wed, 13 Dec 2006, Greg KH wrote:
> A large number of people have expressed interest recently in the
> userspace i/o driver core which allows userspace drivers to be written
> to handle some types of hardware.
>
> Right now the UIO core is working and in the -mm relea
Jan Engelhardt wrote:
It has to be written once, but compiled for every kernel
version and $arch out there (for out of tree drivers), or it
has to wait for the next kernel release and distro sync (for
in-tree drivers).
Still better than written for every _and_ compiled for every.
But
> It has to be written once, but compiled for every kernel
> version and $arch out there (for out of tree drivers), or it
> has to wait for the next kernel release and distro sync (for
> in-tree drivers).
Still better than written for every _and_ compiled for every.
But wait, make it simpler:
>The patches can be found in the -mm releases or at:
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio.patch
>- UIO core
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch
>- UIO
On Thu, 14 Dec 2006 12:37:16 +0100
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> There are three breaks in that while loop, the first makes it return as
> soon as an interrupt occurs.
Doh ignore that I misread it. Perils of reading email before midday
-
To unsubscribe from this list: send the
Am Donnerstag, 14. Dezember 2006 12:39 schrieb Alan:
> On Thu, 14 Dec 2006 12:22:16 +0100
> Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2006-12-14 at 10:52 +, Alan wrote:
> > > Might be kind of hairy given uio_read() doesn't even return from the
> > > kernel.
> >
> > We
On Thu, 14 Dec 2006 12:22:16 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-12-14 at 10:52 +, Alan wrote:
> > Might be kind of hairy given uio_read() doesn't even return from the
> > kernel.
>
> We probably talk about different code here, right ? The one, I'm looking
> at
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
> Might be kind of hairy given uio_read() doesn't even return from the
> kernel.
We probably talk about different code here, right ? The one, I'm looking
at returns on each interrupt event.
tglx
-
To unsubscribe from this list: send the
Arjan van de Ven wrote:
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
> Arjan van de Ven wrote:
> >> I understand one still has to write a kernel driver to shut up the irq.
> >> How about writing a small bytecode interpreter to make event than
> >> unnecessary?
> >>
> >
> > if you do that why not do a real
[why trim the cc?]
Hans-Jürgen Koch wrote:
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
The userspace driver would
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
An entire driver in bytecode? that means exposing the entire
> But in order to get this core into the kernel tree, we need to have some
> "real" drivers written that use it. So, for anyone that wants to see
> this go into the tree, now is the time to step forward and post your
> patches for hardware that this kind of driver interface is needed.
Might be
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
>
> I understand one still has to write a kernel driver to shut up the irq.
> How about writing a small bytecode interpreter to make event than
> unnecessary?
>
> The userspace driver would register a couple of bytecode programs:
>
> I understand one still has to write a kernel driver to shut up the irq.
> How about writing a small bytecode interpreter to make event than
> unnecessary?
if you do that why not do a real driver.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Greg KH wrote:
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from the last time patches
Greg KH wrote:
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from the last time patches
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
The userspace driver would register a couple of bytecode programs:
But in order to get this core into the kernel tree, we need to have some
real drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
Might be kind of
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
An entire driver in bytecode? that means exposing the entire
[why trim the cc?]
Hans-Jürgen Koch wrote:
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
The userspace driver would
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
Arjan van de Ven wrote:
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about different code here, right ? The one, I'm looking
at returns on each interrupt event.
tglx
-
To unsubscribe from this list: send the
On Thu, 14 Dec 2006 12:22:16 +0100
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about different code here, right ? The one, I'm looking
at returns on
Am Donnerstag, 14. Dezember 2006 12:39 schrieb Alan:
On Thu, 14 Dec 2006 12:22:16 +0100
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about
On Thu, 14 Dec 2006 12:37:16 +0100
Hans-Jürgen Koch [EMAIL PROTECTED] wrote:
There are three breaks in that while loop, the first makes it return as
soon as an interrupt occurs.
Doh ignore that I misread it. Perils of reading email before midday
-
To unsubscribe from this list: send the line
It has to be written once, but compiled for every kernel
version and $arch out there (for out of tree drivers), or it
has to wait for the next kernel release and distro sync (for
in-tree drivers).
Still better than written for every _and_ compiled for every.
But wait, make it simpler: just
The patches can be found in the -mm releases or at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio.patch
- UIO core
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch
- UIO documentation
Jan Engelhardt wrote:
It has to be written once, but compiled for every kernel
version and $arch out there (for out of tree drivers), or it
has to wait for the next kernel release and distro sync (for
in-tree drivers).
Still better than written for every _and_ compiled for every.
But
On Wed, 13 Dec 2006, Greg KH wrote:
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from
On Thu, Dec 14, 2006 at 12:56:29PM +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to
On Dec 14 2006 15:38, Avi Kivity wrote:
Jan Engelhardt wrote:
It has to be written once, but compiled for every kernel
version and $arch out there (for out of tree drivers), or it
has to wait for the next kernel release and distro sync (for
in-tree drivers).
Still better than written
On Thu, Dec 14, 2006 at 12:48:55PM +0200, Avi Kivity wrote:
[why trim the cc?]
Hans-J?rgen Koch wrote:
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to
linux-os (Dick Johnson) wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
If anyone has any questions on how to use this interface, or anything
else about it, please let me and Thomas know.
thanks,
greg k-h
[snip]
There are well thought-out methods of creating hardware interfaces that
have a
Greg KH wrote:
But in order to get this core into the kernel tree, we need to have some
"real" drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from the last time patches were posted to lkml
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from the last time patches were posted to lkml
Greg KH wrote:
But in order to get this core into the kernel tree, we need to have some
real drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
46 matches
Mail list logo
