Hi,
On Tue, Nov 15, 2011 at 12:02:58AM +0100, Samuel Thibault wrote:
Considering the target of user-level drivers, I've come to a few
biting points:
- we should have a PCI arbitrer in the end. - that arbitrer should
permit to confine drivers to resources of only one PCI device, no more
Hello,
Considering the target of user-level drivers, I've come to a few biting
points:
- we should have a PCI arbitrer in the end.
- that arbitrer should permit to confine drivers to resources of only
one PCI device, no more (though of course with DMA, without IO-MMU,
you could access
Hi,
On Tue, Aug 23, 2011 at 03:22:06AM +0200, Samuel Thibault wrote:
What about using the I/O port scheme? That is, decide_intr_notify
doesn't enable IRQ notifications, but instead just returns a
handle (compare i386_io_perm_create) that is then passed to
device_irq_enable to
olafbuddenha...@gmx.net, le Tue 24 May 2011 12:09:08 +0200, a écrit :
What about using the I/O port scheme? That is, decide_intr_notify
doesn't enable IRQ notifications, but instead just returns a handle
(compare i386_io_perm_create) that is then passed to device_irq_enable
to
Hi,
On Mon, May 09, 2011 at 12:07:16AM +0200, Samuel Thibault wrote:
I've started having a look at Zheng Da's user-level driver integration.
I've cleaned his tree a bit, and now considering adding patches to
the debian packages for wider testing.
Great :-)
The ArchHurd folks have been on it
Hi,
On Mon, May 09, 2011 at 11:15:15AM +0200, Thomas Schwinge wrote:
On Mon, 9 May 2011 00:07:16 +0200, Samuel Thibault samuel.thiba...@gnu.org
wrote:
/* Requesting IRQ events on a port */
routine device_intr_notify(
master_port : mach_port_t;
in irq
On Tue, May 10, 2011 at 03:29:11AM +0200, Samuel Thibault wrote:
There are archs which have varying page size. I'd rather avoid
introducing the page size, can't mig cope with 64bit values on 32bit
archs?
Right. Even mmap2() forces multiples of 4096 and not the page size. So
using 64 bits
On Tue, May 10, 2011 at 03:26:26AM +0200, Samuel Thibault wrote:
What do you mean by phase?
Offset from the alignment. But I don't think it's useful at all in this
case. Minimum and maximum addresses and alignment should do. Maybe
boundary crossing but usually, specifying the right alignment and
On Mon, May 09, 2011 at 12:07:16AM +0200, Samuel Thibault wrote:
I've started having a look at Zheng Da's user-level driver integration.
I've cleaned his tree a bit, and now considering adding patches to
the debian packages for wider testing. The patches however add a few
kernel RPCs, which
Hallo!
On Mon, 9 May 2011 00:07:16 +0200, Samuel Thibault samuel.thiba...@gnu.org
wrote:
I've started having a look at Zheng Da's user-level driver integration.
I've cleaned his tree a bit, and now considering adding patches to
the debian packages for wider testing.
Great!
I'm not the most
Thomas Schwinge, le Mon 09 May 2011 11:15:15 +0200, a écrit :
The patches however add a few
kernel RPCs, which we should probably agree on first, at the minimum
that their existence makes sense, so we can reserve slots in upstream
gnumach. Basically, it's about allocating
On Mon, May 09, 2011 at 12:17:51PM +0200, Samuel Thibault wrote:
Hmm, I guess we don't have anything that is better than using
vm_address_t for physical addresses? At least not in
include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we?
(phys_address_t based on natural_t?)
Hallo!
On Mon, 9 May 2011 12:17:51 +0200, Samuel Thibault samuel.thiba...@gnu.org
wrote:
Thomas Schwinge, le Mon 09 May 2011 11:15:15 +0200, a écrit :
The patches however add a few
kernel RPCs, which we should probably agree on first, at the minimum
that their existence makes sense, so
Hallo!
On Mon, 9 May 2011 13:19:22 +0200, Richard Braun rbr...@sceen.net wrote:
On Mon, May 09, 2011 at 12:17:51PM +0200, Samuel Thibault wrote:
Hmm, I guess we don't have anything that is better than using
vm_address_t for physical addresses? At least not in
include/mach/std_types.h,
On Mon, May 09, 2011 at 01:27:32PM +0200, Thomas Schwinge wrote:
I'd suggest using natural_t (or unsigned long) too. But then, it can't
be used to address 4 GiB physical memory. Consider expressing physical
memory in page frame numbers.
Good idea! But: what about differently sized frames
Richard Braun, le Mon 09 May 2011 10:55:36 +0200, a écrit :
This RPC lacks a few additional constraints like boundaries, alignment
and maybe phase.
What do you mean by phase?
Samuel
Richard Braun, le Mon 09 May 2011 13:33:37 +0200, a écrit :
On Mon, May 09, 2011 at 01:27:32PM +0200, Thomas Schwinge wrote:
I'd suggest using natural_t (or unsigned long) too. But then, it can't
be used to address 4 GiB physical memory. Consider expressing physical
memory in page frame
Hello,
I've started having a look at Zheng Da's user-level driver integration.
I've cleaned his tree a bit, and now considering adding patches to
the debian packages for wider testing. The patches however add a few
kernel RPCs, which we should probably agree on first, at the minimum
that their
18 matches
Mail list logo
