Jiaxin,
> > > In my memory, we only talked about the performance issue before.
> > > Here, I understand your requirement: 1) The network interface should
> > > be in
> > > *un-
> > > configured* status at each boot time until the third part
> > > configuration;
Yes, we would like a policy setting (either runtime/protocol or build-time/PCD
is fine) for this.
2) the policy setting should be ignored, right? I
> > > don't
I don't know what you mean by this. The static/dhcp policy shouldn't
necessarily be ignored but if the interface is not yet configured (i.e. the IP
layer won't respond to packets) then the static/dhcp policy doesn't really
matter until some component calls Configure() for the first time.
> This is what I want to confirm with you that my understanding is right? You
> complained the network interface comes "up" at each boot, what does
> "comes up" exactly mean? So, I gave the above two guesses 1) and 2).
And I tried to clarify what I meant. Another way of saying it is by being "up"
it means performing DHCP (if that is the setting) and transmitting/receiving
packets using the IP address. What we are asking for is a policy where we can
suppress this behavior until the first Configure() call like before.
> Of course not. I mean if my guessing 2) is correct, it's not reasonable
> because
> UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in one of
> them. I just recalled the old Ip4Config behavior: no policy assigned default
> (if
> I remember correctly). So, don't misunderstand my truly means. It's
> unrelated to the *behavior consistency*.
Perhaps not spec consistency but we need this for implementation consistency
since we've built up years of expectations from the previous implementation.
> First, *based on the current UEFI Spec (only static / dhcp policy)*, I want to
> highlight my understanding of *un-configured* status you mentioned: policy
> should be always set, *un-configured* means *no IP address configuration*.
Correct, in that the device will neither transmit or respond at an IP layer
initially.
> If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> can be used with Ip4Config2 protocol. Detailed see below pseudocode:
>
> First, register a notify for Ip4Config2 protocol in your Dxe Driver
> EntryPoint:
> EfiCreateProtocolNotifyEvent (
> &gEfiIp4Config2ProtocolGuid,
> TPL_CALLBACK,
> Ip4Config2InstalledCallback,
> NULL,
> &Registration
> );
>
> Then, In your Ip4Config2InstalledCallback() function, you can change the
> default policy for the current boot:
> Ip4Config2InstalledCallback () {
> gBS->LocateProtocol (
> &gEfiIp4Config2ProtocolGuid,
> Registration,
> (VOID **) &Ip4Config2Instance
> );
>
> //
> // Change the policy to Ip4Config2PolicyDhcp to clean the static
> setting.
> //
> Policy = Ip4Config2PolicyDhcp;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
>
> Ip4Config2DataTypePolicy,
> sizeof
> (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
>
> //
> // Change the policy to Ip4Config2PolicyStatic to clean the DHCP
> policy
> setting.
> //
> Policy = Ip4Config2PolicyStatic;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
>
> Ip4Config2DataTypePolicy,
> sizeof
> (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
> }
>
> After that, your previous setting will be cleaned, and reach a *un-
> configured* state. I know the addition Dxe Driver is an indirect way to meet
> your requirement, but based on current UEFI Spec, it's one-time event if you
> added in your platform ahead.
There's two issues I see with this approach:
1. It destroys any previous configuration data that the user may have made
(static IP entry or explicit selection of DHCP)
2. It's a hack where we're using one policy interface to try to accomplish
something unrelated (auto vs on-demand config) based on attributes of the
current implementation and not the spec
So I'd like to propose again that we define another, separate, policy value for
automatic versus on-demand IP configuration. It can be either through a PCD or
a protocol interface. My preference in the short term is to do the PCD thing
since we can do it now where the protocol approach will require spec
modification.
Let me know if that makes sense - I'm prepared to provide a patch for the PCD
option if/when you're ready.
Eugene
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
