tree 3630590a9bb9b8d4e969aed35a648cfd9f4496dc
parent ac34d7b7261173cc583c1874dc129242dfd3deec
author bjacob <benoitjacob@google.com> 1689001493 -0400
committer GitHub <noreply@github.com> 1689001493 -0400
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkrB4VCRBK7hj4Ov3rIwAA75MIAFQJE3hmK3fAYgpHsi37te+j
 lNIQi3j2ArUqMm3RRxvBNMIfRapuAybfnAXr0l9Pt7tsZLf9gomh7kDGGshmCfuF
 gERqDKASSfgg5XUXhRSUNZEZRdL/FiEt9ezpX5y/vXT770E5mB/Cz6PUIpSS88pd
 OhOGf2NIyjBq09A/FiP5wksEBU3m7gxgytx32mu2IeSigWY+Hsv6SNXy1D0F2K51
 RVWoNY0qJo7FGyjTrAVC7+P2hVMicOUVP+9vGlf9SIp1Stf68Cm0ERYpcUnQpoRw
 U1Miq+f9hFfss9773YPq8OIPA9VfKHKcZ1FfakK6CVly72//Bs3Uw1xHcUx9fyE=
 =dFF9
 -----END PGP SIGNATURE-----
 

Remove the ukernels standalone plugin (#14339)

This was done as a stepping stone towards ukernels-as-bitcode. Now that
we have that, we don't need the stepping stone anymore. Like the bitcode
build, this involved custom invocations of custom Clang to produce a
multi-arch library; this is expensive to maintain as it's a whole
separate build of all ukernel code to all target architectures.

The system-plugin remains as it's much simpler (it simply links the
native-build of ukernels as a regular library) and it's much more likely
to still be used by some classes of users going forward (people going to
places where only a system-provided toolchain can go, and not caring for
the multi-arch aspect).