שאלות ראיון Linux Kernel — 30 שאלות ותשובות מעשיות

שאלות ראיון Linux Kernel — 30 שאלות ותשובות מעשיות

עודכן לאחרונה: 29 ספטמבר, 2026

שורה תחתונה:
  • ראיונות Linux Kernel בודקים הבנה עמוקה של ניהול זיכרון, תזמון תהליכים, מנגנוני סנכרון ו-Device Drivers — לא טריוויה.
  • 30 השאלות במדריך הזה מכסות את הנושאים שחוזרים על עצמם בראיונות לחברות כמו Mobileye, Mellanox (NVIDIA), Qualcomm ו-Intel בישראל.
  • לכל שאלה יש תשובה מעשית עם הסבר ברמת Kernel — לא רק "מה" אלא "למה ואיך".
  • כדאי לתרגל עם קוד אמיתי: לקרוא מקור הקרנל, לכתוב מודולים, ולהשתמש ב-ftrace וב-perf כדי להבין מה קורה מתחת למכסה המנוע.

אם יש לך ראיון על פוזיציית Kernel developer, BSP engineer או Embedded Linux בישראל דע שהמרואיינים לא מחפשים תשובות מ-Stack Overflow. הם רוצים לראות שאתה חושב ברמת ה-Kernel, מבין מה קורה בין User Space ל-Hardware, ויודע להסביר את זה בביטחון. המדריך הזה מכיל 30 שאלות שחוזרות שוב ושוב בראיונות בתעשייה הישראלית, עם תשובות מעשיות שייתנו לך יתרון אמיתי. לא קיצורי דרך, לא בלופים, תוכן שנבנה מניסיון בשטח.

אילו נושאי ליבה חוזרים בכל ראיון Linux Kernel?

בגדול, ראיונות Kernel מתחלקים לארבעה צירים מרכזיים: ניהול זיכרון (Memory Management), תזמון תהליכים (Process Scheduling), מנגנוני סנכרון (Synchronization), ו-Device Drivers. בואו נצלול לכל ציר עם השאלות הכי נפוצות.

שאלות בנושא ניהול זיכרון, מה באמת שואלים?

שאלה 1: מה ההבדל בין Virtual Memory ל-Physical Memory?
Virtual Memory הוא מרחב כתובות לוגי שהקרנל מציג לכל תהליך, כאילו יש לו זיכרון פרטי ורציף. ה-MMU (Memory Management Unit) בחומרה מתרגם כתובות וירטואליות לפיזיות דרך Page Tables. כך תהליכים מבודדים זה מזה, וניתן להשתמש ב-swap כדי להרחיב מעבר ל-RAM הפיזי.

שאלה 2: מה זה Page Fault ומתי הוא קורה?
Page Fault הוא interrupt שנוצר כשתהליך ניגש לכתובת וירטואלית שאין לה מיפוי פיזי תקף. יש שני סוגים: Minor — כשהדף קיים בזיכרון אבל ה-PTE לא מעודכן (למשל אחרי fork עם Copy-on-Write). Major — כשצריך לטעון את הדף מהדיסק (swap).

שאלה 3: הסבר את מנגנון ה-Slab Allocator.
Slab Allocator הוא מנגנון הקצאת זיכרון בקרנל שאופטימלי להקצאות קטנות ותכופות של אובייקטים בגודל קבוע (כמו struct task_struct). במקום לקרוא ל-buddy allocator כל פעם, הוא מקצה מראש "slabs" — בלוקים של דפים, ומנהל בתוכם cache של אובייקטים מוכנים. ב-Kernel מודרני נעשה שימוש ב-SLUB כברירת מחדל.

שאלה 4: מה ההבדל בין kmalloc ל-vmalloc?
kmalloc מקצה זיכרון פיזי רציף (contiguous) ומתאים להקצאות קטנות ול-DMA. vmalloc מקצה זיכרון שהוא רציף רק במרחב הוירטואלי אבל לא בהכרח פיזית, מתאים להקצאות גדולות אבל עם overhead של תרגום כתובות.

