Re: gnumach: [PATCH] - irq as a mach device

[Samuel Thibault]

Damien Zammit, le dim. 05 juil. 2020 11:50:12 +1000, a ecrit:
> On 5/7/20 3:48 am, Samuel Thibault wrote:
> > Also, I don't think this will play nice with Linux drivers' own
> > disabling counting management to properly share IRQs between
> > Linux drivers and userland drivers. Why not just moving the
> > __dis/enable_irq() functions from the Linux parT?
> 
> I don't want to mix linux/ code with pure mach code.  The linux/
> code will eventually be removed right?

Yes, but part of that code was not from Linux, but is glue code, I
believe this piece is part of it.
We can always move code from linux/ anyway, as long as it doesn't pose
long-term copyright issues.

> I think the linux interrupt handling can remain counting interrupts
> separately.

But we may need something like this long-term wise. It's just pure luck
that pure mach drivers (keyboard, mouse, clock) are not sharing IRQs
with user-land drivers.

> One thing that is missing from this patch is the "vm_allocate_contiguous" RPC.
> It is required for DMA.  How should I proceed with it?  Do I make it an RPC 
> on the
> "mem" device only?

No, it's completely fine to make it work just like vm_allocate(), I
don't see a reason to deviate from it for now.  I see in the comment
that it recommends for upstream inclusion to make it a memory object,
but in our current uses we don't need that, if we need something
advanced like that someday we can introduce it.

What we however lack in the current RPC interface is the
min/max/alignment of physical address constraints parameters, to make
us possibly use VM_PAGE_SEG_DMA32 or even VM_PAGE_SEG_DMA instead of
VM_PAGE_SEG_DIRECTMAP, and use the proper power-of-two to respect
alignment and release unused pages accordingly.

Samuel