<aparcar[m]>
does netifd support some kind of alias setting? I'm looking to map a specific PCI path to a device since the eth order detected by the kernel is wrong. nbd ?
<dwfreed>
ah, probably to save space on the buildbot
<Habbie>
likely
<Habbie>
ok, if 1.79 passes i'll try 1.80 + 19221
<dwfreed>
perhaps they could be relocated to cheaper, slower storage instead
<Habbie>
like, downloads.openwrt.org :)
indy has quit [Ping timeout: 480 seconds]
<ynezz>
IIRC it's running from RAM, buildbot was unusable from disk
<dwfreed>
also not surprising
srslypascal has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
minimal has joined #openwrt-devel
<aparcar[m]>
ynezz: that's exactly what i need. wow...
<aparcar[m]>
i owe you a beer
<Slimey>
=)
<aparcar[m]>
hurricos: what's the status of your x86 interface rename patch? I can't find it on the ML
<Habbie>
recursor + boost 1.79 builds
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
notch has joined #openwrt-devel
notch is now known as Guest890
<hurricos>
aparcar: I haven't pushed it further yet. Is there interest in making it available for all targets?
<hurricos>
I'm not 100% comfortable with the idea of a bunch of patches rushing into each targets' `02_network`s
<hurricos>
I'd prefer people modified the ... uh ...
srslypascal has joined #openwrt-devel
<hurricos>
I don't know how one "activates DSA" to get it to set ethernet port names. It confuses me greatly, is DSA supposed to manage ports that are plain GMII on the SoC?
<hurricos>
I thought DSA special-cased CPU ports.
<aparcar[m]>
hurricos: I need exactly this feature for x86 so I'm fine having this in x86 only, I don't see how this is a problem on DTS devices
<aparcar[m]>
talking to dangowrt another solution could be to have this handled by netifd, however I see the advantage of having this in the early config steps
<jow>
hurricos: you can't "activate DSA" for the sake of setting netdev names. It is a kernel subsystem for dealing with switch ICs in particular. It is not applicable to simple ethernet NICs
<jow>
we should stick to the upstream endorsed solution of using ip link set name (or the netlink equivalent of it)
<jow>
as you proposed in your patch basically
<jow>
it needs a little bit of rework though to be robust
<jow>
like the two phase renaming thing
<jow>
and using full arguments for "ip"
<jow>
o abbreviations
<aparcar[m]>
I implemented a two phase solution previously, I'd rework the script accordingly
<aparcar[m]>
hurricos: are you fine I put some work into this or do you want to continue?
Guest890 has quit [Quit: Page closed]
<hurricos>
I'd 1000% prefer device trees be consumed in this patch TL;DR. I think
<hurricos>
ops
<hurricos>
Hmm, terminal is giving me som efunnies.
<hurricos>
jow: Right, OK. I know the "DSA configuration style" is available for /etc/config/network which is what confused me. I understand that DSA is strictly for switching / routing ICs but was not sure whether the internal fabric of any CPUs was considered
<hurricos>
aparcar: The patch applie sg
<hurricos>
... sorry. The patch works globally for x86 and non-x86, but I'd appreciate if you could also implement this using (for devicetree-enabled targets) /sys/firmware/devicetree/base/aliases/*
<jow>
actually, from a configuration pov, DSA is irrelevant
<jow>
all it changes is the netdev names
<jow>
but from a uci syntax perspective, there's e.g. no difference between an x86 server with 3 seaprate pcie cards or an mt76 router with a 5 port dsa switch
<hurricos>
OK, that's fine. I still think that whenever OpenWrt is holding a board-specific device tree, we should use it for storing board-specific config
<jow>
just that on the former the netdevs likely happen to be called eth0, eth1, eth2 while on the latter they're lan1, lan2, lan3, lan4 and wan
<hurricos>
I don't want my name on a mess in 02_network :^)
<hurricos>
... like I'm doing for x86 ... but that's justified because there's nowhere else to do it :\
<hurricos>
aparcar, jow, others: Do what you like with the patch, I'm glad someone else wants it
<aparcar[m]>
hurricos: well I'd upstream it once it complies with jow requests
<hurricos>
:thumbsup:
<aparcar[m]>
do you want to send it upstream?
<aparcar[m]>
i.e. github
<hurricos>
I can do that.
<hurricos>
jow: my worry with doing two rounds of config is that it's usually not needed, and setting those ip link(s) can take time on non-DSA-enabled, slow platforms. In my case only two NICs ever get set to a hashed.
<hurricos>
Moreso it's also a pain in the ass to write code for
<hurricos>
but I'm just not good at jshn. Well, let me move it to Github now and we can talk about it
<aparcar[m]>
hurricos: please ping me once you posted it somewhere?
<hurricos>
aparcar: I don't want to block this PR trying to scrape /sys/firmware/devicetree/base/aliases/* as well for naming
<hurricos>
but if you have any ideas of how to shim OpenWrt-specifics into there without borking all OpenWrt boards, I'm all ears
<hurricos>
I think it's already overloaded with vendor crap -- e.g. WS-AP3825i vendor u-boot follows the aliases node to find where to shim MAC addresses
<hurricos>
I just learned about this. I did not realize things could be done this way fwiw. There might be some DIP switch dependencies that are hard-coded on these boards which actually would make this useless for me.
<hurricos>
Borromini: Looks like the T30-W actually *boots* from the SDHC making this *trivial*
<hurricos>
If you have one, could you binwalk the SD card for us? :^)
<hurricos>
and create a thread!
srslypascal has quit [Ping timeout: 480 seconds]
<Borromini>
hurricos: no i just saw one for sale (looks like it)