In what circumstances 'Openwrt ' is preferred over 'Buildroot' frame work?

Question

I'm confused between Buildroot and OpenWrt. I mean in which scenario one will choose OpenWrt over Buildroot.

As per my understanding, there are only 2 differences between Buildroot and OpenWrt

1. OpenWrt provides package manager(opkg) which is not available for buildroot.

2. OpenWrt provides the good number of packages support for most networking related devices (routers, switches etc).

If I don’t need any package manager for a project and yet I want network support then I can choose Build root over OpenWrt, right? Is it not possible to build networking related packages in Buildroot itself?

I mean if package manager is not a concern we can go ahead with buildroot itself right? there is no need to opt OpenWrt?

If I'm wrong can anyone address the scenarios where buildroot fails and Openwrt wins?

I mean is it possible to achieve what OpenWrt is doing(Building Firmware images for networking related hardware) with Buildroot itself. I observed that the init process (early userspace) behaviour is different for Buildroot and OpenWrt.

• In Buildroot init script will be read etc/inittab and the scripts under init.d will be executed.
• In Openwrt procd is the init script (rc.common)and will run the scripts listed under init.d as well as scripts under rc.d.

Will this affect any way if I try to use Buildroot to generate an Image for the firmware which is supported by OpenWrt?

Answer 1

OpenWRT is based on Buildroot, just as Ubuntu is based on Debian. While the two projects share code, OpenWRT focuses on routers and the like, whereas buildroot is just a general purpose toolchain for embedded linux. What you should be asking yourself is, "Which of these two projects contain what I need to accomplish my task?"

OpenWRT can be compiled without opkg, in fact, many packages can be ripped out and it will work just fine. This is useful for devices with less resources.

Also, OpenWRT can be made to use regular init scripts; you don't have to use procd if you don't want to. The abstractions offered by it do make it easier to configure an existing package, however, if you are looking to port a new package, advanced knowledge of procd is needed to create those from scratch.