From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ml01.01.org (Postfix) with ESMTP id 690F31A1E04 for ; Fri, 12 Aug 2016 19:37:10 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 12 Aug 2016 19:37:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,513,1464678000"; d="scan'208";a="1024671351" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 12 Aug 2016 19:37:10 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 12 Aug 2016 19:37:09 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX151.amr.corp.intel.com (10.18.125.4) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 12 Aug 2016 19:37:09 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.116]) with mapi id 14.03.0248.002; Sat, 13 Aug 2016 10:37:07 +0800 From: "Wu, Jiaxin" To: "Cohen, Eugene" , "Ye, Ting" , "edk2-devel@lists.01.org" Thread-Topic: DHCP Automatic Configure at Driver Connect Thread-Index: AdHzMrTK7bp7ndKxTJOq/Qc4XXghzQARlkIgAAQKA6AAE/Dm8AAV/5hgABh+18AAGhwegA== Date: Sat, 13 Aug 2016 02:37:07 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C677D@SHSMSX103.ccr.corp.intel.com> References: <895558F6EA4E3B41AC93A00D163B7274137C5EA3@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137C63EC@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTFlZTFjYzUtZGZiNy00YzE3LTliNmItN2Y3NGJlODJiNmQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjQ2WmQ4K0ltZzFtdERJdWVTTVVRNmlZS0ZDdkZMV2k4bDF5RzNqXC9XT1RNPSJ9 x-ctpclassification: CTP_IC 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: Sat, 13 Aug 2016 02:37:10 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Jiaxin, >=20 > > > 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 applicati= on. > > > > 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 This is what I want to confirm with you that my understanding is right? You= complained the network interface comes "up" at each boot, what does "come= s up" exactly mean? So, I gave the above two guesses 1) and 2). > > 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. >=20 > 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 behavio= r > consistent with the original Ip4Config behavior? This seems like somethi= ng Of course not. I mean if my guessing 2) is correct, it's not reasonable bec= ause UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in= one of them. I just recalled the old Ip4Config behavior: no policy assigne= d default (if I remember correctly). So, don't misunderstand my truly mean= s. It's unrelated to the *behavior consistency*. > 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. >=20 > > > > > > 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. >=20 > 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 Ip4Conf= ig2 > 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 ju= st > don't understand what you're describing - perhaps some pseudocode for > your proposal that accomplishes the use case I'm describing would help. >=20 First, *based on the current UEFI Spec (only static / dhcp policy)*, I want= to highlight my understanding of *un-configured* status you mentioned: pol= icy should be always set, *un-configured* means *no IP address configuratio= n*. If we want to implement such a *un-configured* state, one *DXE_DRIVER* can = be used with Ip4Config2 protocol. Detailed see below pseudocode: First, register a notify for Ip4Config2 protocol in your Dxe Driver EntryP= oint: EfiCreateProtocolNotifyEvent ( &gEfiIp4Config2ProtocolGuid, TPL_CALLBACK, Ip4Config2InstalledCallback, NULL, &Registration ); Then, In your Ip4Config2InstalledCallback() function, you can change the de= fault policy for the current boot: Ip4Config2InstalledCallback () { gBS->LocateProtocol ( &gEfiIp4Config2ProtocolGuid,=20 Registration,=20 (VOID **) &Ip4Config2Instance ); // // Change the policy to Ip4Config2PolicyDhcp to clean the static s= etting. // Policy =3D Ip4Config2PolicyDhcp; Ip4Config2Instance->SetData( Ip4Config2Instance, Ip4Config2DataTypeP= olicy, sizeof (EFI_IP4_CON= FIG2_POLICY), &Policy ); // // Change the policy to Ip4Config2PolicyStatic to clean the DHCP p= olicy setting. // Policy =3D Ip4Config2PolicyStatic; Ip4Config2Instance->SetData( Ip4Config2Instance, Ip4Config2DataTypeP= olicy, sizeof (EFI_IP4_CON= FIG2_POLICY), &Policy ); } After that, your previous setting will be cleaned, and reach a *un-configu= red* state. I know the addition Dxe Driver is an indirect way to meet your = requirement, but based on current UEFI Spec, it's one-time event if you add= ed in your platform ahead. > Again, I think this is just two different pieces of information that need= s 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. >=20 > If you feel this should be brought to UNST instead let me know and I'll s= witch > forums. >=20 > Eugene >=20 >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel