From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ml01.01.org (Postfix) with ESMTP id 57AC81A1DF6 for ; Tue, 16 Aug 2016 22:50:13 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 16 Aug 2016 22:50:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,529,1464678000"; d="scan'208";a="749776087" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 16 Aug 2016 22:50:13 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 16 Aug 2016 22:50:12 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 16 Aug 2016 22:50:12 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.150]) with mapi id 14.03.0248.002; Wed, 17 Aug 2016 13:50:10 +0800 From: "Wu, Jiaxin" To: "Cohen, Eugene" , "Ye, Ting" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Fu, Siyuan" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegACBdhLAABj3DZAAI4TcYAANnL8w Date: Wed, 17 Aug 2016 05:50:10 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C819F@SHSMSX103.ccr.corp.intel.com> References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C7D82@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2E3M2U1NjgtYjNhMC00ZjIyLWEwNmItMTNiODY3NTcyYzRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiI2NTduelRZenI1eHR0clFZckxKeHNuM0Y3ZzVxMGR4NWZYSDQwVUVCQVwvMD0ifQ== x-ctpclassification: CTP_PUBLIC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: DHCP Automatic Configure at Driver Connect X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 05:50:13 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, > > I mean I didn't know whether the *un-configured* status you want > > contain *no policy setting * or not. But it doesn't matter now, from > > your statement here, I know you don't care the policy setting. >=20 > Correct the static vs dhcp is irrelevant - it's the fact that the IP laye= r comes up > that is the issue. >=20 > > As I said in previous email, " The current behavior of Ip4Config2: > > DHCP policy together with D.O.R.A process, which is the same case as > > the old Ip4Config behavior ". >=20 > I'm confused by this statement because I can see a distinct difference in > behavior from the past. I can see the new code which enables the new > behavior as well Ip4Config2OnDhcp4SbInstalled- when the DHCP SB is > installed you do a configure automatically - this code simply did not exi= st > before -- see Ip4Config2OnDhcp4SbInstalled. >=20 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 detect= s the DHCP policy." In such a case, it's reasonable with the function Ip4Co= nfig2OnDhcp4SbInstalled(). Status =3D NetLibCreateServiceChild ( IpSb->Controller, IpSb->Image, &gEfiDhcp4ServiceBindingProtocolGuid, &Instance->Dhcp4Handle ); if (Status =3D=3D EFI_UNSUPPORTED) { // // No DHCPv4 Service Binding protocol, register a notify. // if (Instance->Dhcp4SbNotifyEvent =3D=3D NULL) { Instance->Dhcp4SbNotifyEvent =3D EfiCreateProtocolNotifyEvent ( &gEfiDhcp4ServiceBindingProtocolGuid= , TPL_CALLBACK, Ip4Config2OnDhcp4SbInstalled, (VOID *) Instance, &Instance->Registration ); } } =20 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 poli= cy is detected by Ip4Dxe driver (DHCP policy (note: NOT DHCP SB) together w= ith 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 poli= cy has been detected. If the policy is not DHCP during the system boot, I = think your concern will not appear. 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 wa= s implemented in the deprecated driver -- Ip4ConfigDxe. When the system boo= t next time, the previous IP configuration will cleaned and the interface w= ill be in UN-CONFIG status again. Current implementation don't have this c= lean-up operation no matter Static/DHCP policy has been set. Is this the di= fference you mentioned?=20 > > From the case you described here, are you want to separate the DHCP > > policy setting and D.O.R.A process? We don't know. >=20 > Yes, You could say I want to separate the DHCP vs static policy from D.O.= R.A. > but I don't think that's a good way to state it - I would state that we d= on't > want the IP protocol (whether it be DHCP or statically configured) to be = "up" > until a piece of UEFI calls Configure(). >=20 > > The provided solution for you (such a DXE Driver) is only based on you > > want an *un-configured* status at each boot time until the third part > > configuration. I think it does an approach for this. But I think Ting > > is right, "we need fully understand your usage case before analyzing > > the problem". Perhaps you have more detailed requirements we don't > > know clearly. >=20 > We want the IP config information stored in NVRAM (dhcp or static) to be > preserved but want a separate policy choice to delay the IP interface com= ing > "up" until a component calls Configure(). Now, let us consider your requirement:=20 1) The IP config information stored in NVRAM=20 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 patc= h to do this implementation, can you share it to us for better understandin= g?=20 >=20 > Eugene >=20 >=20 >=20 >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel