Garrett D'Amore wrote:
> Thanks for the clarification.
ditto.
Kais
>
> (I wasn't aware that RCM was being used this way. I recall that once
> upon a time there was a separate "sysevent" architecture where
> insertion events were handled without RCM interposing. The point, at
> the time,
Thanks for the clarification.
(I wasn't aware that RCM was being used this way. I recall that once
upon a time there was a separate "sysevent" architecture where insertion
events were handled without RCM interposing. The point, at the time, of
having a separate RCM from sysevent was that RCM
RCM is also used to restore all the configuration when the device is
plugged back in and that is when this sysevent will be used.
- Cathy
> RCM is "normally" (historically, anyway) used for device *removal*,
> rather than addition.
>
> What do you intend the RCM module to do with this event?
>
RCM is "normally" (historically, anyway) used for device *removal*,
rather than addition.
What do you intend the RCM module to do with this event?
-- Garrett
Cathy Zhou wrote:
> This event will be consumed by a syseventd module which in turn will
> generate a RCM event which will then be c
This event will be consumed by a syseventd module which in turn will
generate a RCM event which will then be consumed by the RCM modules.
But the usage of the EC_DATALINK class would not be limited to this.
- Cathy
> completeness question: who's the intended consumer for this event?
>
>Kai
completeness question: who's the intended consumer for this event?
Kais
Sebastien Roy wrote:
> I'm submitting this case for Cathy Zhou. It is being filed as closed
> approved automatic.
>
> ???Datalink sysevents
> --
>
> release binding: patch
>
> Summary
> ---
>
> Th
I'm submitting this case for Cathy Zhou. It is being filed as closed
approved automatic.
???Datalink sysevents
--
release binding: patch
Summary
---
This case proposes to introduce a new EC_DATALINK sysevent class to
report data-link related sysevents. For now, onl
