Re: DHCP Automatic Configure at Driver Connect

["Cohen, Eugene" <eugene@hp.com>]

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.ye@intel.com]
> Sent: Wednesday, August 17, 2016 9:11 PM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; Cohen, Eugene
> <eugene@hp.com>; edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>; Fu, Siyuan <siyuan.fu@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 <eugene@hp.com>; Ye, Ting <ting.ye@intel.com>;
> edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>; Fu, Siyuan <siyuan.fu@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.
> >