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 onl
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 a
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_enabl
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 enab
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
> wrote:
> > /* Requesting IRQ events on a port */
> >
> > routine device_intr_notify(
> >master_port : mach_port_t;
> >in irq
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
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 a
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 se
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 p
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
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 size
Hallo!
On Mon, 9 May 2011 13:19:22 +0200, Richard Braun 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, i386/in
Hallo!
On Mon, 9 May 2011 12:17:51 +0200, Samuel Thibault
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 we can reserv
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 natu
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 physicall
Hallo!
On Mon, 9 May 2011 00:07:16 +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!
I'm not the most knowledgeable person
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, whic
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 ex
18 matches
Mail list logo