שאלה 5: מהו OOM Killer ומתי הוא מופעל?
כשהמערכת מגיעה למצב של חוסר זיכרון קריטי (Out of Memory), הקרנל מפעיל את OOM Killer שבוחר תהליך להרוג לפי ניקוד (oom_score) — שנבנה ממספר הדפים שהתהליך תופס, עדיפויות, וערך oom_score_adj שאפשר לקבוע ידנית.

שאלה 6: מה זה Memory-Mapped I/O לעומת Port I/O?
ב-MMIO רגיסטרים של חומרה ממופים למרחב הכתובות של הזיכרון — הקרנל ניגש אליהם עם ioremap ואז כותב/קורא כאילו לזיכרון רגיל. ב-Port I/O (נפוץ ב-x86 ישן) יש מרחב כתובות נפרד שניגשים אליו עם inb/outb. רוב הארכיטקטורות המודרניות, כולל ARM — משתמשות ב-MMIO.

שאלה 7: מה זה DMA ולמה הוא חשוב?
Direct Memory Access מאפשר לחומרה לגשת ישירות ל-RAM בלי לעבור דרך ה-CPU, מה שמשחרר את המעבד לעבודות אחרות. ב-Kernel צריך להקצות DMA-safe buffers (בדרך כלל דרך dma_alloc_coherent) ולהבטיח cache coherency.

נקודת מפתח: מרואיינים שמבינים את הקשר בין MMU, Page Tables ו-TLB — ויודעים להסביר מה קורה בתרחיש של TLB miss — מצליחים פי שניים בראיונות Kernel לעומת מי שמסתפק בהגדרות כלליות.

שאלות על תזמון תהליכים — Scheduler ו-Context Switch

שאלה 8: מה ההבדל בין Process ל-Thread ב-Linux?
ב-Linux, שני המושגים מיוצגים על ידי struct task_struct. Thread הוא תהליך קל, הוא חולק את מרחב הכתובות, טבלת file descriptors ו-signal handlers עם תהליך האב. thread נוצר עם clone() עם דגלים כמו CLONE_VM ו-CLONE_FILES. Process מלא מקבל עותק עצמאי של הכל.

שאלה 9: מהו CFS ואיך הוא עובד?
Completely Fair Scheduler הוא מתזמן ברירת המחדל ב-Linux. הוא משתמש ב-Red-Black Tree כדי לעקוב אחרי vruntime — זמן ריצה וירטואלי של כל תהליך. התהליך עם ה-vruntime הנמוך ביותר מקבל את ה-CPU הבא. כך מובטחת הוגנות: תהליכים שרצו פחות מקבלים עדיפות.

שאלה 10: מה השתנה עם EEVDF Scheduler?
בגרסאות האחרונות של הקרנל, CFS הוחלף ב-EEVDF (Earliest Eligible Virtual Deadline First). הגישה החדשה מוסיפה מושג של deadline וירטואלי, לא רק "מי רץ פחות" אלא "מי ה-deadline שלו הכי קרוב". זה משפר latency בעיקר לתהליכים אינטראקטיביים.

שאלה 11: הסבר מה קורה ב-Context Switch.
כש-Scheduler מחליט להחליף תהליך, קורים כמה דברים: שמירת רגיסטרים של התהליך הנוכחי ב-task_struct שלו, טעינת רגיסטרים של התהליך הבא, החלפת מרחב כתובות (טעינת CR3 ב-x86 / TTBR0 ב-ARM — מה ש-flushes את ה-TLB), ועדכון מצב ה-stack. זה overhead אמיתי, ולכן מינימום Context Switches הוא יעד ביצועי.

שאלה 12: מה ההבדל בין Preemptive ל-Non-Preemptive Kernel?
ב-Preemptive Kernel (ברירת המחדל ב-Linux מודרני), גם קוד שרץ ב-Kernel Space יכול להיות מופסק לטובת תהליך בעדיפות גבוהה יותר, למעט בתוך אזורים קריטיים מוגנים. Non-Preemptive Kernel לא יעשה switch עד שהקוד חוזר ל-User Space. ההגדרה נשלטת דרך CONFIG_PREEMPT.

שאלה 13: מה זה Real-Time Scheduling ב-Linux?
Linux תומך במדיניות RT: SCHED_FIFO ו-SCHED_RR. תהליכי RT תמיד מקבלים עדיפות על CFS/EEVDF. SCHED_FIFO רץ עד שמשחרר את ה-CPU או שתהליך בעדיפות גבוהה יותר מגיע. SCHED_RR דומה אבל עם time-slice. הפאצ' PREEMPT_RT מאפשר latency קבוע וצפוי — קריטי לתעשייה.

