Gargoyle Forum

I've looked through the build script and can see where the generic and architecture specific patches are applied, but there doesn't seem to be any support for profile specific patches.

The specific use case I had in mind relates to the Netgear D7800, where there is evidence that many production samples have 512MB of RAM (supported by the Netgear D7800 product brochure) however BETA samples are known to only have 256MB of RAM. OpenWrt, after some early toing & froing, only has a DTS configuration for 256MB (recent discussion with some historical links here).

Given that Gargoyle has the concept of profiles within architectures, this could be a case where both 256MB (default) and 512MB (specific profile) builds could exist - provided that there was a satisfactory way to apply a patch to the DTS (or copy an alternate DTS file).

Another potential use case that comes to mind is with the RaspberryPi - one scenario would be to use VLANs on the onboard ethernet port to support both WAN and LAN (requires a VLAN capable switch) as one profile with the alternate approach relying on having a USB ethernet (or USB WiFi adapter) for the WAN and use the onboard ethernet for the LAN as an alternate profile. There are ways to achieve this with smart script logic and possibly some UI changes, but is that a better approach than separate profiles (assuming documentation is also available to guide users to the image they need)?

Are there any better, or simpler/easier, approaches to achieve the same outcomes?

There's a few things that make this a bit difficult and have large performance implications.

Every new architecture adds hours to the build process.
Every new profile (as long as it uses a similar CPU/architecture) should only add 20-30 minutes to the build. If it has to build a new toolchain, then you're back to the hours again.

If you implement profile level patching, you need to force a full rebuild for each profile to clean out the patches. This makes each profile take several hours.

Also to build the same image in multiple profiles means that you'll only get the last image produced as they all have the same name.
So that causes a few issues too.

I think for your RPi example, a uci-defaults script is most appropriate.
I can't think of anything that can be done about the DTS example.

Thanks for the insights.

After some more reading and thought I think the only way to reasonably handle the D7800 case would be to define a second device to produce a separate image with it's own DTS file.

With the RPi case are you suggesting that a uci-defaults script could be used that configured the VLAN based WAN/LAN setup when only the onboard i/f is detected and the LAN over onboard i/f+WAN over second i/f setup if it detects a second i/f?

Pretty much.
Check out the patch in x86. We don't know ahead of time how many interfaces we will have, but we handle it. Something clever like that