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 physically-contiguous memory > > for DMAs, and getting IRQ events: > > Of course, it doesn't matter at the moment, but are these for x86 only, > or architecture independent?
Well, it does matter since that changes the allocation which we'd do. I believe that as it is proposed, it is architecture-agnostic: allocating a physically-contiguous area of memory for things like DMAs, and being notified of hardware requests. The vocabulary of the calls should be made arch-neutral of course. > 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?) Maybe we should, indeed, else we can't do PAE. > At this time, would it make sense to make paddr inout (and/or vaddr, > too?) and add an additional ``anywhere : boolean_t'' parameter as > vm_allocate has? Or can't there be any need for such functionality? I was wondering too. I don't think it makes sense for paddr: either you do care, and then should simply use /dev/mem and whatever we implement behind (currently it's the mem driver), or you don't care. For vaddr, I was wondering. With Zheng Da's current implementation it's not trivial to add !anywhere support, but it could make sense indeed. > > The actual event: > > > > simpleroutine mach_notify_irq( > > notify : notify_port_t; > > name : int); > > I don't understand this ``name : int''. Isn't this rather a pointer to a > struct mach_irq_notification_t? It's actually the interrupt line number. > 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 > enable/disable IRQ notifications (compare i386_io_perm_modify). Does > that make sense in this IRQ scenario? It probably looks better, yes. Samuel
