[Yocto-BBB] 19. Cấu hình share state , đẩy nhanh quá trình build
1. Thiết lập HTTP server
Ở đây mình dùng nginx, các bạn hoàn toàn có thể dùng các cách đơn giản hơn. Vì ở đây đơn giản là share cái folder sstate-cache, từ 1 máy khác đã build yocto sang 1 máy cùng mạng
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
sudo apt update
sudo apt install nginx -y
cat << 'EOF' | sudo tee /etc/nginx/sites-available/yocto-sstate
server {
listen 8080;
server_name _;
location /sstate-cache/ {
alias /home/zk47/Youtube/Yocto/yocto-bbb/poky/build-bbb/sstate-cache/;
autoindex on;
}
}
EOF
sudo ln -sf /etc/nginx/sites-available/yocto-sstate /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx
Tuy nhiên khi thử vào đường link thì nó lại bị 403 Forbidden
Do đó ta phải sửa lại cấu hình. NGINX (chạy dưới user www-data) hiện đang không có quyền try cập vào thư mục sstate-cache vì thư mục home của máy đang khóa quyền đọc, thực thi đối với các user khác
Do đó ta sẽ đổi user chạy NGINX thành user hiện tại luôn, user mình là zk47
1
2
3
sudo sed -i 's/user www-data;/user zk47;/g' /etc/nginx/nginx.conf
# Restart nginx
sudo systemctl restart nginx
Okay giờ vào lại link trên ta đã thấy folder share state
Như ở đây là ta đã đem được folder lên trên mạng rồi
2. Cấu hình bên client
2.1 Cấu hình
Ở bài này để demo nên mình đã build lại mới hẳn yocto-bbb
Trong local.conf (Nên copy y nguyên từ server sang)
1
2
3
4
5
6
MACHINE = "beaglebone"
DISTRO ?= "poky"
SSTATE_MIRRORS ?= "file://.* http://192.111.63.101:8080/sstate-cache/PATH;downloadfilename=PATH"
BB_HASHSERVE = "192.111.63.101:8687"
BB_SIGNATURE_HANDLER = "OEEquivHash"
Ở đây ta có lựa chọn BB_SIGNATURE_HANDLER = “OEEquivHash”
chỉ định cho BitBake sử dụng signature handler (bộ xử lý chữ ký) có tên OEEquivHash — đây là bộ xử lý hỗ trợ Hash Equivalence (tương đương hash).
Trong Yocto/BitBake, mỗi task (ví dụ do_compile, do_install) được gán một task hash dựa trên đầu vào (source code, biến cấu hình, dependencies…). Hash này quyết định có thể tái sử dụng sstate-cache (kết quả build đã có) hay phải build lại.
Với signature handler mặc định (OEBasicHash), nếu bất kỳ đầu vào nào thay đổi → hash thay đổi → phải build lại, ngay cả khi kết quả đầu ra thực tế giống hệt nhau.
OEEquivHash giải quyết vấn đề này bằng cách:
- Sau khi một task chạy xong, nó tính output hash (hash của đầu ra thực tế).
- Output hash được gửi lên hash equivalence server (trong file của bạn là
BB_HASHSERVE = "192.111.63.101:8687"). - Server lưu mapping: task hash A → output hash X.
- Khi một máy khác (hoặc build khác) có task hash B khác nhưng server biết rằng output hash cũng sẽ là X → BitBake coi hai task là tương đương và tái sử dụng sstate-cache có sẵn thay vì build lại.
Ví dụ thực tế
- Bạn thay đổi một comment trong recipe → task hash thay đổi, nhưng file binary output vẫn giống hệt.
- Với
OEBasicHash: build lại toàn bộ. - Với
OEEquivHash: server nhận ra output hash giống → bỏ qua, dùng cache → tiết kiệm thời gian đáng kể.
2.2 Kết quả
Và thế là chạy thôi
1
2
source oe-init-build-env build-bbb
bitbake core-image-minimal
1
2
3
4
Checking sstate mirror object availability: 100% |###############################################################################################################################| Time: 0:01:12
Sstate summary: Wanted 1914 Local 0 Mirrors 520 Missed 1394 Current 0 (27% match, 0% complete)
NOTE: Executing Tasks
Setscene tasks: 1914 of 1914
Tỉ lệ này mới chỉ là 27% match chưa cao lắm, do giữa 2 máy mình vẫn có những config khác nhau
Nếu các bạn chạy xong 1 máy, mà copy thẳng config y hệt và cấu trúc y hệt. Cache có thể lên tới 99%
Bài này khá ngắn, nhưng mình vẫn viết vì mình thấy nó khá hữu dụng, hi vọng giúp được mọi người :vv