מנגנוני סנכרון — למה שואלים את זה ואיך עונים?

סנכרון הוא הנושא שבו הכי הרבה מועמדים נכשלים. לא בגלל שהם לא יודעים מה זה mutex — אלא בגלל שהם לא מבינים מתי להשתמש במה, ומה העלות. בואו נפרק את זה.

איזה מנגנון סנכרון לבחור ב-Kernel?

שאלה 14: מה ההבדל בין Spinlock ל-Mutex?
Spinlock עושה busy-wait — הוא סובב בלולאה עד שהנעילה מתפנה. Mutex שם את התהליך לישון. Spinlock מתאים לאזורים קריטיים קצרים מאוד ולהקשרי interrupt (שם אסור לישון). Mutex מתאים כשהנעילה עלולה להיות ארוכה וניתן להרשות context switch.

שאלה 15: מתי משתמשים ב-RCU?
Read-Copy-Update מתאים כשיש הרבה קוראים ומעט כותבים. הקוראים לא צריכים לנעול בכלל, הם פשוט קוראים דרך rcu_read_lock/rcu_read_unlock. הכותב יוצר עותק חדש של המבנה, מעדכן את המצביע, וממתין grace period עד שכל הקוראים הישנים סיימו. זה מנגנון יסוד בניהול routing tables ו-file systems.

שאלה 16: מה זה Atomic Operations ומתי מספיק להשתמש בהם?
ב-Linux הקרנל מספק atomic_t ומשפחת פונקציות כמו atomic_inc, atomic_dec_and_test. הם מבצעים פעולות בודדות על משתנה ללא צורך בנעילה — מבוססים על הוראות חומרה (LOCK prefix ב-x86, LDREX/STREX ב-ARM). מתאימים למונים פשוטים ול-flags.

שאלה 17: מה זה Priority Inversion ואיך Linux מטפל בזה?
Priority Inversion קורה כשתהליך בעדיפות גבוהה ממתין ל-mutex שמוחזק על ידי תהליך בעדיפות נמוכה, ותהליך בעדיפות בינונית רץ ומונע מהנמוך לסיים. הפתרון ב-Linux הוא Priority Inheritance: התהליך שמחזיק את המנעול "יורש" זמנית את העדיפות הגבוהה ביותר מבין הממתינים. rt_mutex מיישם את זה.

שאלה 18: מתי אפשר ליפול ל-Deadlock ב-Kernel ואיך מונעים?
Deadlock קלאסי: שני threads, שני locks, סדר נעילה הפוך. ב-Kernel משתמשים ב-lockdep — כלי debug שמגלה הפרות סדר נעילה בזמן ריצה ומנפיק אזהרות. הכלל: תמיד לנעול באותו סדר. אף פעם לא לקחת spinlock ואז mutex (כי mutex יכול לישון בזמן ש-spinlock מחזיק).

מנגנון ממתין או ישן? שימוש מתוך Interrupt? מתאים למקרה תקורה (Overhead)
Spinlock Busy-wait כן אזור קריטי קצר, interrupt context נמוכה אם קצר, גבוהה אם ארוך
Mutex ישן (sleep) לא נעילה ארוכה, process context context switch
RCU לא ממתין (קוראים) כן (קריאה) הרבה קוראים, מעט כותבים אפסית לקוראים
Atomic Operations לא ממתין כן מונים, flags בודדים מינימלית

מה שואלים על Device Drivers ו-Kernel Modules?

החלק הזה הוא הלחם והחמאה של כל פוזיציית Embedded Linux בישראל. אם אתה הולך לראיון ב-Mobileye, Qualcomm Israel, או כל חברת סמיקונדקטור, תצפה לשאלות מהסוג הזה.

איך כותבים Kernel Module מאפס?

שאלה 19: מה ההבדל בין Kernel Module ל-Built-in Driver?
Kernel Module נטען ומסיר בזמן ריצה (insmod/rmmod) — הקוד שלו נמצא בקובץ .ko נפרד. Built-in driver מקומפל ישירות לתוך ה-image של הקרנל (vmlinuz) ולא ניתן להסרה. הבחירה נעשית דרך Kconfig עם =m (module) או =y (built-in).

