Hi Thomas, On Tue, Jan 26, 2010 at 10:35 AM, Thomas Egerer <hakke_007@xxxxxx> wrote: > Luiz, > let me tell you why I'd like to have an extra config variable. Let's > imagine an admin who want to add the upcoming bnep interfaces to an > _already_ existing bridge (for that matter a test whether the given > interface name already exists would be nice, too) plus he knows about > the infrastructure behind the bridge and decides to set a different > forward delay. He could, of course reset the delay, once the bridge is > up. But ideally he would specify the setting in the network.conf. Hence > the extra config variable (which btw. were actually two variables by the > time I started writing the patch). In lets say a pure network sense you are probably right, but what Im arging about is that the PAN spec doesn't mentioned anything about this, so in the spec sense once you accept the connection the interface _is_ already fully functional. So either we always set the delay to 0 or we have to wait until the interface is ready to accept the connection, although the second alternative is doable it happens to be after the connection is accepted that the network interface is created and there is no way to inform the other part that there is an arbitrary delay before the interface become functional again. -- Luiz Augusto von Dentz Engenheiro de Computação -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
