The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---> On Jun 24, 2025, at 5:52 AM, Daniel Golle <[email protected]> wrote: > > On Mon, Jun 23, 2025 at 08:15:15PM -0600, Philip Prindeville wrote: >>> On Jun 14, 2025, at 3:33 AM, Daniel Golle <[email protected]> wrote: >>>>> On Jun 13, 2025, at 5:01 PM, Daniel Golle <[email protected]> wrote: >>>>> On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via >>>>> openwrt-devel wrote: >>>>>> Should the BPi-R4 be more richly provisioned? It's got 4 or 8GB of DRAM >>>>>> so it's hardly a "skinny" platform. >>>>> >>>>> I would leave that to the user and keep the default image with just what >>>>> is necessary. Diverging and creating "rich" images for specific devices >>>>> imho opens a can of worms which will require continous maintainance. >>>>> How would we decide which packages to include? How would we draw the line >>>>> for each and every board whether in our opinion the amount of flash and >>>>> ram is enough for any particular feature, and why some features are >>>>> present while others aren't? >>>> >>>> Busybox has defaults that people are welcome to turn off. Why not have >>>> something homologous for targets? >>> >>> I don't understand...? Of course anyone who builds from source is free to >>> select all packages they want and is in no way bound to the default >>> package selection. >> >> That goes both ways. People can also unselect all the packages they don’t >> want. > > People, yes. Automated build processes, such as the buildbots generating > the images for downloads.openwrt.org will just use the default. > And that's what people expect and is written in the various (3rd party) > docs, how-tos and so on. You’d think there would be an easy way to mark in the targets a list of platforms to not build via the automation, so we could built the “banana pi-r4 lite” in the automation, but leave it to users to build “banana pi-r4 full” (or whatever) themselves. > As I said, maintaining dedicated package selections for thousands of > devices is not feasible for a small team of volunteer maintainers. There > has to be a clear rule which packages should be included for each board. > For now this rule is to include the default selection of packages for > the class of device (ie. "router" in this case) plus the kernel drivers > and userland tooling for whatever hardware the board comes with. > We risk getting into endless discussions whether packages for a specific > use-case should be included on a specific board. > > Of course, again, the community is free to provide such rich images for > specific devices, and if you take a look into the forums you will find > plenty of them. > >>>>> The 2.5GE PHY is built-into the SoC and apart from being populated >>>>> differently the boards are identical, there is no iway to detect in >>>>> software which variant we are dealing with. SinoVoip equips the R4 with >>>>> some I2C EEPROMs which would be perfectly suitable to be used to indicate >>>>> the board variant or even contain a factory-assigned MAC address. Sadly >>>>> they come all empty. >>>> >>>> >>>> Well, it's EEPROM, so it can be reblown, right? >>> >>> Sure, but as it isn't done in factory it's just another piece of >>> persistent memory the user can do with what ever they want. >>> We cannot use it to find out which board we are dealing with. >>> >>>> Don't know anything about that. I do my own monolithic builds from >>>> scratch. Don't use image-builder. >>> >>> Ok, then you can anyway always divert from defaults in any way you >>> want. What is restricting you? >> >> >> Nothing, but I’m not an expert in the hardware of every platform. Having >> the profile preselect most of the relevant packages and drivers for me would >> be helpful. >> >> For instance, the BPi-R4 I got came with an image that doesn’t have NVMe >> drivers/utilities installed, nor does it seem to have a uboot that can boot >> from NVMe. > > The board also doesn't come with an NVMe. It comes with an M.2 slot, and > PCIe drivers are included. What ever you want to connect to that M.2 > slot is up to you. Without any adapters this could already in this case > as well be an AHCI SSD as well, or a SATA host controller offering > actual SATA ports, ... Well, that depends who you buy it from. There are a couple of vendors online that bundle with modem cards, SSD or NVMe sticks, etc. > >> We keep acting like every platform is a WRT54G w/ 64MB. They’re not. If we >> have room, let’s stretch out legs. > > 4MB of flash and 16MB of RAM in case of the WRT54G btw, 32MB of RAM > on the WRT54GL version supported by OpenWrt ;) > > Imho it should be up to the user to decide what to do with additional > resources. We obviously cannot ship everything, it will always have to > be a subset of the available packages. Well, and that’s to my point: if we support more memory in the form of NVMe, then users will have the room for whatever they choose to install. > We already do have a 'small_flash' flag for devices with very little > flash, and we do have (not very often used) device types 'basic', 'nas', > and 'router' which influences the default selection. We could think > about introducing more device types. > > Also this is a "two way road", in the sense that users chose OpenWrt > images even for eg. x86_64 VMs exactly because they fit into a very > small amount of storage and don't need much RAM. What you see as a flaw > others (including myself) see as a strength. Yeah, I’ve been thinking about us developing an Amazon EC2 image for the market place for people who have CGNAT, for instance, but might want to lease a VM with a fixed IP address, host DNS there, and then do port-forwarding over VPN... and we could have the royalties go to the project. > >> This is, after all, a 2-way street. If vendors see richly provisioned >> platforms as being the norm, perhaps they’ll react by increasing the amount >> of DRAM and Flash that comes on their base models. > > I think vendors mostly see the SDK provided to them by the chip vendors, > and with the bill of materials in mind they envision a set of features > they want to support. By "support" I mean also in terms of providing > actual support to users, which may cost more than giving a board a > little bit of extra storage or RAM. I highly doubt that OpenWrt's > selection of default packages for any specific board will influence > hardware vendors to provide more flash or RAM -- either we are talking > about consumer electronics stuff in a plastic case which mostly just has > to be cheap and comes with a fixed set of features, or we are talking > about "consumer devboards" like the BananaPi boards which are already > equipped with (for OpenWrt terms) huge amounts of storage and RAM, often > maxing out the amount of RAM the underlying SoC is able to deal with, > and providing easy ways to extend the storage using an SSD. Except of course, when there’s a M.2 slot that supports NVMe but we don’t support it. Or there’s a way of installing persistent storage, but we don’t easily support that either. How much work would it be, anyway, to have the options to build images that provision /var at install time, and a “sysupgrade” that supports it and doesn’t lose your configuration… -Philip
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