שאלה 20: הסבר את מנגנון ה-Device Tree.
Device Tree הוא מבנה נתונים (blob — dtb) שמתאר את החומרה למערכת ההפעלה. במקום ש-Kernel ידע מראש איזה חומרה קיימת (כמו ב-x86 עם ACPI), ב-ARM ובארכיטקטורות embedded ה-bootloader מעביר device tree ל-Kernel, והוא יודע אילו drivers לטעון ועם אילו פרמטרים. קבצי DTS נמצאים ב-arch/arm/boot/dts/.

שאלה 21: מה ההבדל בין Character Device ל-Block Device?
Character Device מספק גישה רצפית בייט-בייט (כמו UART, מקלדת). Block Device מספק גישה אקראית בבלוקים (כמו דיסק, eMMC). Character device משתמש ב-file_operations עם read/write/ioctl. Block device משתמש ב-request queue ו-bio structures.

שאלה 22: מה עושה probe() ב-Platform Driver?
probe() נקרא כשהקרנל מוצא התאמה (match) בין Device Tree entry לבין ה-compatible string של ה-driver. בתוך probe() ה-driver מאתחל את החומרה: מקבל resources (כתובות, IRQ), מבצע ioremap, מרשם character device, ומפעיל את ההתקן. זה כמו ה-constructor של ה-driver.

הנה דוגמה למודול Kernel מינימלי, זה הקוד שכל מי שהולך לראיון צריך לדעת לכתוב ישר על הלוח:


#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("RT-ED");
MODULE_DESCRIPTION("Minimal Kernel Module Example");

static int __init my_module_init(void)
{
    pr_info("my_module: loaded successfully\n");
    return 0;
}

static void __exit my_module_exit(void)
{
    pr_info("my_module: unloaded\n");
}

module_init(my_module_init);
module_exit(my_module_exit);

וה-Makefile שהולך איתו:


obj-m += my_module.o

KDIR := /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

טעינה ובדיקה:


# קומפילציה
make

# טעינת המודול
sudo insmod my_module.ko

# בדיקה שהמודול נטען
lsmod | grep my_module

# צפייה בלוג
dmesg | tail -5

# הסרה
sudo rmmod my_module

טעות נפוצה: מועמדים מנסים לשנן APIs — אבל המרואיין רוצה לראות שאתה מבין את הזרימה: איך הקרנל מגלה חומרה, מתי נקראת probe(), ומה קורה אם היא נכשלת. תזרים (flow) מנצח API בכל ראיון.

שאלות Interrupt Handling ו-Kernel Debugging

שאלה 23: מה ההבדל בין Top Half ל-Bottom Half ב-Interrupt Handling?
Top Half הוא ה-interrupt handler עצמו, רץ בהקשר interrupt, חייב להיות קצר ומהיר. Bottom Half (Tasklet, Workqueue, Softirq) מבצע את העבודה הכבדה, ניתן לדחות אותה, Workqueue רץ ב-process context ויכול לישון; Softirq ו-Tasklet לא.

שאלה 24: מה זה Threaded IRQ ומתי משתמשים בו?
request_threaded_irq() מאפשר ל-bottom half לרוץ כ-kernel thread עם עדיפות RT. ה-hardirq handler מבצע מינימום עבודה (אישור interrupt, בדיקה מהירה), והעבודה העיקרית רצה ב-thread. זה הסטנדרט ב-PREEMPT_RT ובמערכות שרגישות ל-latency.

שאלה 25: אילו כלי debug אתה משתמש ב-Kernel?
printk/pr_info לדיבוג בסיסי. ftrace לניתוח זרימת קריאות (function tracer, function_graph). perf לניתוח ביצועים וזיהוי bottlenecks. KGDB לדיבוג אינטראקטיבי עם GDB דרך serial. crash ו-kdump לניתוח kernel panics לאחר מעשה.

שאלה 26: מה זה Kernel Panic ומה גורם לו?
Kernel Panic הוא מצב שבו הקרנל מגיע לשגיאה בלתי ניתנת לשחזור — NULL pointer dereference ב-Kernel Space, stack overflow, חריגה ב-interrupt handler. המערכת עוצרת. כדי לנתח: מגדירים kdump שלוכד את מצב הזיכרון, ואז מנתחים עם crash utility.

