All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: VMI Interface Proposal Documentation for I386, Part 5
Date: Tue, 14 Mar 2006 08:45:01 -0800	[thread overview]
Message-ID: <4416F30D.3040403@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603140040230.11606@montezuma.fsmlabs.com>

Zwane Mwaikambo wrote:
> Hello Zach,
>
> On Tue, 14 Mar 2006, Zachary Amsden wrote:
>
>   
>> It could be possible to change the semantics of the interrupt masking
>> interface in Linux, such that enable_interrupts() did just that - but did not
>> yet deliver pending IRQs.  As did restore_interrupt_mask().  This would
>> require inspection of many drivers to ensure that they don't rely on those
>> actions causing immediate interrupt delivery.  And if they did, they would
>> require a call, say, deliver_pending_irqs() to accomplish that.
>>     
>
> I think we can break these down into low level and higher level interrupt 
> enabling. Lower level tends to be call sites like exception entry, in that 
> particular case drivers aren't aware of the interrupt enable/disable 
> semantics so it's safe to enable without dispatch. Higher up is where 
> dispatch makes sense and we can closer mimick hardware.
>   

Yes, there may clearly be a benefit to having a low level / high level 
separation - say STI / PUSHF / POPF, and EnableInterrupts, 
SaveInterruptFlag, RestoreInterruptFlag.  I didn't want to do that yet, 
since it adds bulk to the interface, but there clearly is some value 
there.  And as you point out, it does save a driver audit.

Zach

  reply	other threads:[~2006-03-14 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13 19:56 VMI Interface Proposal Documentation for I386, Part 5 Zachary Amsden
2006-03-14  7:59 ` Zwane Mwaikambo
2006-03-14  8:25   ` Zachary Amsden
2006-03-14  8:47     ` Zwane Mwaikambo
2006-03-14 16:45       ` Zachary Amsden [this message]
2006-03-14 17:01       ` Zachary Amsden
2006-03-15 23:41     ` Pavel Machek
2006-03-16  1:33       ` Zachary Amsden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4416F30D.3040403@vmware.com \
    --to=zach@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.