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

[Damien Zammit]

On 5/7/20 3:48 am, Samuel Thibault wrote:
> Hello,
> 
> Thanks for reworking this!  With a couple RPC interface changes we can
> probably commit it.

Hooray!

> I.e. remove this disable and initial unacked interrupt, and remove the
> initial intr_enable call from netdde / rump.
> 
Done in this patch. (not the netdde/rump part yet)

>> -ds_device_intr_enable(ipc_port_t master_port, int line, char status)
>> +ds_device_intr_enable (device_t dev, int id)
> 
> Please rename to ds_device_intr_ack, we don't want to keep an underlying
> intr disable/enable semantic (notably since you are dropping the status
> parameter).

ACK

> Also, as mentioned in the previous user_intr_enable() prototype, this
> RPC should be taking the delivery port rather than the irq id, so we use
> search_intr instead of search_intr_line.
ACK

> The smaller the patch is, the less time it takes to review it, and thus
> the easier it is for me to find time to review it.

I've removed the unnecessary churn in the patch.

>> +void
>> +irq_enable (irq_t irq)
>> +{
>> +  unmask_irq (irq);
>> +}
> 
> This isn't enough: we need to disable irqs while doing this!

ACK

> 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?  I think the linux interrupt handling
can remain counting interrupts separately.

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?

See attached for revised patch.

Thanks,
Damien

0001-irq-as-mach-device2.patch
Description: Text Data