💾 Archived View for magaz.hellug.gr › 01 › 07_kerncomp › index.gmi captured on 2024-02-05 at 09:52:42. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Γεωργάτος Φώτης gef@ceid.upatras.gr(mailto:gef@ceid.upatras.gr?subject=LINUX-MAGAZ) Ιαν 1998
Από τις πιο εντυπωσιακές διαφορές του Linux από τα άλλα λειτουργικά συστήματα, είναι η μεταγλώττιση του πυρήνα (kernel).
Όταν πρωτοστήνει κανείς ένα Linux σύστημα, συνήθως παίρνει ένα πυρήνα που να δουλεύει, αλλά σπάνια αυτός αντιστοιχεί στις πραγματικές ανάγκες ενός χρήστη, άρα η κατασκευή ενός νέου είναι επιβεβλημένη. Η διαδικασία αυτή είναι μάλλον διασκεδαστική - γιατί αφήνει την αίσθηση του πλήρη ελέγχου στον Η/Υ - αλλά και λίγο χρονοβόρα, συνήθως είναι υπόθεση 15 λεπτών.
Θα σας δείξω, τώρα, πώς χάρις στην μεγάλη ευελιξία του Unix (άρα και του Linux), κατάφερα να μειώσω στο 1/20, τον χρόνο μεταγλώττισης, χρησιμοποιώντας την ταχύτητα και μνήμη ενός γρήγορου συστήματος, που δούλευε για λογαριασμό ενός αργού.
Είχα ένα τοπικό δίκτυο ethernet με δύο Linux Η/Υ, έναν 386SX-20, 6MB RAM, 340MB HDD (Πόρος), και έναν 486DX-100, 20MB RAM, 1.2GB HDD (Κατελειός).
|----*---------------*------|
| |
-------- -----------
|ΠΟΡΟΣ | |ΚΑΤΕΛΕΙΟΣ|
|386-20| | 486-100 |
-------- -----------
Ο 486-100 ήθελε γύρω στα 30 λεπτά, αλλά ο 386-20 ήταν απαράδεκτα αργός στην κατασκευή πυρήνα γιατί ήθελε 17 ώρες (1 προς 34).
Την πρώτη φορά που έκανα το compile στον 386, νόμιζα ότι είχε κολήσει γιατί δούλευε όλη την ώρα στον δίσκο (swapfile). Αιτία ήταν ότι το compile, και ειδικά του πυρήνα, απαιτεί μεγάλες ποσότητες μνήμης τις οποίες ο 386 με 6MB τις παρείχε σαν ιδεατή μνήμη (virtual memory). Δεν ήμουν σίγουρος για το τι συμβαίνει και έτσι διέκοψα την μεταγλώττιση (απλά με control-c). Λίγες μέρες αργότερα τον έβαλα να φτιάξει πυρήνα και μέτρησα περίπου 17 ώρες.
Κάποια στιγμή χρειάστηκε ο Πόρος νέο πυρήνα οπωσδήποτε, αλλά δεν ήμουν πρόθυμος να τον περιμένω 17 ώρες... Το να φτιάξω πυρήνα στον 486 μέσα σε ένα μισάωρο, και να τον αντιγράψω δεν έστεκε σαν λύση, γιατί το compile εκτός από το 1 αρχείο που φτιάχνει και είναι ο πυρήνας (zImage), κάνει πολυάριθμα άλλα πράγματα όπως τα modules και κάποιες ρυθμίσεις στο /boot και στα include αρχεία, νομίζω. Κοντολογίς, θα έφτιαχνα "μισό" πυρήνα και θα χάλαγα ενδεχομένως τον 486 στις ρυθμίσεις του.
Ιδού λοιπόν η λύση: Κάνω export το / (root filesystem) του Πόρου,
echo "/ kateleios(rw,no_root_squash)" >>/etc/exports kill -HUP `pidof rpc.nfsd rpc.mountd`
και το προσαρτώ στον 486 σε έναν υποκατάλογο του:
mount poros/ /mnt.
Αυτό το σύστημα λέγεται NFS (Network FileSystem), και είναι η τυπική μέθοδος για την διανομή αρχείων μεταξύ Unix συστημάτων.
Στην συνέχεια εκτελώ την εντολή chroot στον Κατελειό, ως root:
chroot /mnt sh
Αυτή η εντολή λέει στον πυρήνα ότι η διεργασία sh (που τρέχει στον Κατελειό) και τα παιδιά της, αλλάζει το root directory και όταν θα αναφέρεται στο /usr/local/src ας πούμε, θα εννοεί το /mnt/usr/local/src. Τι σύμπτωση, εκεί είναι ο πηγαίος κώδικας του πυρήνα του Πόρου... Ότι κάνουμε από εδώ και στο εξής, "τρέχει" σαν διεργασία στον Κατελειό αλλά φορτώνει και δουλεύει από τον δίσκο του Πόρου.
Αρχίζουμε λοιπόν, μέσα από το "περίεργο" shell:
cd /usr/src/linux make config make dep make clean make zImage
Σε ένα 40λεπτο ο πυρήνας είναι έτοιμος, χρησιμοποιώντας την άπλετη μνήμη και υπολογιστική ισχύ του 486. Δεν τελειώσαμε όμως:
make modules make modules_install
Ο νέος πυρήνας υπάρχει στο /usr/src/linux/arch/i386, αλλά δεν είναι ακόμα ενήμερο το LILO στον Πόρο. Όχι!!! μην γράψετε lilo στο shell αυτό, γιατί μόνο το MBR του 486 είναι ορατό στο lilo. Απλά, βγήκα από το shell και έκανα telnet poros, μπήκα σαν root, αντέγραψα τον πυρήνα στο /zImage (εγώ τον τοποθετώ εκεί) και εκτέλεσα lilo. Το σύστημα ενημερώθηκε για την αλλαγή του πυρήνα και στο επόμενο reboot δούλεψε μια χαρά.
Υποδείξεις: