kumquat-buildroot/package/dahdi-linux/Config.in

16 lines
503 B
Plaintext
Raw Normal View History

package/dahdi-linux: new package dahdi-linux provides kernel modules to drive a variety of telephony cards, ranging from low-end one-channel to higher-end multi-channel cards. It also provides headers for userland to talk to those cards. With a bit of love, dahdi-linux can use our kernel-module infrastructure. Wee! :-) Still, there are a few specificities about dahdi-linux. First, it needs to install a few binary firmware blobs, which it wants to download at install time. Since we do want to be able to do completely off-line builds, we need to downlaod them manually. So we have the full list of firmware blobs (even if some can only be used on an i386/x86_64 target, we still uconditionally download them), for which we have locally-computed sha256 (no hash provided by upstream for the blobs). Second, the install procedure for the firmware blobs needs to have access to the Linux kernel .config file, so it can decide whether to install the blobs or not. We can force not to install them, but we can't force to install them... :-/ And anyway, we'd have to do the same check as is already done by dahdi-linux, so no need to duplicate that. Finally, the licensing is relatively weird. Although it is obvious and straightforward for the most part of dahdi-linux, consisting of mostly GPLv2 and a few LGPLv2.1, there is one gotcha. Of the firmware blobs, one is provided as a .o file, with no licensing information whatsoever, without any source available from upstream, but is directly linked to a GPLv2 file. This is very concerning, but there is not much we can do about it, except delegate to the legal reviewer whether that is acceptable or not. AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or later, as it uses internals that have been removed in linux-4.0. There has been no update upstream dahdi-linux to fix that. There's not much we can do, except warn the user in the help text. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Arnout: use SPDX license names and add hashes for license files] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
config BR2_PACKAGE_DAHDI_LINUX
bool "dahdi-linux"
package/dahdi-linux: new package dahdi-linux provides kernel modules to drive a variety of telephony cards, ranging from low-end one-channel to higher-end multi-channel cards. It also provides headers for userland to talk to those cards. With a bit of love, dahdi-linux can use our kernel-module infrastructure. Wee! :-) Still, there are a few specificities about dahdi-linux. First, it needs to install a few binary firmware blobs, which it wants to download at install time. Since we do want to be able to do completely off-line builds, we need to downlaod them manually. So we have the full list of firmware blobs (even if some can only be used on an i386/x86_64 target, we still uconditionally download them), for which we have locally-computed sha256 (no hash provided by upstream for the blobs). Second, the install procedure for the firmware blobs needs to have access to the Linux kernel .config file, so it can decide whether to install the blobs or not. We can force not to install them, but we can't force to install them... :-/ And anyway, we'd have to do the same check as is already done by dahdi-linux, so no need to duplicate that. Finally, the licensing is relatively weird. Although it is obvious and straightforward for the most part of dahdi-linux, consisting of mostly GPLv2 and a few LGPLv2.1, there is one gotcha. Of the firmware blobs, one is provided as a .o file, with no licensing information whatsoever, without any source available from upstream, but is directly linked to a GPLv2 file. This is very concerning, but there is not much we can do about it, except delegate to the legal reviewer whether that is acceptable or not. AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or later, as it uses internals that have been removed in linux-4.0. There has been no update upstream dahdi-linux to fix that. There's not much we can do, except warn the user in the help text. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Arnout: use SPDX license names and add hashes for license files] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
depends on BR2_LINUX_KERNEL
help
DAHDI (Digium/Asterisk Hardware Device Interface) is the open
source device interface technology used to control Digium and
other legacy telephony interface cards.
DAHDI Linux is the open source device driver framework used to
interface Asterisk with telephony hardware.
https://github.com/asterisk/dahdi-linux
package/dahdi-linux: new package dahdi-linux provides kernel modules to drive a variety of telephony cards, ranging from low-end one-channel to higher-end multi-channel cards. It also provides headers for userland to talk to those cards. With a bit of love, dahdi-linux can use our kernel-module infrastructure. Wee! :-) Still, there are a few specificities about dahdi-linux. First, it needs to install a few binary firmware blobs, which it wants to download at install time. Since we do want to be able to do completely off-line builds, we need to downlaod them manually. So we have the full list of firmware blobs (even if some can only be used on an i386/x86_64 target, we still uconditionally download them), for which we have locally-computed sha256 (no hash provided by upstream for the blobs). Second, the install procedure for the firmware blobs needs to have access to the Linux kernel .config file, so it can decide whether to install the blobs or not. We can force not to install them, but we can't force to install them... :-/ And anyway, we'd have to do the same check as is already done by dahdi-linux, so no need to duplicate that. Finally, the licensing is relatively weird. Although it is obvious and straightforward for the most part of dahdi-linux, consisting of mostly GPLv2 and a few LGPLv2.1, there is one gotcha. Of the firmware blobs, one is provided as a .o file, with no licensing information whatsoever, without any source available from upstream, but is directly linked to a GPLv2 file. This is very concerning, but there is not much we can do about it, except delegate to the legal reviewer whether that is acceptable or not. AS an aside, dahdi-linux drivers do not build with a kernel 4.0 or later, as it uses internals that have been removed in linux-4.0. There has been no update upstream dahdi-linux to fix that. There's not much we can do, except warn the user in the help text. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Arnout: use SPDX license names and add hashes for license files] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-09 23:39:26 +02:00
comment "dahdi-linux needs a Linux kernel to be built"
depends on !BR2_LINUX_KERNEL