Eugene, > > Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not > > accurate as you said "when the DHCP SB is installed you do a configure > automatically". > > It's more proper to say "IPv4 driver is requiring DHCP SB due to it > > detects the DHCP policy." In such a case, it's reasonable with the > > function Ip4Config2OnDhcp4SbInstalled(). > > I see - my observation was based on the fact that removing this prevented the > undesirable automatic configuration, but what you say makes sense. > > > I agree with you this code did not exist in *Ip4Dxe* before. We > > implemented this function because of we need start the AutoConfig due > > to the DHCP policy is detected by Ip4Dxe driver (DHCP policy (note: > > NOT DHCP SB) together with D.O.R.A process). It does may appear > > AutoConfig straight away with DHCP SB if Ip4Dxe ahead of Dhcp4Dxe. But > > the precondition is that the DHCP policy has been detected. If the > > policy is not DHCP during the system boot, I think your concern will not > appear. > > Are you saying the IP4 interface will not come "up" even for a static IP > policy?
If the policy is static and the default interface has not been referenced/used, we can say it's not come up. Once you get involved and do any IP assignment, the default interface is only ready to use, we can say it has been configured and it's available now. For *Ip4Dxe*, I think no matter what kind of policy behavior will only affect the default interface (configured or un-configured), currently : 1) If the policy is DHCP, Ip4Dxe will try his best to be in available state. 2) If the policy is static, it will depend on the third part configuration. After the default interface is ready and available, the only way I can think to make it in un-configured state is leveraging the DXE_DRIVER (I mentioned it before) to do some cleanup according the current implementation. For #1, the DHCP process will be triggered automatically. For #2, I agree such a DXE_DRIVER driver will destroy the previous configuration data (Actually, the old Ip4Config behavior also did it), but if not, how can we reach such a un-configured state since the data already saved? > I was assuming it would in this case. I'm not sure how big a deal this is > because > if there are no listeners or connections initiated it's kind of a don't-care > - I > think the only difference would be whether responses to ARP are provided. > > > Now, compared to old Ip4Config behavior, we take 'ifconfig' tool > > command as example - "ifconfig -s eth0 dhcp": > > The Ip4Config->Start will be invoked to start the auto configuration. > > It was implemented in the deprecated driver -- Ip4ConfigDxe. When the > > system boot next time, the previous IP configuration will cleaned and > > the interface will be in UN-CONFIG status again. Current > > implementation don't have this clean-up operation no matter > > Static/DHCP policy has been set. Is this the difference you mentioned? > > Okay - this must be it - so DHCP magically turned back into "unconfigured" > effectively creating the on-demand Configure() effect, at least for DHCP > cases, > that we now desire. Interesting. > Yeah. > > Now, let us consider your requirement: > > 1) The IP config information stored in NVRAM > > 2) A separate policy to delay the IP interface coming up until a > > component calls Configure (). > > > > #1 is also the current implementation. For 2), I remember you have one > > patch to do this implementation, can you share it to us for better > > understanding? > > Yes, my first thought was to make the handling of > Ip4Config2OnDhcp4SbInstalled conditional based on a PCD value (the policy in > this case, would be in the PCD value). Based on the limited experiment I did > this seems to have the desired effect but based on your expertise perhaps > there is a better location for such a check? > Ok, understand your purpose. So, It's not related to the IP protocol to be "up" or not , and also not related to *reach un-configured state* if policy is *static*. Right? If so, we can only focus on the question "whether to separate the D.O.R.A process with DHCP policy or not". In addition, I don't think it's a good idea to use PCD to decide/control the DHCP policy behavior. We should keep the DHCP policy behavior constant (no matter to separate the D.O.R.A process or keep the current implementation). In my opinion or usage case, keep the current implementation is fine. But as you complained, it does trouble your previous usage. It will be appreciated if you can describe your usage case here, for example, step1, step2,...:). > Thank you for patiently helping me with this - it's been enlightening to learn > the history and thinking behind the config process. > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
