Hi,
According to the discussion in today's meeting. We are splitting this 
ARC case into two cases.
The new proposal for this case is attached.

If no objections within 24 hours, I'd like to close the case then.

We'll file another ARC case for the ACPI support with the contract 
signed, when the APIs are available.

Thanks

--Irene
Henry Zhao wrote:
> Alan Coopersmith wrote:
>>
>>> libsysevent                    committed
>>>     
>>
>> Isn't saying you import libsysevent like saying you use ioctl (i.e.
>> the interface is a gateway to all sorts of functionality at all sorts
>> of different stability levels)?  Without knowing what events, it's
>> hard to say if it's a safe usage or not.
>>
>> For this case, wouldn't you be importing events from the ACPI system,
>> which is Project Private (PSARC 2005/085)?   Will you need a contract
>> from the ACPI team promising not to change them incompatibly without
>> warning you first?
>>   
>
> Actually there are two interfaces here:
>
> (1) libsysevent    There functions are used:
>
>     sysevent_bind_handle()
>     sysevent_subscribe_event()
>     sysevent_unsubscribe_event()
>     sysevent_unbind_handle()
>
> (2) The ACPI events
>
>     In testing model we use event class  EC_ACPIEV
>     (PSARC/2006/601) and subclasses  ESC_ACPIEV_VIDEO_SWITCH,
>     ESC_ACPIEV_VIDEO_PROBE.   However  all of these classes are
>     subject to change.  The ACPI  team will do a separate ARC case when
>     the project is finalized.  We can do a contract, as a consumer, with
>     ACPI team at that time - and this is the second phase of the project.
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: disp_switch.phase.1
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080820/1d59e55d/attachment.ksh>

Reply via email to