שאלות מתקדמות — File Systems, Networking ו-Security

מה כדאי לדעת על File Systems ו-VFS?

שאלה 27: מה זה VFS ולמה הוא קיים?
Virtual File System הוא שכבת הפשטה בקרנל שמספקת ממשק אחיד לכל סוגי ה-File Systems — ext4, XFS, NFS, procfs. כשתהליך קורא ל-open() או read(), ה-system call עובר דרך VFS שמפנה לפונקציות הספציפיות של ה-File System. הרעיון: אפליקציה לא צריכה לדעת איזה FS מתחת.

שאלה 28: מה ההבדל בין procfs ל-sysfs?
procfs (ממוקם ב-/proc) נועד במקור לחשוף מידע על תהליכים, אבל הורחב לחשוף גם מידע מערכתי. sysfs (ממוקם ב-/sys) מציג את מבנה ה-device model של הקרנל בצורה היררכית, כל device, driver, bus מופיע כספרייה. הכלל: sysfs לחומרה ול-drivers, procfs לתהליכים ומידע מערכתי.

שאלה 29: הסבר בקצרה את Netfilter ו-iptables.
Netfilter הוא ה-framework בקרנל לסינון פקטות, NAT, ומניפולציה של תעבורת רשת. הוא מגדיר hooks בנקודות שונות ב-network stack (PRE_ROUTING, INPUT, FORWARD, OUTPUT, POST_ROUTING). iptables הוא ה-userspace tool שמגדיר חוקים ב-Netfilter. בגרסאות חדשות, nftables מחליף את iptables עם syntax אחיד וביצועים טובים יותר.

שאלה 30: מה זה Namespaces ו-Cgroups ואיך הם קשורים ל-Containers?
Namespaces מבודדים את מה שתהליך רואה — PID namespace, network namespace, mount namespace וכו'. Cgroups מגבילים את מה שתהליך יכול לצרוך — CPU, זיכרון, I/O. ביחד הם היסוד של כל טכנולוגיית Containers: Docker, Podman, LXC — כולם משתמשים ב-Kernel features האלה ולא בשום "קסם" משלהם.

הנה דוגמה מעשית — בדיקת namespaces בפעולה:


# יצירת network namespace חדש
sudo ip netns add test_ns

# הרצת פקודה בתוך ה-namespace
sudo ip netns exec test_ns ip addr
# תראו רק loopback — ללא ממשקי רשת חיצוניים

# יצירת veth pair לחיבור
sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth1 netns test_ns

# הגדרת כתובת IP בתוך ה-namespace
sudo ip netns exec test_ns ip addr add 10.0.0.2/24 dev veth1
sudo ip netns exec test_ns ip link set veth1 up

# ניקוי
sudo ip netns delete test_ns

סיכום והמלצות

ראיון Linux Kernel הוא לא מבחן טריוויה — זה שיחה מקצועית שבה המרואיין רוצה לראות שאתה חושב כמו Kernel developer. מי שמבין את הזרימה בין User Space ל-Kernel Space, יודע מתי לבחור spinlock על mutex, ויכול לכתוב מודול בסיסי על הלוח — נמצא כבר מקום טוב.

  • תתרגל לקרוא קוד מקור של הקרנל — תתחיל עם drivers/char/ ותלך משם. אין תחליף לקריאת הקוד האמיתי.
  • תבנה סביבת פיתוח עם QEMU ו-Buildroot כדי שתוכל לטעון מודולים, להריץ ftrace ולשבור דברים בבטחה.
  • תתמקד ב-flow ולא ב-API: מהרגע שתהליך עושה system call, דרך ה-VFS, ה-Scheduler, ה-interrupt handler — ועד שהתגובה חוזרת ל-User Space.
  • תדע להסביר כל תשובה בשלוש רמות: מילה אחת, שלושה משפטים, וציור על הלוח. זה בדיוק מה שמרואיינים מחפשים.
  • תעבוד עם ftrace ו-perf בפועל לפחות שעה של ניסוי מעשי שווה עשר שעות של קריאה.

