pkernel kai clock()/malloc()/free() tailoring

Christos Houtouridis hoo2.ch.pub at gmail.com
Fri Mar 8 01:45:46 EET 2013


Χαιρετώ τη λίστα.

Ας το κάνω σαφές από την αρχή. Αυτό το mail ΔΕΝ αφορά το GNU/Linux, ούτε
καν πυρήνα τύπου UNIX με fork κτλ. Αφορά howto kernel dev για συνυπάρξεις
μαζί με την GNU libc.

Πρόκειται για ένα πυρήνα για Cortex-M3/M4 τον "pkernel" εκ του pico-kernel,
που γράφω εδώ και 2-3 βδομάδες και που ελπίζω σύντομα να δει το web/φως της
δημοσιότητας.
Γενικά έχει (θέλω επιείκεια είμαι ηλεκτρονικός και όχι μηχανικός
λογισμικού):
- Μpreemtive multitasking με priorities (nice και fit)
- Semaphores / mutexes
- Privileged mode για όλους και όλα
- Sleep, wait, και lock μπορούν να κάνουν suspend
- και άλλα καλούδια για μας τους ηλεκτρονικούς.
- και μέχρι στιγμής τρέχει (μια χαρά) και κάνει compile χωρίς θεματάκια με
τον arm-non-eabi-gcc 4.7

Τεσπα, στο ζητούμενο. Ο pkernel κάνει χρήση του SysTick για μέτρηση χρόνου
και του PendSV για context switching. Στo PendSV "ζει" ο πυρήνας μας,
τρέχει ο scheduler και τα άλλα μπουξουσουλούκια και "καλείται" τόσο από το
SysTick όσο και ασύγχρονα μέσω sleep(), wait() κτλ. Και αφού το έχουμε που
το 'χουμε το SysTick δεν είναι "κρίμα" να μην κοινοποιήσουμε τον χρόνο στην
time.h? Μέχρι τώρα υπάρχει ένα ktime.h που παρέχει mktime, time, clock ktl.
Αν όμως κάποιος (εγώ δλδ πάλι) θέλει την time.h? Δεν θα ήταν καλό να μπορεί
αυτή η ριμάδα να ξέρει την τιμή των μεταβλητών Ticks και Now που κάνω
update στον SysTick? Μια σκέψη μου είναι να γίνει tailoring η clock() ή και
κάποια άλλη συνάρτηση της time.h. Μια άλλη σκέψη μου είναι να "βρω" που
σκατά βρίσκονται οι μεταβλητές για CPU time και να πειράξω εκείνες
κρατώντας την ktime.h κρυφή μέσα στον πυρήνα μου και χρησιμοποιώντας τις
λειτουργίες της(k_mktime, k_time κτλ) μόνο σε μικρά project που δεν έχει
κανείς ανάγκη όλη την time.h. Έχει κανείς καμιά ιδέα για το πως γίνεται
κάτι τέτοιο; Πως δηλαδή να πάρω από την clock() και την time() τις
μεταβλητές του πυρήνα μου; Οποιαδήποτε άλλη λύση/ ιδέα είναι ευπρόσδεκτη.

Και μην νομίζετε ότι αυτό ήταν. Έχει και δεύτερη ερώτηση.
Αυτή τη στιγμή όταν ο πυρήνας ξεκινάει (καλείται από την main πχ) "ψάχνει"
τις μεταβλητές που κάνει export το Link script _eram, _ebss, ..., _pulStack
(δείτε διάγραμμα παρακάτω). Από ότι έχω καταλάβει το linker script τα βάζει
όλα καλά και τακτοποιημένα, και μπορείς να δεσμεύσεις το χώρο (_eram -
pulStack) για kernel stack.
Αλλά.....όταν θές heap, κανεις Link με libc και κλήση της malloc, τότε οι
μεταβλητές γίνονται allocate, μετά το  pulStack + STACK_SIZE. Το οποίο
είναι μλκία(sorry) γιατί κόβει στη μέση τον ωραίο χώρο που είχαμε για
kernel stack. Σας κάνω attach το script αν θέλετε, αλλά είναι το κλασικό
script χωρίς να το έχω πειράξει καθόλου. Οπότε ερχόμαστε πάλι στην ίδια
λύση. Ξέρει κανείς αν μπορώ να γράψω την δική μου malloc/free και να μην
"χαλάσω" τη stdlib.h? Αν το κάνω αυτό τότε μπορώ να χρησιμοποιήσω αυτή τη
malloc για να κάνω allocation μνήμη και για τα processes μου, ενώ τώρα έχω
μια "μπακατέλα".

Ευχαριστώ

  ----------------
|                 | <- _eram
|                 |
|                 |
|                 |
|                 |
   - - - - - -    |<- pulStack + STACK_SIZE
|  Startup's  |
|    stack     | <- pulStack
---------------- ---
|                 | <- _ebss
|     .bss      |
|                 | <- _sbss / _edata
 ----------------
|                 |
|    .data      |
|   .sdata     | <- _sdata
------------------


Συγνώμη για το μακροσκελές, εκτός θέματος μήνυμα.

ΥΓ: Αν πάλι θέλετε μπορώ να ανεβάσω κάπου και όλο τον κώδικα. Ούτως ή άλλως
στο τέλος θα τον post-άρω κάπου.

--
Χουτουρίδης Χρήστος
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hellug.gr/pipermail/linux-greek-users/attachments/20130308/54ea037e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm-gcc-link.ld
Type: application/octet-stream
Size: 1399 bytes
Desc: not available
URL: <http://lists.hellug.gr/pipermail/linux-greek-users/attachments/20130308/54ea037e/attachment.obj>


More information about the Linux-greek-users mailing list