mirror of
https://github.com/hanzoai/volume.git
synced 2026-10-01 00:48:00 +00:00
A fork of Rancher's local-path-provisioner at v0.0.36. The behaviour is unchanged and deliberately so — a directory on the node a pod lands on is the right thing for a disk. What changes is identity. The provisioner answers to hanzo.ai/volume rather than rancher.io/local-path. That is not branding: two provisioners sharing one name race for the same claims, and a stock k3s carries the upstream one, so a cluster running both would settle our storage by chance. Data lives at /var/lib/hanzo/volume, so reading a Hanzo cluster does not mean learning another vendor's directory. Apache-2.0 as published, unaltered, with Rancher's attribution in NOTICE. The README says what this is not: durability. A volume here dies with its node. That is hanzoai/replicate's question, one layer up, and keeping the two apart is what lets the disk stay this simple.
37 lines
562 B
ArmAsm
37 lines
562 B
ArmAsm
// +build !appengine
|
|
// +build gc
|
|
// +build !noasm
|
|
|
|
#include "textflag.h"
|
|
#include "funcdata.h"
|
|
#include "go_asm.h"
|
|
|
|
TEXT ·x86extensions(SB), NOSPLIT, $0
|
|
// 1. determine max EAX value
|
|
XORQ AX, AX
|
|
CPUID
|
|
|
|
CMPQ AX, $7
|
|
JB unsupported
|
|
|
|
// 2. EAX = 7, ECX = 0 --- see Table 3-8 "Information Returned by CPUID Instruction"
|
|
MOVQ $7, AX
|
|
MOVQ $0, CX
|
|
CPUID
|
|
|
|
BTQ $3, BX // bit 3 = BMI1
|
|
SETCS AL
|
|
|
|
BTQ $8, BX // bit 8 = BMI2
|
|
SETCS AH
|
|
|
|
MOVB AL, bmi1+0(FP)
|
|
MOVB AH, bmi2+1(FP)
|
|
RET
|
|
|
|
unsupported:
|
|
XORQ AX, AX
|
|
MOVB AL, bmi1+0(FP)
|
|
MOVB AL, bmi2+1(FP)
|
|
RET
|