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.
>
> Correct the static vs dhcp is irrelevant - it's the fact that the IP layer
> comes up
> that is the issue.
>
> > 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 ".
>
> 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 exist
> before -- see Ip4Config2OnDhcp4SbInstalled.
>
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().
Status = NetLibCreateServiceChild (
IpSb->Controller,
IpSb->Image,
&gEfiDhcp4ServiceBindingProtocolGuid,
&Instance->Dhcp4Handle
);
if (Status == EFI_UNSUPPORTED) {
//
// No DHCPv4 Service Binding protocol, register a notify.
//
if (Instance->Dhcp4SbNotifyEvent == NULL) {
Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (
&gEfiDhcp4ServiceBindingProtocolGuid,
TPL_CALLBACK,
Ip4Config2OnDhcp4SbInstalled,
(VOID *) Instance,
&Instance->Registration
);
}
}
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.
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?
> > 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.
>
> 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 don't
> want the IP protocol (whether it be DHCP or statically configured) to be "up"
> until a piece of UEFI calls Configure().
>
> > 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.
>
> 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 coming
> "up" until a component calls Configure().
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?
>
> Eugene
>
>
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
