BFor a while now, I've been looking at how we have a LOT of hardware enablement images with distinct repos, workflow, etc... and it's a serious pain to maintain. I've got a goal to clean it up.
This is something I've chatted about with various members of the team, but wanted to get down in a thread.
This is something I've chatted about with various members of the team, but wanted to get down in a thread.
BSo just a quick sketch of the plan after I've looked at various methods we use for matrix and workflow management in bluefin and ucore...
I will create a repo
The 6 repos themselves will be archived after the final migration.
I will create a repo
hwe- asus
- asus-nvidia
- framework
- nvidia
- surface
- surface-nvidia
The 6 repos themselves will be archived after the final migration.
B@j0rge @Kyle Gospo @EyeCantCU @Noel @Robert (p5)
I'm sure I should ping others, but this is a start.
I'm sure I should ping others, but this is a start.
BThe distinction between
mainhwemainhwe
EI think having everything under a single HWE repo makes a lot of sense. The one thing I'd be concerned about is the number of concurrent builds we'd have to support
Something else also comes to mind... Kernel fsync supports like literally everything out of the box. Could be worth maintaining just fsync images?
Something else also comes to mind... Kernel fsync supports like literally everything out of the box. Could be worth maintaining just fsync images?
EHmm... I guess what makes that slightly more challenging is Surface still needs libwacom-surface and Asus asusctl...
Kwe could probably break it up by hardware layer or by image
Kso it builds in stages
EThat would work!
Bwe can manage the concurrent builder issue
Byes, exactly
Bregarding "just using fsync" that's scope creep 
my mission is maintainability... once we can build stuff and make a change by only touching 4 repos, not 9 or 10... then we can see about that
my mission is maintainability... once we can build stuff and make a change by only touching 4 repos, not 9 or 10... then we can see about that
JYeah and I've been talking to github, assign that problem to me, ya'll handle the tech. 
Byeah, i'll let you know when/if we hit a problem on it
FThe issue with fsync is that some unexpected issues can arise, like what @bsherman experienced with audio crackling.
But it is indeed more convenient to have everything in a kernel & in a single image, than to maintain multiple ones.
But it is indeed more convenient to have everything in a kernel & in a single image, than to maintain multiple ones.
Kfsync is a hard no from me, it's nice but it's not upstream
Kgood for bazzite
Byeah, really, just want to keep this thread about repo and build workflow consolidation... don't want to grow the scope any more
RSo will it be the same structure as Bluefin - a packages.json file containing the different packages to install for each image, and a separate directory for config files to copy over to each?
Bi've still got to look at some details per repo.
right now, only
so, I'll just do my best to merge it all together in a sane way
right now, only
surfaceso, I'll just do my best to merge it all together in a sane way
Bi do plan to keep
nvidiaAsahi is about to give me a huge dose of scope creep
But yeah, no. You and Kyle are correct
But yeah, no. You and Kyle are correct
NDo we have an issue open for this? We should probably have one so we can track it.
Bgoodcall
BNno worries, probably should've confirmed At least we have one.
At least we have one.RWould it be easier to manage if we keep Nvidia separate? I can see us wanting surface-nvidia, framework-nvidia etc, so keeping Nvidia as another "layer" should make it easier to create the pipelines and dependencies for these.
We're not going to have a surface-framework, so there's no dependencies between these and can therefore be built concurrently, but we will have dependencies on the Nvidia images for all others
We're not going to have a surface-framework, so there's no dependencies between these and can therefore be built concurrently, but we will have dependencies on the Nvidia images for all others
Jyeah I suspect that's what will happen, but bsherman is sick so he wanted to grab some shuteye
Jframework can go away entirely, it's basically all upstream now other than the kargs
J@Kyle Gospo so if we do a kmod for framework that removes the need for framework images. Could we do the same for asus?
BWhat kmod are we talking about for framework?
Jhe was talking for flipping the boot paramater
Jso the user wouldn't need to add the karg themselves, dunno, this part of the stack is a magic box for me
KThere's a driver we have to unload to get parts of framework working
KThe idea is to just patch that so it detects the framework DMI and never loads in the first place
KThat way that hardware doesn't need a device layer
Bso... you could build that as a kmod instead of using
asus-kerneland the custom asus-firmware?
KSeparate from asus, this is framework specific. We never shipped a kernel for them, just a whole bunch of Kernel arguments
KWhich can simply be implemented better
Bsorry, i switched gears in my brain, oops
B@j0rge i just want to get clear on if there's stuff we DON'T need me to merge ... i was planning to pull in asus, asus-nvidia, framework, surface, surface-nvidia
but there's some chatter making me think we don't need framework?
but there's some chatter making me think we don't need framework?
JI marked framework as deprecated last month
JKyle is going to enable it in bazzifin directly via that akmod
Bwell, this is a good time to be done with it maybe then
Jlet me check the framework thread
Bi can just leave it alone until we are ready for archival... but don't need to bother about merging it here
Jactually you know what, let's leave framework alone for now. I need to make an announcement in the thread that at F40 people will need to rebase and I don't wanna leave them hanging without an OS
Bright, i just won't touch it for the moment... i'll merge other stuff and we can see where that leaves us
Jnod
