Nghiên cứu và phát triển nút mạng Ad - Hoc có tính di động cao

bằng biến môi trường Để xem thiết lập USE cuối cùng được Portage sử dụng, hãy chạy emerge --info. Lệnh này sẽ liệt kê mọi biến liên quan (bao gồm biến USE) được dùng bởi Portage. # emerge --info Cập nhật lại toàn bộ hệ thống để sử dụng USE-flag mới Nếu thay thế vài USE flag và muốn cập nhật lại toàn bộ hệ thống để dùng những USE flag này, hãy dùng tùy chọn --newuse của emerge: # emerge --update --deep --newuse world Kế tiếp hãy chạy depclean của Portage để loại bỏ những phụ thuộc theo điều kiện, đã được cài đặt trên hệ thống cũ, nhưng không còn được dùng bởi USE flag mới. # emerge -p --depclean Khi depclean hoàn tất, hãy chạy revdep-rebuild để điều chỉnh những ứng dụng được liên kết động với các thư viện đã bị loại bỏ. revdep-rebuild nằm trong gói gentoolkit; đừng quên emerge gói này. # revdep-rebuild Khi hoàn tất, hệ thống của bạn sẽ sử dụng những thiết lập USE flag mới. USE flag riêng cho mỗi gói Xem các USE flag hiện có Hãy xem ví dụ về mozilla: những USE flag nào sẽ được dùng? Để biết, chúng ta dùng emerge với tùy chọn --pretend và --verbose: # emerge --pretend --verbose mozilla These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] net-www/mozilla-1.5-r1 +java +crypt -ipv6 +ssl +ldap +gnome -debug +mozcalendar -mozaccess -mozxmlterm -moznoirc -moznomail -moznocompose -moznoxft emerge không phải là công cụ duy nhất để thực hiện công việc này. Thực ra, một công cụ khác là equery nằm trong gentoolkit được tạo ra để cung cấp thông tin gói. Trước hết hãy cài đặt gentoolkit: # emerge gentoolkit Giờ hãy chạy equery với tham số uses để xem những USE flag của một gói nhất định. Ví dụ, với gói gnumeric: # equery uses gnumeric [ Colour Code : set unset ] [ Legend : (U) Col 1 - Current USE flags ] [ : (I) Col 2 - Installed With USE flags ] U I [ Found these USE variables in : app-office/gnumeric-1.2.0 ] - - libgda : Adds GNU Data Access (CORBA wrapper) support for gnumeric - - gnomedb : unknown + + python : Adds support/bindings for the Python language + + bonobo : Adds support for gnome-base/bonobo (Gnome CORBA interfaces) Init Script Runlevel Khởi động hệ thống Khi bạn khởi động hệ thống, bạn sẽ để ý thấy rất nhiều dòng chữ trôi qua. Nếu bạn để ý kỹ hơn, bạn sẽ thấy những dòng này đều giống nhau mỗi lần khởi động hệ thống. Chuỗi những hoạt động này được gọi là chuỗi khởi động (boot sequence) và được định nghĩa cố định. Trước hết boot loader của bạn sẽ nạp kernel image bạn định nghĩa trong phần cấu hình boot loader vào bộ nhớ. Sau đó nó yêu cầu CPU chạy kernel. Khi kernel được nạp và chạy, nó khởi động những cấu trúc và công việc đặc thù của kernel và khởi động tiến trình init. Tiến trình này bảo đảm mọi hệ tập tin (định nghĩa trong /etc/fstab) được mount vào hệ thống để có thể dùng. Sau đó nó thực hiện một số script nằm trong /etc/init.d, để khởi động các dịch vụ theo thứ tự, nhằm khởi động toàn bộ hệ thống. Cuối cùng, khi mọi script đã được thực hiện, init kích hoạt các terminal (trong hầu hết trước hợp, nó chỉ là virtual console, được kích hoạt bởi Alt-F1, Alt-F2, ...) và gắn mỗi terminal với một chương trình đặc biệt tên là agetty. Chương trình này sẽ bảo đảm bạn có thể đăng nhập vào những termminal này thông qua việc chạy login. Init Script Giờ init không đơn giản thực hiện các script trong /etc/init.d một cách ngẫu nhiên. Nó thậm chí không chạy mọi script trong /etc/init.d mà chỉ chạy những script được yêu cầu. Nó quyết định cần chạy những script nào bằng cách xem trong /etc/runlevels. Trước hết, init chạy mọi script trong /etc/init.d có symbolic link bên trong /etc/runlevels/boot. Thông thường các script sẽ được chạy theo thứ tự bảng chữ cái, nhưng vài script có các thông tin script phụ thuộc bên trong, báo cho hệ thống biết cần phải chạy những script nào khác trước khi script này được chạy. Khi mọi script trong /etc/runlevels/boot đã được chạy, init sẽ tiếp tục chạy các script có symbolic link trong /etc/runlevels/default. Tương tự như trên, các script sẽ được chạy theo thứ tự bảng chữ cái, trừ những script có thông tin phụ thuộc sẽ chạy những script phụ thuộc trước. Cách init hoạt động Dĩ nhiên init tự nó không quyết định tất cả. Nó cần tập tin cấu hình để cho biết những hành động nào cần thực hiện. Tập tin đó là /etc/inittab. Nếu bạn còn nhớ chuỗi khởi động đã được mô tả, bạn sẽ nhớ rằng hành động đầu tiên của init là mount mọi hệ tập tin. Điều này được định nghĩa bởi động sau trong /etc/inittab: si::sysinit:/sbin/rc sysinit Dòng này cho init biết rằng nó phải chạy /sbin/rc sysinit để khởi động hệ thống. Script /sbin/rc sẽ đảm trách tiến trình khởi động này, vì thế bạn có thể nói rằng init không thực hiện gì nhiều -- nó chỉ việc giao công việc khởi động hệ thống cho chương trình khác. init thực hiện mọi script có symbolic link trong /etc/runlevels/boot. Điều đó được mô tả bằng dòng sau: rc::bootwait:/sbin/rc boot Một lần nữa, script rc thực hiện những công việc cần thiết. Chú ý rằng tùy chọn cho rc (boot) là tên thư mục con trong /etc/runlevels cần dùng để khởi động. Giờ init kiểm tra tập tin cấu hình của nó để xem cần chạy runlevel nào kế tiếp. Để quyết định, nó đọc dòng sau từ /etc/inittab: id:3:initdefault: Trong trường hợp này (cũng là trường hợp được dùng nhiều nhất), runlevel là 3. Dùng thông tin này, init sẽ kiểm tra xem nó cần chạy những gì trong runlevel 3: l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot Dòng định nghĩa runlevel 3, một lần nữa lại dùng script rc để khởi động những dịch vụ (bây giờ lại dùng tham số default). Chú ý là tham số của rc cũng là tên thư mục con trong /etc/runlevels. Khi rc chạy xong, init quyết định cần kích hoạt những virtual console nào và những lệnh gì cần chạy trên mỗi console: c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux Runlevel Init dùng mô hình đánh số để quyết định runlevel nào cần kích hoạt. Runlevel là một trạng thái của hệ thống và chứa một tập các script (runlevel script hay initscript) cần được thực hiện để vào hoặc thoát một runlevel. Trong Gentoo, có vài bảy runlevel được định nghĩa: ba runlevel nội bộ, và bốn runlevel do người dùng định nghĩa. Những runlevel nội bộ là sysinit, shutdown và reboot và thực hiện chính xác như tên của chúng: khởi động hệ thống, tắt máy, khởi động lại máy. Những runlevel do người dùng định nghĩa là những cái đi kèm với thư mục con tương ứng trong /etc/runlevels: boot, default, nonetwork và single. Runlevel boot khởi động mọi dịch vụ cấp hệ thống mà những runlevel khác sử dụng. Ba runlevel còn lại khác nhau ở những dịch vụ được khởi động: default được dùng cho hoạt động hằng ngày, nonetwork được dùng trong trường hợp không cần mạng, và single được dùng khi bạn cần sửa chữa hệ thống. Sử dụng Init Script Các script được rc chạy gọi là init script. Mỗi script trong /etc/init.d có thể được chạy với tham số start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme hoặc broken. Để chạy, ngừng hoặc khởi động lại một dịch vụ (và mọi dịch vụ liên quan), hãy dùng start, stop và restart: # /etc/init.d/postfix start Nếu muốn ngừng một dịch vụ, nhưng không muốn ngừng những dịch vụ phụ thuộc vào nó, có thể dùng tham số pause: # /etc/init.d/postfix pause Nếu muốn xem trạng thái của một dịch vụ (đã chạy, đã dừng, đang tạm dừng ...) ta có thể dùng tham số status: # /etc/init.d/postfix status Để biết những dịch vụ phụ thuộc, có thể dùng tham số iuse hoặc ineed. Với ineed, có thể thấy những dịch vụ thật sự cần để dịch vụ đang xét hoạt động đúng. Ngược lại, iuse cho biết những dịch vụ có thể được dùng bởi dịch vụ này, nhưng không bắt buộc cần thiết. # /etc/init.d/postfix ineed Tương tự, có thể xem những dịch vụ nào cần dịch vụ này (needsme) hoặc dùng dịch vụ này (usesme): # /etc/init.d/postfix needsme Cuối cùng, bạn có thể xem các dịch vụ mà dịch vụ này cần nhưng thiếu: # /etc/init.d/postfix broken Sử dụng rc-update rc-update Hệ thống khởi động của Gentoo dùng một cây phụ thuộc để quyết định dịch vụ nào cần được khởi động trước. Vì đây là một công việc tẻ nhạt nên chúng tôi không muốn người dùng tự làm bằng tay, chúng tôi tạo ra những công cụ để làm dễ dàng việc quản lý runlevel và init script. Với rc-update, bạn có thể thêm vào và loại init script ra khỏi runlevel. rc-update sẽ tự động gọi depscan.sh để xây lại cây phụ thuộc. Thêm và xóa các dịch vụ Bạn đã thêm các init script vào runlevel "default" trong quá trình cài đặt Gentoo. Lúc đó có thể bạn không biết "default" là gì, nhưng bây giờ bạn đã biết. Script rc-update cần tham số định nghĩa hành động cần thực hiện: add, del hoặc show. Để thêm hoặc bỏ một init script, chỉ cần dùng tham số add hoặc del cho rc-update, theo sau là init script và runlevel. # rc-update del postfix default Lệnh rc-update show sẽ hiện mọi init script hiện có và những runlevel sử dụng nó: # rc-update show Cấu hình dịch vụ Cấu hình bổ sung Init script có thể khá phức tạp. Tuy nhiên việc người dùng hiệu chỉnh trực tiếp init script là không cần thiết, vì làm thế rất dễ gây ra lỗi. Tuy nhiên thực sự cần có cách cấu hình một dịch vụ. Ví dụ, muốn đưa nhiều tùy chọn hơn cho dịch vụ đó. Lý do thứ hai là để tách phần cấu hình ra khỏi init script là để có thể dễ dành cập nhật init script mà không sợ xóa mất phần cấu hình của hệ thống. Thư mục /etc/conf.d Gentoo cung cấp một cách dễ dàng để cấu hình một dịch vụ: mỗi init script cần được cấu hình sẽ có một tập tin trong /etc/conf.d. Ví dụ, initscript apache2 (tên là /etc/init.d/apache2) có tập tin cấu hình là /etc/conf.d/apache2, chứa các tùy chọn muốn đưa vào Apache 2 server khi khởi động: APACHE2_OPTS="-D PHP4" Tập tin cấu hình như thế chứa biến và chỉ biến (như /etc/make.conf), nên dễ dành cấu hình dịch vụ. Ngoài ra nó cũng giúp chúng tôi cung cấp nhiều thông tin hơn về các biến (thông qua phần ghi chú). Viết Init Script Viết init script thường là không cần thiết vì Gentoo cung cấp sẵn các init script để có thể dùng ngay cho từng dịch vụ. Tuy nhiên, có thể có một dịch vụ được cài đặt không dùng Portage, trong trường hợp này hầu như sẽ phải viết init script. Không dùng những init script đi kèm với các dịch vụ vì nó không được viết cho Gentoo: Gentoo init script không tương thích với init script được dùng bởi các bản phân phối khác! Bố cục Bố cục cơ bản của init script như bên dưới. #!/sbin/runscript depend() { (Thông tin phụ thuộc) } start() { (Những lệnh cần thiết để khởi động dịch vụ) } stop() { (Những lệnh cần thiết để dừng dịch vụ) } restart() { (Những lệnh cần thiết để khởi động lại dịch vụ) } Mọi init script phải định nghĩa hàm start(). Những phần khác là tùy chọn. Các phụ thuộc Có hai loại phụ thuộc bạn có thể định nghĩa: use và need. Như đã đề cập, phụ thuộc need chặt hơn so với phụ thuộc use. Theo sau loại phụ thuộc này là tên dịch vụ phụ thuộc, hoặc phụ thuộc virtual. Phụ thuộc virtual là phụ thuộc do một dịch vụ cung cấp, nhưng không phải chỉ có duy nhất một dịch vụ có thể cung cấp. Init script của hệ thống có thể phụ thuộc vào một system logger, nhưng có nhiều system logger (metalogd, syslog-ng, sysklogd ...). Vì bạn không thể need mọi system logger (không hệ thống nào cài đặt và chạy mọi system logger), gentoo bảo đảm rằng mọi dịch vụ loại này provide một phụ thuộc dạng virtual. Hãy xem thông tin phụ thuộc của postfix. depend() { need net use logger dns provide mta } Như vậy, dịch vụ postfix: cần phụ thuộc (virtual) net (cung cấp bởi, ví dụ, /etc/init.d/net.eth0) dùng phụ thuộc (virtual) logger (cung cấp bởi, ví dụ, /etc/init.d/syslog-ng) dùng phụ thuộc (virtual) dns (cung cấp bởi, ví dụ, /etc/init.d/named) cung cấp phụ thuộc (virtual) mta (dành cho mọi mail server) Điều khiển thứ tự Đôi khi không cần một dịch vụ, nhưng muốn một dịch vụ khởi động trước (hoặc sau) một dịch vụ khác nếu dịch vụ đó có trên hệ thống (chú ý phần điều kiện - không phải là thông tin phụ thuộc nữa) và chạy trong cùng runlevel (chú ý phần điều kiện - chỉ những dịch vụ trong cùng runlevel là có liên quan). Có thể cung cấp thông tin này bằng thiết lập before hoặc after. Ví dụ thiết lập của dịch vụ Portmap: depend() { need net before inetd before xinetd } Có thể dùng "*" để chọn mọi dịch vụ trong runlevel, mặc dù không nên làm như thế. depend() { before * } Hàm chuẩn Sau hàm depend(), cần định nghĩa hàm start(). Hàm này chứa mọi lệnh cần thiết để khởi động hệ thống. Nó được khuyên dùng hàm ebegin và eend để thông báo cho người dùng biết điều gì đang xảy ra: start() { ebegin "Starting my_service" start-stop-daemon --start --quiet --exec /path/to/my_service eend $? } Nếu cần nhiều hàm start() ví dụ hơn, vui lòng đọc mã nguồn của các init script trong /etc/init.d. Với start-stop-daemon, có một man page xuất sắc chưa nhiều thông tin hơn cho bạn: # man start-stop-daemon Những hàm khác có thể định nghĩa là: stop() và restart(). Ta không bị buộc phải định nghĩa những hàm này! Hệ thống khởi động đủ thông minh để tự điền những hàm này nếu dùng start-stop-daemon. Cú pháp init script của Gentoo dựa trên Bourne Again Shell (bash) vì thế có thể tự do dùng các khai báo của bash bên trong init script. Thêm tùy chọn riêng Nếu muốn init script của hỗ trợ nhiều tùy chọn hơn những cái đã thấy, ta nên thêm tùy chọn vào biến opts, và tạo một hàm cùng tên với tùy chọn. Ví dụ, để hỗ trợ tùy chọn restartdelay: opts="${opts} restartdelay" restartdelay() { stop sleep 3 # Chờ 3 giây trước khi khởi động lại start } Biến cấu hình tùy chọn Ta không phải làm bất cứ gì để hỗ trợ tập tin cấu hình trong /etc/conf.d: nếu init script được chạy, những dòng sau sẽ được gộp vào (thông qua lệnh source): /etc/conf.d/ /etc/conf.d/basic /etc/rc.conf Ngoài ra, nếu ta cung cấp phụ thuộc virtual (như net), tập tin đi kèm với phụ thuộc đó (như /etc/conf.d/net) cũng được gộp vào luôn. Thay đổi hành vi Runlevel Giả sử khi ở nhà người dùng muốn khởi động net.eth0 nhưng khi đi ra đường ta không muốn khởi động dịch vụ này vì không có kết nối mạng. Với Gentoo, ta có thể thay đổi hành vi runlevel . Ví dụ, bạn có thể tạo runlevel "default" thứ hai, dùng để khởi động những init script liên quan. Bạn có thể chọn default runlevel bạn muốn dùng lúc khởi động. Dùng softlevel Trước hết, tạo thư mục runlevel cho runlevel "default" thứ hai của bạn. Trong ví dụ này chúng ta tạo runlevel offline: # mkdir /etc/runlevels/offline Hãy thêm những init script cần thiết vào runlevel mới tạo. Ví dụ, nếu bạn muốn có một bản sao của runlevel default hiện thời nhưng không có net.eth0: (Chép mọi dịch vụ từ runlevel default vào runlevel offline) # cd /etc/runlevels/default # for service in *; do rc-update add $service offline; done (Loại bỏ các dịch vụ không muốn khỏi runlevel offline) # rc-update del net.eth0 offline (Hiển thị các dịch vụ được kích hoạt trong runlevel offline) # rc-update show offline (Một phần kết quả mẫu) acpid | offline domainname | offline local | offline net.eth0 | Giờ hãy sửa cấu hình boot loader và thêm một mục mới cho runlevel offline. Ví dụ, trong /boot/grub/grub.conf: title Gentoo Linux Offline Usage root (hd0,0) kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline Nếu khởi động hệ thống và chọn mục mới, runlevel offline sẽ được dùng thay vì default. Dùng bootlevel Dùng bootlevel hoàn toàn tương tự như softlevel. Khác biệt duy nhất là bạn định nghĩa một runlevel "boot" thứ hai thày vì runlevel "default" thứ hai. Biến môi trường Giới thiệu biến môi trường Biến môi trường là một đối tượng có tên, chứa thông tin được dùng bởi một hoặc nhiều ứng dụng. Nhiều người dùng (đặc biệt là những người mới làm quen với Linux) cảm thấy nó kỳ lạ và không thể quản lý được. Tuy nhiên, đó là một sai lầm: bằng cách dùng biến môi trường, bạn có thể thay đổi thiết lập cấu hình cho một hoặc nhiều ứng dụng. Ví dụ quan trọng Bảng sau liệt kê một số biến được dùng bởi hệ thống Linux và mô tả công dụng của chúng. Những giá trị ví dụ được trình bày bên dưới bảng. Biến Mô tả PATH Biến này chứa danh sách các thư mục, cách nhau bởi dấu hai chấm. Đó là danh sách các thư mục hệ thống sẽ kiểm tra để tìm các tập tin thực thi. ROOTPATH Biến này tương tự như PATH nhưng chỉ liệt kê danh sách những thư mục cần tìm khi người dùng root gọi lệnh. LDPATH Biến này chứa danh sách các thư mục cánh nhau bằng dấu hai chấm, được dùng bởi dynamic linker để tìm các thư viện. MANPATH Biến này chứa danh sách các thư mục cách nhau bằng dấu hai chấm, được dùng bởi man để tìm man page. INFODIR Biến này chứa danh sách các thư mục cách nhau bằng dấu hai chấm, được dùng bởi info để tìm info page. PAGER Biến này chứa đường dẫn chương trình được dùng để xem nội dung tập tin (như less hoặc more). EDITOR Biến này chứa đường dẫn chương trình dùng để thay đổi nội dung tập tin (như nano hoặc vi). KDEDIRS Biến này chứa danh sách các thư mục cách nhau bằng dấu hai chấm, chứa các thông tin đặc trưng của KDE. CLASSPATH Biến này chứa danh sách các thư mục chứa các lớp Java, cách nhau bằng dấu hai chấm. CONFIG_PROTECT Biến này chứa danh sách các thư mục cách nhau bằng khoảng trắng, là danh sách các thư mục cần được Portage bảo vệ tránh bị ghi đè khi cập nhật. CONFIG_PROTECT_MASK Biến này chứa danh sách các thư mục cách nhau bằng khoảng trắng, là danh sách các thư mục không được Portage bảo vệ tránh bị ghi đè khi cập nhật. Bảng 3.1 Danh sách biến môi trường Bên dưới là ví dụ định nghĩa các biến trên: PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin" ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin" LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" MANPATH="/usr/share/man:/usr/local/share/man" INFODIR="/usr/share/info:/usr/local/share/info" PAGER="/usr/bin/less" EDITOR="/usr/bin/vim" KDEDIRS="/usr" CLASSPATH="/opt/blackdown-jre-1.4.1/lib/rt.jar:." CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \ /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf Biến toàn cục Thư mục /etc/env.d Để tập trung các định nghĩa biến, Gentoo giới thiệu thư mục /etc/env.d. Bên trong thư mục này, ta sẽ thấy các tập tin như 00basic, 05gcc, ... chứa các biến được dùng bởi ứng dụng được đề cập bên trên. Ví dụ, khi cài đặt gcc, tập tin tên 05gcc được tạo bởi ebuild gcc, chứa định nghĩa các biến sau: PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" Các bản phân phối khác yêu cầu bạn thay đổi biến trong /etc/profile hoặc ở nơi khác. Ngược lại, Gentoo làm mọi việc dễ dàng hơn cho bạn (và cho cả Portage) khi quản lý các biến môi trường mà không cần quan tâm đến vô số tập tin có thể chứa biến môi trường. Ví dụ, khi cập nhật gcc, tập tin /etc/env.d/05gcc được cập nhật mà không cần bất kỳ sự can thiệp nào của người dùng. Đây không chỉ làm lợi cho Portage mà còn cho cả người sử dụng. Đôi khi người dùng được yêu cầu đặt một số biến toàn cục. Trong ví dụ sau, chúng tôi đặt biến http_proxy. Thay vì làm rối tung lên tập tin /etc/profile, bạn có thể chỉ cần tạo tập tin (/etc/env.d/99local) và nhập các định nghĩa của ta vào: http_proxy="proxy.server.com:8080" Bằng cách dùng cùng một tập tin cho mọi định nghĩa biến, ta có thể có cái nhìn tổng quát về những gì bạn tự định nghĩa. Chương trình env-update Một vài tập tin trong /etc/env.d định nghĩa biến PATH. Đó không phải là lỗi: khi bạn chạy env-update, nó sẽ nối tất cả các định nghĩa này lại với nhau trước khi cập nhật biến môi trường của bạn, nhờ đó làm cho việc thêm các biến môi trường riêng khi đóng gói (hoặc tự bạn thêm) dễ dàng hơn mà lại không tác động các giá trị đã có. Script env-update sẽ nối các giá trị của các tập tin lại theo thứ tự bảng chữ cái tên các tập tin /etc/env.d. Đó là lý do tại sao các tập tin /etc/env.d bắt đầu bằng hai chữ số thập phân. 00basic 99kde-env 99local +-------------+----------------+-------------+ PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin" Việc nối các biến không phải luôn xảy ra, chỉ xảy ra với những biến sau: KDEDIRS, PATH, CLASSPATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT , CONFIG_PROTECT_MASK, PRELINK_PATH và PRELINK_PATH_MASK. Với các biến khác, giá trị mới nhất (theo thứ tự bảng chữ cái tên tập tin trong /etc/env.d) sẽ được dùng. Khi chạy env-update, script này sẽ tạo mọi biến môi trường và đặt vào /etc/profile.env (được dùng bởi /etc/profile). Nó cũng rút trích các thông tin từ biến LDPATH và tạo /etc/ld.so.conf. Sau đó, nó sẽ gọi ldconfig để tạo lại tập tin /etc/ld.so.cache, được dùng bởi dynamic linker. Nếu muốn thấy tác động của env-update tức thì, sau khi chạy nó, hãy thực hiện lệnh sau để cập nhật lại biến môi trường. Nhưng người dùng tự cài đặt Gentoo có lẽ sẽ nhớ ra lệnh này trong các chỉ dẫn cài đặt: # env-update && source /etc/profile Biến cục bộ User Specific Không phải ta luôn muốn định nghĩa biến môi trường cho toàn hệ thống. Ví dụ, có thể muốn thêm /home/my_user/bin và thư mục hiện thời (thư mục đang đứng) vào biến PATH nhưng không muốn những người khác trên hệ thống cũng có y như vậy. Nếu bạn muốn định nghĩa biến môi trường nội bộ, nên dùng ~/.bashrc hoặc ~/.bash_profile: (Dấu hai chấm theo sau không có thư mục nào có nghĩa là thư mục hiện thời) PATH="${PATH}:/home/my_user/bin:" Khi login lần sau, biến PATH sẽ được cập nhật. Đặc trưng cho phiên làm việc Đôi khi cần có những định nghĩa biến chặt hơn. Có thể muốn dùng những chương trình từ một thư mục tạm mà người dùng tạo mà không cần gõ đường dẫn đến chương trình đó cũng như không sửa ~/.bashrc vì ta chỉ cần nó trong một lúc. Trong trường hợp này, ta có thể định nghĩa biến PATH trong quá trình làm việc bằng cách dùng lệnh export. Chừng nào chưa log out thì biến PATH sẽ vẫn còn nguyên như mong muốn. # export PATH="${PATH}:/home/my_user/tmp/usr/bin" CHƯƠNG 4 . BIÊN DỊCH CHÉO Giới thiệu biên dịch chéo cho Linux Chương trình biên dịch là một chương trình cho phép tạo ra mã thực thi từ mã nguồn. Giống như các chương trình khác , một chương trình biên dịch chạy trên một loại máy tính cụ thể, và các chương trình mới do nó sinh ra cũng chạy trên một loại máy tính cụ thể. Máy tính mà cài chương trình biên dịch gọi là HOST, còn máy tính mà chương trình mới sau khi được tạo ra chạy trên nó gọi là TARGET. Khi mà HOST và TARGET cùng là một máy tính thì trình biên dịch gọi là đó gọi là biên dịch thuần túy. Khi HOST và TARGET khác nhau thì bộ biên dịch đó gọi là bộ biên dịch chéo. Vậy tại sao phải biên dịch chéo? Lý do để các nhà nghiên cứu xây dựng và phát triển các bộ biên dịch chéo do 5 nguyên nhân cơ bản: + Tốc độ: Tốc độ của máy tính đích Target chậm hơn rất nhiều so với Hosts. Hầu hết các phần cứng hệ nhúng đều có mục đích đặc biệt là được thiết kế cho giá thành rẻ, tiêu tốn ít năng lượng và hiệu quả cao. + Dung lượng: Việc biên dịch rất nhạy cảm với tài nguyên. Nền tảng của máy target thường không đến vài Gigabyte bộ nhớ hoặc vài trăm Gigabyte không gian nhớ vật lý giống máy tính để bàn. Do vậy nó thừa tài nguyên để biên dịch các chương trình cỡ “Hello world” nhưng với các chương trình lớn thì điều này là ngoài khả năng của nó. + Tính sẵn sàng ( có giá trị): Việc mang cả bản Linux vào nền tảng phần cứng không bao giờ chạy trước khi yêu cầu một bộ biên dịch chéo. Thậm chí cả những platform ổn định lâu dài như MIPs hay Arm, việc tìm kiếm một môi trường cập nhật cho các target có thể rất khó. Nếu platform không được khách hàng yêu cầu nhiều thì việc cập nhật là rất khó. Nếu bạn có một bản phân phối linux cho riêng target trước khi bạn có thể xây dựng cho target, bạn quay trở lại dùng cross-compile bằng bất cứ cách nào. + Linh động: Một bản phân phối linux đầy đủ có hàng trăm packages, nhưng môi trường cross-compile có thể phụ thuộc vào bản phân phối của host để chọn ra những thứ thật sự cần thiết. Mục tiêu của cross compile là xây dựng các gói để phát triển, không sử dụng các gói chỉ dành riêng cho hệ thống của target. + Thuận tiện: Giao diện người dùng ngày càng được chú trọng và làm cho đẹp mắt. Việc cài đặt từ đĩa CD vào một cái máy mà không có ổ đĩa CD thật khó khăn. Việc reboot giữa môi trường phát triển và môi trường test rất mất thời gian. Cross compile giúp bạn giải quyết được điều đó. Các phương pháp biên dịch chéo Phương pháp tạo môi trường phát triển: Theo lý thuyết, 1 máy tính người dùng muốn xây dựng một chương trình cho một vài thiết bị khác thì nó phải có cấu hình máy tương tự với thiết bị đó, một bộ phân phối Linux tương tự, và một trình biên dịch với môi trường tương tự (Hình 4.1). Hình 4.1 Quá trình biên dịch chéo bằng phương pháp tạo môi trường phát triển Phương pháp biên dịch phân tán Đây là phương pháp tiếp cận kiểu mới. Với phương pháp này, máy HOST không cần phải có cấu hình phần cứng cũng như hệ điều hành giống với máy TARGET. Với phương pháp này, ta có thể nhờ nhiều máy HOST có các cấu trúc phần cứng cũng như hệ điều hành khác nhau mà cùng sử dụng chung một mạng LAN với máy TARGET để biên dịch chéo cho máy TARGET (Hình 4.2). Như vậy thời gian biên dịch sẽ giảm một cách đáng kể tùy thuộc vào số lượng của các HOST. Hình 4.2 Quá trình biên dịch chéo bằng phương pháp phân tán Tìm hiểu về biên dịch chéo Các bước của quá trình biên dịch chéo Qúa trình biên dịch và chạy một chương trình biên dịch chéo gồm một vài bước sau: + Chạy chương trình biên dịch chéo trên máy HOST để sinh ra các tập tin lắp ráp cho máy TARGET. Điều này đòi hỏi các tập tin tiêu đề cho máy TARGET. + Ghép khối các tập tin được sinh ra bởi trình biên dịch chéo. Điều này có thể thực hiện được với bộ ghép nối trên máy TARGET, hoặc với bộ ghép nối chéo trên máy HOST. + Liên kết các tập tin để tạo ra chương trình có khả năng thực thi. Điều này có thể làm được với bộ liên kết trên máy TARGET, hoặc với bộ liên kết chéo trên máy HOST. Với bất kỳ máy tính nào, ta cần phải có các thư viện và các tập tin khởi động chính ( điển hình là `crt….o’) cho máy TARGET. Tiện lợi nhất để làm tất cả những bước này trên cùng một máy HOST, kể từ đó ta có thể làm tất cả với trình biên dịch GNU CC. Điều này yêu cầu phải có các bộ lắp ráp chéo và liên kết chéo phù hợp. Đã có những bộ lắp ráp và liên kết của GNU có thể áp dụng cho một vài máy TARGET. Cấu hình một trình biên dịch chéo Để xây dựng GNU CC như một trình biên dịch chéo, ta chạy lệnh `configure’. Sử dụng `--target=TARGET’ để mô tả kiểu kiến trúc phần cứng của máy TARGET. Nếu `configure’ không có khả năng để xác định đúng hệ thống mà ta đang chạy, cũng có thể mô tả bằng tùy chọn `--build=BUILD’. Ví dụ, để cấu hình cho mộ trình biên dịch chéo mà nó sinh ra mã cho hệ thống HP 68030 chỵ BSD trên một hệ thống mà `configure’ có thể xác định một cách chính xác: ./configure –target=m68k-hp-bsd4.3 Công cụ và thư viện cho một trình biên dịch chéo Trước hết ta phải cài đặt 2 bộ công cụ là cross-assembler và cross-linker. Đưa chúng vào thư mục ` /usr/local/TARGET/bin’. Dưới đây là bảng công cụ mà ta nên đưa chúng vào thư mục trên: + `as’ : Nên là cross-assembler. + `ld’ : Nên là cross-linker. + `ar’ : Nên là cross-archiver: là chương trình có thể thao tác các tập tin lưu trữ ( các thư viện liên kết) trong định dạng của máy TARGET. + `ranlib’ : Nên là chương trình để xây dựng một bảng ký tự cho các tập tin lưu trữ. Quá trình cài đặt của GNU CC sẽ tìm ra các chương trình đó trong thư mục ` /usr/local/TARGET/bin’, và sao chép hoặc liên kết chúng vào đúng chỗ để trình biên dịch chéo có thể tìm thấy chúng khi nó chạy. Cách đơn giản nhất để cung cấp những tập tin này là tạo ra gói Binutils và GAS. Cấu hình chúng với tùy chọn ‘—host’ và ‘—target’ giống nhau để sử dụng cho việc cấu hình GNU CC, sau đó xây dựng và cài đặt chúng. Các tập tin có khả năng thực thi được cài đặt vào đúng thư mục. Tuy nhiên chúng không hỗ trợ tát cả các kiến trúc của máy TARGET mà GNU CC hỗ trợ. Nếu muốn cài đặt thư viện để sử dụng với trình biên dịch chéo, ví dụ bộ thư viện C chuẩn, đưa chúng vào thư mục ‘/usr/local/TARGET/lib’; quá trình cài đặt của GNU CC sẽ sao chép tất cả các tập tin trong thư mục con vào trong đúng thư mục để cho GNU CC có thể tìm thấy chúng và liên kết với chúng. Dưới đây là một ví dụ cụ thể ( sao chép một vài thư viện từ máy target): ftp TARGET-MACHINE lcd /usr/local/TARGET/lib cd /lib get libc.a cd /usr/lib get libg.a get libm.a quit Ta cần phải thiết lập chính xác các thư viện và vị trí của nó trong máy target, thay đổi tùy thuộc vào các hệ điều hành. Nhiều máy target yêu cầu “các tập tin khởi động” như là ‘crt0.o’ và ‘crtn.o’. Các tập tin này được liên kết với mỗi tập tin có thể thực thi; nó cũng được đặt tại thư mục ‘ /usr/local/TARGET/lib’. Có thể có một vài lựa chọn thay thế cho ‘crt0.o, để sử dụng với các lựa chọn biên dịch định hình hoặc các lựa chọn khác. Kiểm tra sự định nghĩa của ‘STARTFILE_SPEC’ của máy target để tìm ra các tập tin bắt đầu được sử dụng. Dưới đây là ví dụ sao lưu những tập tin từ máy target: ftp TARGET-MACHINE lcd /usr/local/TARGET/lib prompt cd /lib mget *crt*.o cd /usr/lib mget *crt*.o quit Các tập tin tiêu đề Nếu trình biên dịch chéo là một chương trình độc lập hoặc là một chương trình dành cho hệ thống nhúng, ta không cần bất kỳ tập tin tiêu đề nào ngoại trừ một vài tập tin là một phần của GNU CC ( và những chương trình dành cho các ứng dụng khác). Tuy nhiên nếu ta liên kết chương trình khác với thư viện C chuẩn như ‘libc.a’, thì ta có thể cần để biên dịch với các tập tin tiêu đề đi cùng với thư viện mà ta sử dụng. Trình biên dịch GNU C không đi kèm với những tập tin này vì chúng là một hệ thống đặc biệt và chúng thộc về thư viện C, không nằm trong trình biên dịch. Nếu máy target đi kèm với trình biên dịch C, nó có lẽ cũng đi kèm với một vài tập tin tiều đề tương thích. Nếu ta tạo ra các tập tin có khả năng truy cập từ máy host, trình biên dịch chéo cũng có thể sử dụng chúng. Cách khác, khi biên dịch chéo ta có thể tìm kiếm các tập tin tiêu đề. Khi ta có các tập tin tiêu đề phù hợp, đặt chúng vào trong thư mục ‘ /usr/local/TARGET/include’ , trước khi xấy dựng nên trình biên dịch chéo. Sau đó, quá trình cài đặt sẽ chạy các trình sửa lỗi và cài đặt đúng các phiên bản của các tập tin tiêu đề vào nơi mà trình biên dịch chéo sẽ sử dụng chúng. Cung cấp các tập tin tiêu đề trước khi xây dựng trình biên dịch chéo vì tầng xây dựng chạy trình biên dịch chéo để sinh ra các phần của ‘libgcc.a’. (Những phần này *có thể* được biên dịch với GNU CC.)Một vài trong số chúng cần các tập tin tiêu đề phù hợp. Dưới đây là ví dụ chỉ ra cách để sao chép các tập tin tiêu đề từ một máy target. Trong máy target, thực hiện lệnh sau: (cd /usr/include; tả cf - .) > tarfile Sau đó, trên máy host, chạy những lệnh sau: ftp TARGET-MACHINE lcd /usr/local/TARGET/include get tarfile quit tar xf tarfile Thời gian thi hành Mã được biên dịch bởi GNU CC sử dụng thời gian thi hành chính hỗ trợ hoàn toàn các chức năng. Một vài trong số các chức năng này có thể được biên dịch thành công với chính bản thân GNU CC, nhưng một số khác lại không thể làm được điều này. Các hàm có vấn đề này nằm trong tập tin nguồn ‘libgcc1.c’; Thư viện được tạo ra từ việc gọi tập tin ‘libgcc1.a’. Khi ta xây dựng một chương trình biên dịch thuần túy, những hàm chức năng được được biên dịch với một vài trình biên dịch. Tất nhiên là không thể thiếu GNU CC. Có lẽ nó biết làm thế nào để mở mã những hoạt động, hoặc biết cách gọi các phương tiện mô phỏng thời gian thi hành mà máy tính đi kèm. Nhưng cách tiếp cận này không được sử dụng để xây dựng một trình biên dịch chéo.Trình biên dịch chéo mà ta xây dựng chỉ biết về hệ thống host chứ không biết về target. Vì thế khi xây dựng trình biên dịch chéo ta phải cung cấp các thư viện tương thích như ‘libgcc1.a’ . Để biên dịch ‘libgcc1.c’ với trình biên dịch chéo ( bản thân máy tính đó sẽ không thực hiện chức năng biên dịch này). Những hàm chức năng ở trong các tập tin này được cung cấp để cài đặt các thuật toán làm việc mà GNU CC không biết cách nào để mở mã cho máy tính target. Những hàm chức năng này được biên dịch bới chính GNU CC trong máy tính đó, chúng sẽ biên dịch vào trong sự đệ quy vô hạn. Hầu hết các chức năng này không cần thiết trong bất kỳ máy target. Nếu GNU CC có thể mở mã một thuật toán, nó sẽ không gọi các hàm chức năng để thực hiện các hoạt động này.Có thể trên máy tính target, không hàm nào được sử dụng. Nếu vì thế ta có thể cung cấp một thư viện rỗng như ‘libgcc1.a’. Rất nhiều máy target cầ thư viện để hỗ trợ cho sự nhân và chia.Nếu ta liên kết tới một thư viện chứa các hàm chức năng cho sự nhân và chia thì ta có thể gọi GNU CC để gọi chúng một cách trực tiếp nhờ định nghĩa macro ‘MULSI3_LIBCALL’, và những macro ưa thích khác. Những macro này caafmn phải được định nghĩa trong các tập tin macro trên máy target. Trên một vài target, chúng đã được định nghĩa sẵn. Điều này có đủ khả năng để tránh cần libgcc1.a; nếu vì thế, ta có thể hỗ trợ một thư viện rỗng. Một vài target không có cấu trúc dấu phẩy động; chúng cần các chức năng khác trong thư viện ‘libgcc1.a’ là thư viện hỗ trợ tính toán dấu phẩy động. Một vài phiên bản GNU CC gần đây có một tập tin mô phỏng dấu phẩy động. Với một số lượng làm việc nhất định ta có đủ khả năng để xây dựng một bộ mô phỏng dấu phẩy động sử dụng như ‘libgcc1.a’. Có lẽ phiên bản trong tương lai sẽ có mã để thực hiện một cách tự động và thuận tiện. Điều đó phụ thuộc vào việc ai đó muốn thực hiện điều đó. Một vài máy tính nhúng đi kèm với tất cả thư viện ‘libgcc1.a’ cần thiết được viết bằng C hoặc asembler. Những máy tính này xây dựng ‘libgcc1.a’ một cách tự động và ta không cần phải làm bất kỳ thứ gì đặc biệt cho nó. Các máy tính nhúng khác lại không cần bất kỳ thư viện ‘libgcc1.a’ kể từ khi tất cả các hoạt động cần thiết được hỗ trợ bởi phần cứng. Nếu hệ thống máy tính của ta có một trình biên dịch C khác, ta có thể cấu hình GNU CC như trình biên dịch thuần túy trên máy đó, xây dựng ‘libgcc1.a’ với câu lệnh ‘make libgcc1.a’ trên máy tính đó, và sử dụng tập tin kết quả với trình biên dịch chéo. Để làm được điều này, hãy thực hiện các bước dưới đây trên máy tinh target. Cd TARGET-BUILD-DIR ./configure –host=sparc –target=sun3 Make libgcc1.a Và sau đó thực hiện điều này trên máy host: ftp TARGET-MACHINE binary cd TARGET-BUILD-DIR get libgcc1.a quit Cách khác để cung cấp chức năng ta cần trong ‘libgcc1.a’ là để định nghĩa chính xác macro ‘perform..’ cho các chức năng. Nếu những sự định nghĩa này không sử dụng thuật toán C mà chúng cài đặt, ta nên biên dịch với trình biên dịch chéo đang xây dựng. ( Nếu các định nghĩa đã tồn tại sẵn trên các tập tin target, sau đó thiết lập chúng). Để sử dụng macro để xây dựng ‘libgcc1.a’ , sử dụng ‘LIBGCC1=libgcc1.a OLDCC=./xgcc’ khi xây dựng trình biên dịch. Các khác. Ta đặt thư viện thay thế dưới tên ‘libgcc1.a’ trong thư mục mà ta sẽ xây dựng trình biên dịch chéo trước khi chạy lệnh ‘make’. Xây dựng chéo Bây giờ ta có thể thực hiện cũng như biên dịch trên một máy qua các bước ở giai đoạn 1. Nếu ta không cung cấp một số loại ‘libgcc1.a’ sau đó sự biên dịch sẽ cung cấp nơi mà nó cần các tập tin, việc in ấn một thông điệp lỗi phù hợp. Nếu ta cung cấp ‘libgcc1.a’, sau khi xây dựng trình biên dịch sẽ tự động biên dịch và liên kết một chương trình chạy thử gọi là ‘libgcc1-test’; nếu ta cần biết lỗi trong quá trình liên kết, có nghĩa là không phải tất cả các thói quen cần thiết trong ‘libgcc1.a’ là có sẵn. Ta nên cung cấp tập tin tiêu đề ‘float.h’. Một cách để thực hiện điều đó là để biên dịch ‘hỏi thăm’ là chạy trên máy target và mô tả bởi sự diễn tả dấu phẩy động. Hồ sơ ‘hỏi thăm’được tìm thấy trong tập tin tiêu đề ‘float.h’. Nếu ta không thể sinh ra tập tin này bằng cách chạy ‘hỏi thăm’ trên máy target, sau đó sẽ cần thiết để đi tới với tập tin ‘float.h’ thích hợp trong một vài cách khác ( tránh sử dụng nó trong chương trình của bạn). Không thử xây dựng ở tầng thứ 2 cho một trình biên dịch chéo. Nó không làm việc để tái xây dựng GNU CC như một trình biên dịch chéo vì điều này sẽ sinh ra một chương trình chạy trên máy target, không phải trên máy host. Cho ví dụ, nếu ta biên dịch một trình biên dịch 386-tới-6803 , kết quả sẽ không chính xác cho 386 ( vì nó chỉ được biên dịch trong 6803) hoặc cho 6803 ( vì nó được cấu hình cho 386 như host). Nếu ta muốn biên dịch GNU CC vào trong mã 6803, khi nào ta muốn biên dịch nó trên 6803 hoặc với trình biên dịch chéo trên 386, ta phải chỉ ra một 68030 như một host khi ta cấu hình nó. Để cài đặt một trình biên dịch chéo, sử dụng lệnh ‘make install’. DISTCC Giới thiệu về DISTCC Distcc là một chương trình dùng để phân chia việc biên soạn (compiling) chương trình/phần mềm từ một máy qua nhiều máy khác nhau. Tất cả các máy có thể chạy các hệ điều hành khác nhau (dĩ nhiên bạn sẽ vất vả hơn vì phải cài bộ gcc với chức năng cross-compiling trên mỗi máy). Cái quan trọng nhất khi dùng distcc là nên sử dụng phiên bản gcc giống nhau trên cùng hệ điều hành vì một vài chương trình viết bằng C++ sẽ gặp vấn đề nếu bạn dùng phiên bản gcc khác nhau trên mỗi máy. Điều quan trọng thứ nhì đó là distcc không phải là một chương trình biên soạn (compiler). Distcc không yêu cầu tất cả các máy phải chia sẻ filesystem, nó có đồng hồ đồng bộ hoặc có một vài thư viện hoặc các file header được cài đặt. Chúng có thể thực hiện trên các máy có vi xử lý hoặc hệ điều hành khác nhau, nếu mà cross-compiler đã được cài đặt. Tất cả các máy tham gia cross-compiler đều phải cài chạy distcc các máy đó được gọi là host (server) còn máy mà chạy chương trình sau khi biên dịch ra file nhị phân là client (hay target). Cài đặt và cấu hình Distcc Distcc trên Gentoo Cài đặt Cài đặt distcc từ mạng internet trên gentoo ta sử dụng lệnh: $ emerge distcc Cấu hình Sau khi cài đặt xong, đưa distcc vào chạy mặc định với lệnh: #rc-update add distccd default Chạy distccd #/etc/init.d/disccd start Chỉnh sửa trong file cấu hình distccd #vi /etc/conf.d/distccd DISTCCD_OPTS="${DISTCCD_OPTS} --allow 192.168.7.2/24" Tiếp đó thiết lập hosts bằng lệnh #distcc-config --set-hosts "192.168.7.131 192.168.7.100” Tiếp đó sửa file make.conf #vi /etc/make.conf FEATURES="distcc" MAKEOPTS="-jN" Thêm biến môi trường: #export PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:${PATH}" Để theo dõi quá trình Cross compile ta sử dụng công cụ distccmon-text hoặc distccmon-gui: #distccmon-text N Hoặc #distccmon-gui Distcc trên Ubuntu Cài đặt Cài đặt distcc từ mạng internet trên ubuntu ta sử dụng lệnh: Cấu hình Cấu hình lại file /etc/default/distcc $sudo vim /etc/default/distcc STARTDISTCC="true"ALLOWEDNETS="192.168.7.2/24" Chạy tiện ích distcc bằng lệnh $sudo distccd –allow “192.168.7.131” CHƯƠNG 5. TRIỂN KHAI DỰ ÁN VÀ KẾT QUẢ Triển khai dự án Thiết lập mode Ad-hoc trên fit-pc. Quá trình thiết lập mode ad-hoc cho fit-pc trải qua những bước sau (Hình 5.1). B1. Cấu hình với Gentoo kernel 2.6.25 r7 Thiết lập với wireless tools nhưng thất bại. Thiết lập với WPA cũng không thành công. Sau khi nghiên cứu trên mạng, em được biết Gentoo không hỗ trợ cấu hình mode Ad-hoc trên Gentoo kernel 2.6.25 r7. B2. Upgrade kernel lên Gentoo 2.6.27 r8 (Hình 5.2 + Hình 5.3). B3. Cài đặt driver ralink cho card mạng không dây của fit-pc. B4. Thiết lập mạng Ad-hoc (Hình 5.4 + Hình 5.5). Kết luận: Như vậy đã thiết lập được mạng Ad-hoc trên fit-pc Hình 5.1 Quá trình thiết lập mạng không dây mode Ad-hoc cho fit-pc Hình 5.2 Cấu hình kernel Hình 5.3 Lưu file cấu hình kernel Hình 5.4 Cấu hình mạng Ad-hoc trên fit-pc Hình 5.5 Mạng Ad-hoc đã thiết lập thành công Cross compile cho fit-pc. Vì tài nguyên của fit-pc tương đối hạn hẹp nên việc biên dịch các dự án lớn trên fit-pc mất rất nhiều thời gian (đặc biệt là khi biên dịch nhân – mất 8 tiếng). Ta sẽ sử dụng một máy cài hệ điều hành ubuntu để thực hiện việc biên dịch cùng với fit-pc. Để thực hiện được việc này, ta sử dụng công cụ DISTCC và tiến hành các bước sau: B1. Cấu hình distcc trên fit-pc ( địa chỉ IP là: 192.168.1.131 ) Hình 5.6 Cấu hình file /etc/conf.d/distccd trên fit-pc (gentoo) Hình 5.7 Cấu hình file /etc/make.conf trên fit-pc (gentoo). B2. Cấu hình distcc trên ubuntu ( địa chỉ IP là: 192.168.1.91) Hình 5.8 Địa chỉ mạng của máy host (ubuntu). Hình 5.9 Cấu hình file /etc/default/distcc trên host (ubuntu). Hình 5.10 Khởi động daemon distccd trên host (ubuntu). B3. Thực hiện cross compile với dự án distcc-2.18.3 trên fit-pc: Sử dụng distcc để biên dịch dự án distcc-2.18.3 trên fit-pc. Sau khi vào thư mục distcc-2.18.3 trên fit-pc, ta sử dụng lệnh ./configure để cấu hình dự án. Sau đó sử dụng lệnh make –j8 CC=distcc để biên dịch. Dùng công cụ distccmon-gui để theo dõi quá trình biên dịch dự án bằng distcc (Hình 5.11) . Trong đó: Màu xanh lá cây: dữ liệu đang biên dịch (compile). Màu tím: dữ liệu chờ để xử lý (preprocess). Màu vàng: gửi dữ liệu (send). Màu xanh dương: nhận dữ liệu (receive). Màu đỏ: bị chặn (block). Hình 5.11 Quá trình biên dịch chéo sử dụng Distcc Để đo thời gian thực hiện dự án ta thêm lệnh time vào trước lệnh make –j8 CC=distcc (time make –j8 CC=distcc). Kết quả sau khi thực hiện biên dịch chéo với công cụ distcc (Hình 5.12). Thời gian thực hiện quá trình biên dịch này là 0m27 .891s (real 0m27 .891s). Thời gian user thực hiện là 0m13 .110s (user 0m13 .110s). Thời gian hệ thống phải làm việc là 0m2 .620s (sys 0m2 .620s). Hình 5.12 Kết quả biên dịch chéo sử dụng Distcc Triển khai dự án truyền video trên mạng Ad-hoc. Giới thiệu dự án: Sự phát triển kỹ thuật phần cứng và phần mềm cho phép sử dụng các hệ nhúng nhỏ gọn , rẻ tiền vào rất nhiều lĩnh vực, cung cấp phương tiện thông tin mọi nơi, mọi lúc (any time, anywhere connectivity). Kết nối mạng không dây cho phép chúng truyền và xử lý tín hiệu multimedia vào các ứng dụng phi truyền thống, không gắn với máy tính PC nối mạng Internet. Các hệ nhúng này có thể mang trên người (wearable computer), các đối tượng di chuyển (xe cộ, tàu thuyền) hoặc đặt cố định ở hiện trường (địa điểm công cộng) giúp truyền video có tương tác hoặc giám sát thời gian thực. Em đã nghiên cứu, thiết kế, tích hợp và phát triển phần cứng , phần mềm cho hệ nhúng FIT-PCcho phép truyền video trên mạng WLAN cũng như mạng di động không có cơ sở hạ tầng thiết lập trước (ad-hoc network ). Hệ thống cho phép người dùng thay đổi tham số video một cách dễ dàng cũng như tự thích ứng với điều kiện đường truyền. Ngoài ra, video được nhúng vào giao diện web tiếng Việt rất thân thiện với người dùng Việt Nam. Hệ thống có thể được đem ứng dụng vào giám sát bằng video thời gian thực ở các địa điểm công cộng đông người, tòa nhà cao tầng, nhà riêng… Mốt truyền ad hoc có thể hỗ trợ tốt các tình huống khẩn cấp không có cơ sở hạ tầng thông tin tiền định. Hệ nhúng kích thước nhỏ, tiêu hao ít năng lượng rất thích hợp cho các ứng dụng di động. Sản phẩm cũng hỗ trợ tốt việc nghiên cứu truyền video trên mạng không dây phi truyền thống. Mô hình dự án (Hình 5.13): Dự án gồm: + Armadillo 300 được gắn webcam + fit-pc làm nút trung gian. + 3 máy laptop có chương trình web browser để hiển thị video Fit-pc kết nối với Armadillo qua 1 hop. Web Browser 1 kêt nối với Armadillo 300 qua 1 hop. Web Browser 2 kêt nối với Armadillo 300 qua 2 hop (nút trung gian là fit-pc). Web Browser 3 kết nối với Armadillo 300 qua 3 hop ( 2 nút trung gian là fit-pc và Web Browser 2). Hệ thống được định tuyến bởi giao thức OLSR. Hình 5.13 Mô hình dự án truyền video qua mạng Ad-hoc Tiến trình thực hiện dự án (Hình 5.15): Quá trình thực hiện dự án trải qua những bước cơ bản sau: B1. Nghiên cứu về hệ nhúng và mạng Ad-hoc. Trong bước này em đã nghiên cứu cơ bản về mạng Ad-hoc, ưu nhược điểm của mạng Ad-hoc, định tuyến trên mạng Ad-hoc. Cùng với đó em cũng nghiên cứu về hệ nhúng, vấn đề tài nguyên , năng lượng của hệ nhúng, thiết lập mạng Ad-hoc trên hệ nhúng. B2. Để có thể quan sát được hình ảnh từ hiện trường, hệ thống cần tích hợp webcam để bắt giữ tín hiệu video. Nhưng vấn đề khó khăn xảy ra là phải triển khai được driver cho webcam trên hệ nhúng. B3. Tiếp theo là phải thiết lập được mạng không dây mode Ad-hoc trên hệ nhúng (Hình 5.14). Vấn đề khó khăn ở đây là phải triển khai được driver hỗ trợ thiết lập mode Ad-hoc trên hệ nhúng. B4. Triển khai chương trình bắt giữ tín hiệu video từ webcam. Sau đó đưa vào bộ đệm của hệ nhúng. Chờ khi nào có yêu cầu kết nối tới sẽ truyền luồng video tới Web Browser yêu cầu quan sát hiện trường. B5. Triển khai web server trên hệ nhúng (Hình 5.16). Vấn đề đặt ra là phải tiết kiệm tài nguyên cho hệ nhúng. Cùng với đó là thiết kế giao diện web sử dụng ngôn ngữ Tiếng Việt thân thiện với người dùng Việt Nam (Hình 5.17). B6. Ngoài ra nhóm em cũng nghiên cứu về giao tiếp RS232 trên hệ nhúng. Xây dựng được chương trình cho phép giao tiếp với hệ nhúng qua cổng RS232 (Hình 5.18). B7. Tích hợp hệ thống. Tích hợp tất cả các module thành một hệ thống mạng Ad-hoc hoàn chỉnh cho phép quan sát tín hiệu video từ tất cả các Web Browser trong mạng. Hình 5.14 Tiến trình triển khai driver cho card wifi mode Ad-hoc trên fit. Hình 5.15 Tiến trình thực hiện dự án truyền video qua mạng Ad-hoc Hình 5.16 Tiến trình triển khai web server trên armadillo. Hình 5.17 Tiến trình triển khai giao diện web Hình 5.18 Tiến trình xây dựng chương trình Changing Resolution Các module chính của dự án: + Module Nghiên cứu về hệ nhúng và xây dựng mạng ad-hoc trên hệ nhúng. Tìm hiều về hệ nhúng, các board , các kiến trúc . Việc xây dựng mạng ad-hoc dựa trên hệ nhúng. Việc triển khai là rất khả thi vì hệ nhúng tiết kiệm năng lượng. Phù hợp với việc xây dựng mạng ở những khu vực địa hình hiểm trở. Đặc biệt mạng Ad-hoc không cần cơ sở hạ tầng. + Module triển khai video streaming trên server. Hệ thống mạng Ad-hoc phù hợp để truyền video thời gian thực. Ứng dụng hệ thống vào việc quan sát hiện trường. Video từ hiện trường được đưa lên server. Module kết nối mạng + Module triển khai kết nối mạng. Thực hiện việc kết nối hệ nhúng thành mạng Ad-hoc. Mạng được định tuyến bằng OLSR. Luồng bắt tín hiệu chính là fit-pc. Luồng video nhận về được hiển thị trên web Browser. Giao diện người - máy Xây dựng web Browser cho phép người dùng có thể theo dõi video từ hiện trường. Hình 5.19 Giao diện người máy Web Browser Xây dựng chương trình “Resolution changing” cho phép người ở hiện trường có thể thay đổi resolution của video qua giao thức truyền thông RS232. Hình 5.20 Giao diện người máy Resolution Changing Tích hợp hệ thống Kết nối webcam vào fit-pc đã cài driver hỗ trợ. Cài đặt chương trình video streaming. Cài đặt webserver trên fit-pc, Cài đặt Webpage. Thiết lập mạng Ad-hoc. Thiết lập giao thức định tuyến OLSR cho mạng Ad-hoc. Tiến hành cấu hình và chạy video streaming trên mạng Ad-hoc. Phần cứng Hình 5.21 Webcam Labtech Hình 5.22 Armadillo 300 Hình 5.23 Giao tiếp RS232 Hình 5.24 Fit-pc + Bàn phím Phần mềm - Giao diện web quan sát hiện trường: Hình 5.25 Giao diện web ( giới thiệu) Hình 5.26 Giao diện web quan sát hiện trường - Giao diện chương trình Resolution changing. Hình 5.27 Giao diện Changing Resolution Hình 5.28 Giao diện Changing Resolution (Configure and Send Data). Kết quả Trong quá trình thực hiện dự án, em đã thiết lập thành công được mode ad-hoc cho fit-pc, nắm bắt được rõ kỹ thuật biên dịch chéo trên hệ nhúng cũng như sử dụng công cụ distcc để biên dịch chéo cho fit-pc. Em cũng đã triển khai dự án quan sát hiện trường trên hệ nhúng nối mạng Ad-hoc. Các máy client trên mạng Ad-hoc đã theo dõi được hiện trường qua trang web được truy cập vào địa chỉ của server. Tín hiệu thu được tương đối rõ nét khi ở khoảng cách gần hoặc khi Web Browser là 1 hop hoặc 2 hop. Khi khoảng cách quá xa hoặc chất lượng đường truyền khá thấp, chất lượng video không được tốt khi để độ phan giải cao. Để khắc phục điều này, nhóm nghiên cứu của em đã đưa ra giải pháp là thay đổi độ phân giải xuống thấp hơn để giảm kích thước gói tin truyền trên mạng Ad-hoc. KẾT LUẬN Việc nghiên cứu, triển khai mạng Ad-hoc cho các nút mạng có tính di động cao dựa trên các hệ điều hành và cấu trúc phần cứng khác nhau càng chứng tỏ tính di động và linh hoạt của mạng Ad-hoc. Việc phát triển mạng Ad-hoc trên hệ nhúng nhỏ gọn rẻ tiền có thể cung cấp thông tin mọi nơi mọi lúc. Các hệ thống này có thể mang trên người các đối tượng di chuyển (xe cộ, tàu thuyền) hoặc đặt cố định ở hiện trường (địa điểm công cộng) giúp truyền video có tương tác hoặc giám sát thời gian thực. Với điều kiện ở Việt Nam hiện nay vấn đề thiên tai lũ lụt xảy ra thường xuyên vì vậy ứng dụng để đưa mạng Ad-hoc vào quan sát hiện trường, đưa ra những cảnh báo kịp thời. Hướng phát triển tiếp theo của đồ án là tiếp tục phát triển hệ thống truyền video thời gian thực cho phép truyền video với độ nén tốt mà vẫn đảm bảo hình ảnh được khôi phục gần với ảnh gốc nhất. Phát triển giao diện người và máy có nhiều chức năng cho phép người dùng tùy biến việc truyền video. Phát triển các module cho phép khai thác tính di động cao của fit-pc. Cụ thể là nghiên cứu phát triển bàn phím và màn hình theo dõi dành riêng cho fit-pc cũng như các hệ nhúng khác. TÀI LIỆU THAM KHẢO Thuyết minh đề tài KHCN trọng điểm cấp nhà nước KC.01.10/06-10. Symbian developer library, section “Application development tutorial”, . Embedded Linux: BlueCat Linux, . Microsoft Windows Mobile, Windows Mobile Developer Center, Hiroaki Takada, Ken Sakamura, "μITRON for Small-Scale Embedded Systems," IEEE Micro, vol. 15, no. 6, pp. 46-54, Dec. 1995.