> Jiaxin,
>
> > > The issue is not just a performance issue around DHCP timing. Even
> > > with a static IP address set the fact that the network interface
> > > comes "up" at each boot is problematic because our requirement is
> > > only to enable the network interface when directed to by an application.
> >
> > 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; 2) the policy setting should be ignored, right? I don't
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).
> > think it's reasonable. I know the old Ip4Config did as you said here,
> > but currently, the IPv4 default policy concept is new enrolled by
> > Ip4Config2 protocol, the device policy should be in one state no matter
> static or DHCP.
>
> Sorry I'm having trouble understanding what you meant - can you rephrase
> or expand this? Are you saying that it is not reasonable to want behavior
> consistent with the original Ip4Config behavior? This seems like something
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*.
> that should be doable - in my experiment suppressing the configuration in
> Ip4Config2OnDhcp4SbInstalled does exactly this so it seems like some
> additional policy (automatic versus on-demand) could be defined to handle
> this.
>
> > >
> > > Modifying the IP configuration dynamically to suppress the interface
> > > coming up at every boot is also problematic because it means we
> > > would need to store the IP address configuration in another NVRAM
> location.
> > > In other words, the combining of the IP address settings storage
> > > *and* the policy of whether to configure at boot or wait until
> > > explicitly requested is problematic - we really would like to
> > > control these settings independently. Is that possible within the
> > > scope of the spec? Could we just have a PCD that suppresses the
> > > automatic configure at
> > boot under any circumstance?
> >
> > Actually, if you want to recover the Ipv4 setting to the
> > *un-configured* status (Note here: policy should be always set,
> > *un-configured* means no IP address configuration), Ip4Config2 provide
> > the ability to change the default policy. As git commit version SHA-1:
> > 7648748e99eeeadec38fda7568adb260c4acc861 described, "This update let
> > the other platform drivers have chance to change the default config
> > data by consume Ip4Config2Protocol. " So, you don't need to set
> > another NVRAM location to do that, that means additional DXE_DRIVER
> > can add in your platform ahead to change the default config data. The
> > only operation in this DXE_DRIVER is to register a notify for
> > Ip4Config2 protocol to change the default policy. That's also the
> > reason why we don't want to enroll PCD to change it, you know two
> interface to do the same thing is not a good idea.
>
> Let's say I have configured a static IP of 192.168.0.1. But since I don't
> want
> the network interface to automatically configure at boot I think you are
> saying that I should implement a platform policy driver that uses Ip4Config2
> to set an *unconfigured* state. But there is no definition for an
> "unconfigured" state in UEFI 2.6 so how would one do this? Furthermore,
> wouldn't this effectively delete the previous static IP data? Maybe I just
> don't understand what you're describing - perhaps some pseudocode for
> your proposal that accomplishes the use case I'm describing would help.
>
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*.
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.
> Again, I think this is just two different pieces of information that needs to
> be
> stored separately: 1. static vs dhcp vs unconfigured IP address settings, 2.
> automatic versus on-demand startup . Trying to to modify the IP address
> settings as an indirect way of communicating whether the stack should be
> configured seems far more troublesome than just storing another policy
> variable.
>
> If you feel this should be brought to UNST instead let me know and I'll switch
> forums.
>
> Eugene
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