עודכן: 2026-09-28

שאלות נפוצות

כמה זמן לוקח להתכונן לראיון Linux Kernel?

תלוי ברקע. מי שמכיר C ועבד עם Linux — שבועיים עד שלושה של עבודה רצינית על הנושאים במדריך הזה, עם תרגול מעשי (כתיבת מודולים, קריאת קוד מקור, שימוש ב-ftrace), יכולים להיות מספיק. מי שמתחיל מאפס — צריך חודש-חודשיים של עבודה שיטתית.

האם צריך לדעת C בשביל לעבוד עם Linux Kernel?

בלי ספק. Linux Kernel כתוב כמעט כולו ב-C (עם קטעי Assembly בודדים). אין דרך לעקוף את זה. צריך שליטה ברמה טובה: מצביעים, מבני נתונים, ניהול זיכרון ידני, macros ו-preprocessor. מי שבא מ-Python או Java — צריך לעשות השקעה רצינית ב-C לפני שניגש ל-Kernel.

מה ההבדל בין ראיון Kernel לראיון Embedded Linux?

ראיון Kernel מתמקד בפנימיות של הקרנל עצמו: scheduling, memory management, synchronization, VFS. ראיון Embedded Linux כולל גם את זה, אבל מוסיף שאלות על Bootloader (U-Boot), Device Tree, Board Bring-up, cross-compilation, ו-BSP integration. בפועל, בחברות ישראליות כמו Mobileye או Qualcomm — שני הסוגים מתמזגים.

אילו ארכיטקטורות חומרה חשוב להכיר?

ARM היא הארכיטקטורה הדומיננטית — בערך 90% מהפוזיציות embedded בישראל עובדות על ARM (Cortex-A ו-Cortex-M). כדאי להכיר גם x86 ברמה בסיסית ולהבין את ההבדלים (ACPI לעומת Device Tree, BIOS לעומת U-Boot). RISC-V צוברת תאוצה ושווה ללמוד ברמת מודעות.

האם PREEMPT_RT חשוב לדעת?

מאוד, במיוחד בתעשייה הישראלית. חברות שעובדות על מערכות Real-Time — רכב אוטונומי, תעופה, ציוד רפואי, רובוטיקה — משתמשות ב-PREEMPT_RT. זה לא נושא "נחמד לדעת" — בראיונות לפוזיציות RT שואלים ספציפית על Threaded IRQs, Priority Inheritance, latency benchmarking עם cyclictest, ומה ההשפעה של CONFIG_PREEMPT_RT על מנגנוני נעילה.

מה הכלי הכי חשוב לדיבוג Kernel?

ftrace. בלי להתלבט. הוא מובנה בקרנל, לא דורש recompile, ומאפשר לראות בדיוק אילו פונקציות נקראו, כמה זמן כל אחת לקחה, ומה הזרימה. perf חשוב לביצועים, KGDB חשוב לדיבוג אינטראקטיבי — אבל ftrace הוא הסכין השוויצרית. תתחיל עם trace-cmd record -p function_graph ותגלה עולם שלם.

האם כותבים Kernel code כחלק מהראיון?

כן, בהרבה ראיונות בישראל. שאלות נפוצות: כתוב character device driver בסיסי, ממש open/read/write. כתוב מודול שרושם proc entry. ממש handler ל-interrupt עם top half ו-bottom half. אל תנסה לזכור בעל פה — תבין את הלוגיקה ותתרגל לכתוב את ה-boilerplate (MODULE_LICENSE, module_init, file_operations) עד שזה אוטומטי.

מפתח Kernel טוב לא נולד עם ביטחון, הוא בונה אותו שורת קוד אחרי שורת קוד, dmesg אחרי dmesg, ו-kernel panic אחרי kernel panic. אם הגעת עד לכאן במדריך הזה, יש לך סקרנות — ואת הסקרנות הזו שום ראיון לא יכול לפסול. תמשיך להעמיק עם מדריכים נוספים באתר rt-ed.co.il — שם יש עוד חומרים מעשיים על Embedded Linux, Device Drivers, ו-RTOS שייתנו לך את הבסיס לצעד הבא.


תחומי לימוד הכי מבוקשים בהייטק בשנת 2026

© כל הזכויות שמורות Real Time Group