2015-02-19 20:37:53 -05:00
|
|
|
package libnetwork
|
|
|
|
|
|
2015-02-20 01:21:05 -05:00
|
|
|
import (
|
2015-04-13 14:40:42 -04:00
|
|
|
"github.com/docker/libnetwork/driverapi"
|
2015-05-26 13:46:21 -04:00
|
|
|
"github.com/docker/libnetwork/drivers/windows"
|
2015-02-20 01:21:05 -05:00
|
|
|
)
|
2015-02-19 20:37:53 -05:00
|
|
|
|
2015-04-13 14:40:42 -04:00
|
|
|
type driverTable map[string]driverapi.Driver
|
2015-02-20 01:21:05 -05:00
|
|
|
|
Make driver packages register themselves via DriverCallback
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-11 08:46:29 -04:00
|
|
|
func initDrivers(dc driverapi.DriverCallback) error {
|
|
|
|
|
for _, fn := range [](func(driverapi.DriverCallback) error){
|
2015-05-26 13:46:21 -04:00
|
|
|
windows.Init,
|
2015-05-03 16:37:22 -04:00
|
|
|
} {
|
Make driver packages register themselves via DriverCallback
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-11 08:46:29 -04:00
|
|
|
if err := fn(dc); err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
2015-02-20 01:21:05 -05:00
|
|
|
}
|
Make driver packages register themselves via DriverCallback
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
2015-05-11 08:46:29 -04:00
|
|
|
return nil
|
2015-02-20 12:12:29 -05:00
|
|
|
}
|