Ting, sounds good to me - the discussion here seems to be growing increasingly unproductive.
I'll tee this up with UNST. Eugene > -----Original Message----- > From: Ye, Ting [mailto:ting...@intel.com] > Sent: Wednesday, August 17, 2016 9:11 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; Cohen, Eugene > <eug...@hp.com>; edk2-devel@lists.01.org; Kinney, Michael D > <michael.d.kin...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: RE: DHCP Automatic Configure at Driver Connect > > Hi Eugene, > > If you propose separating DHCP process from DHCP policy setting, I > think it is more like to update/clarify existing behavior defined in > IP4Config2/IP6Config of UEFI specification. How about we move the > discussion to UNST forum, in order to draw more attention for the > topic? > > Thanks, > Ting > -----Original Message----- > From: Wu, Jiaxin > Sent: Thursday, August 18, 2016 10:49 AM > To: Cohen, Eugene <eug...@hp.com>; Ye, Ting <ting...@intel.com>; > edk2-devel@lists.01.org; Kinney, Michael D > <michael.d.kin...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: RE: DHCP Automatic Configure at Driver Connect > > 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
