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 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 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. 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
