Commit 399dbe91 authored by bzt's avatar bzt

Fixed typos in docs

parent 99d610d7
OS/Z - an operating system for hackers
======================================
<img align="left" style="margin-right:10px;" alt="OS/Z" src="https://gitlab.com/bztsrc/osz/raw/master/logo.png">
<a href="https://gitlab.com/bztsrc/osz/tree/master/bin/">Download live images</a>, <small>(~8 Mbyte)</small><br>
<a href="https://gitlab.com/bztsrc/osz/blob/master/docs/README.en.md">Documentation</a><br>
<a href="https://gitlab.com/bztsrc/osz/issues">Support</a><br><br>
OS/Z is a POSIXish hobby OS project. As such it demonstrates [different concepts to POSIX](https://gitlab.com/bztsrc/osz/blob/master/docs/posix.md)
for those who like hacking with OSes. This used to include the community at OSDev.org, but as of 2018 that site has been taken over
by paid trolls, who are deliberatly giving bad advices and trying to undermine the community. Avoid them. Sadly it is not the place
as it once was.
My OS' aim is to be small, elegant, [portable](https://gitlab.com/bztsrc/osz/blob/master/docs/porting.en.md) and to be able to handle
enormous amounts of data in a user friendly way. To achieve that goal, I've eliminated as many limits as possible by design.
For example only storage capacity limits the number of inodes on a disk. And only amount of RAM limits the number of
concurent tasks at any given time. If I couldn't eliminate a hard limit, I've
created a [boot option](https://gitlab.com/bztsrc/osz/blob/master/docs/bootopts.en.md) for it so that you can tweek it without
recompilation. This makes OS/Z a very scalable system.
Features
--------
- [GNU or LLVM toolchain](https://gitlab.com/bztsrc/osz/blob/master/docs/compile.en.md)
- Microkernel architecture with an effective [messaging system](https://gitlab.com/bztsrc/osz/blob/master/docs/messages.en.md)
- Single disk image for [booting](https://gitlab.com/bztsrc/osz/blob/master/docs/boot.en.md) from BIOS or from UEFI or on Raspberry Pi 3.
- [Higher half kernel](https://gitlab.com/bztsrc/osz/blob/master/docs/memory.en.md) mapping, full 64 bit support
- It's [filesystem](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.en.md) can handle YottaBytes of data (unimagineable as of writing)
- ELF64 object format support
- UNICODE support with UTF-8
- Multilingual
Hardware Requirements
---------------------
- 10 Mb free disk space
- 32 Mb RAM
- 800 x 600 / ARGB display
- IBM PC with x86_64 processor - or -
- Raspberry Pi 3 with AArch64 processor
- [Supported devices](https://gitlab.com/bztsrc/osz/blob/master/docs/drivers.en.md)
Testing
-------
The [latest live dd image](https://gitlab.com/bztsrc/osz/raw/master/bin/osZ-latest-x86_64-ibmpc.dd) should boot OS/Z in emulators and on real machines. For example type
```shell
qemu-system-x86_64 -hda bin/osZ-latest-x86_64-ibmpc.dd
```
For more options, see [Testing How To](https://gitlab.com/bztsrc/osz/blob/master/docs/howto1-testing.en.md). I usually test the image
with [qemu](http://www.qemu.org/), [bochs](http://bochs.sourceforge.net/) and [virtualbox](https://www.virtualbox.org/).
License
-------
The boot loader and the [BOOTBOOT](https://gitlab.com/bztsrc/bootboot) Protocol, the [memory allocator](http://gitlab.com/bztsrc/bztalloc) and the
[on disk format of FS/Z](https://gitlab.com/bztsrc/osz/blob/master/include/osZ/fsZ.h) are licensed under MIT licence. Because the libfuse
library is licensed under GPL, therefore the [FS/Z FUSE](https://gitlab.com/bztsrc/osz/blob/master/tools/fsZ-fuse.c) driver is licensed under GPL as well.
All the other parts of OS/Z (including the native [FS/Z](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.en.md) implementation) licensed under CC-by-nc-sa-4.0.
This means although OS/Z is **Open Source**, it is **not a Free Software**. You can use it and play with it for your own pleasure at home, but
there’s absolutely no warranty applied. You are not allowed to use it in business environment or for commertial purposes without preliminary
written permission from the author.
Copyright (c) 2016-2019 bzt (bztsrc@gitlab) [CC-by-nc-sa-4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)
**You are free to**:
- **Share** — copy and redistribute the material in any medium or format
- **Adapt** — remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow
the license terms.
**Under the following terms**:
- **Attribution** — You must give appropriate credit, provide a link to
the license, and indicate if changes were made. You may do so in
any reasonable manner, but not in any way that suggests the
licensor endorses you or your use.
- **NonCommercial** — You may not use the material for commercial purposes.
- **ShareAlike** — If you remix, transform, or build upon the material,
you must distribute your contributions under the same license as
the original.
Project Structure
=================
```
(git repository)
|
|_ bin/ generated files
| |_ ESP/ files of the boot partition (FAT, boot files)
| |_ home/ files of the home partition (private user data)
| |_ initrd/ files of the initrd (ESP/BOOTBOOT/INITRD or boot partition)
| |_ usr/ files of the usr partition (system partition)
| |_ var/ files of the var partition (public variable data)
| |_ *.part partition images
| \_ *.dd disk images
|
|_ docs/ documentation
| \_ README.en.md main documentation index
|
|_ etc/ et cetera, miscelangelous files
| |_ root/ skeleton for root's home, /root on initrd
| \_ sys/ skeleton for system configuration files
| |_ etc/ skeleton for /sys/etc on initrd
| |_ lang/ language dictionaries for core and libc
| \_ config boot environment configuration file (ESP/BOOTBOOT/CONFIG, generated by "make config")
|
|_ include/ C header files, used by the build system (also installed to /usr/sys/include)
|
|_ loader/ pre-compiled boot loader images, see BOOTBOOT Protocol
|
|_ src/ source files
| |_ core/ supervisor
| | |_ aarch64/ architecture specific sources
| | | |_ rpi/ platform specific sources
| | \_ x86_64/ architecture specific sources
| | |_ ibmpc/ platform specific sources
| | \_ apic/ platform specific sources
| |_ drivers/ source of device drivers
| | |_input/ example device category
| | | \_ps2/ a device driver
| | |_display/ example device category
| | | \_bga/ a device driver
| | \_* device categories
| |_ libc/ source of C library
| |_ sh/ source of shell
| |_ */ necessary system services, libraries and applications
| \_ *.ld linker scripts
|
|_ tools/ scripts and utilities used by the build system
|
|_ usr/ userspace packages, installed to usr partition
| \_ sys/etc/ skeleton for /usr/sys/etc
|
|_ Config build system configuration file (generated by "make config")
|_ TODO.txt generated to-do list
\_ Makefile the main project GNU make file
```
For the generated file system directory structure, see [VFS](https://gitlab.com/bztsrc/osz/blob/master/docs/vfs.en.md).
Authors
-------
qsort: Copyright The Regents of the University of California
BOOTBOOT, FS/Z, OS/Z, bztalloc: bzt
Contributions
-------------
Geri: testing
jahboater: testing, ARM optimization suggestions
Octocontrabass: testing
BenLunt: constructive FS/Z criticism
This diff is collapsed.
......@@ -6,9 +6,10 @@ Developer's Corner
Materials interesting for developers.
* [Project Structure](https://gitlab.com/bztsrc/osz/blob/master/docs/project.en.md) of OS/Z repository
* [User callable functions reference](https://gitlab.com/bztsrc/osz/blob/master/docs/refusr.md)
* [System functions reference](https://gitlab.com/bztsrc/osz/blob/master/docs/refsys.md)
* [Memory Management](https://gitlab.com/bztsrc/osz/blob/master/docs/memory.en.md) in OS/Z
* The [FS/Z](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.en.md) file system, and it's [on disk format](https://gitlab.com/bztsrc/osz/blob/master/include/sys/fsZ.h)
* The [FS/Z](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.en.md) file system, and it's [on disk format](https://gitlab.com/bztsrc/osz/blob/master/include/osZ/fsZ.h)
* About [processes](https://gitlab.com/bztsrc/osz/blob/master/docs/process.en.md)
* [Scheduler](https://gitlab.com/bztsrc/osz/blob/master/docs/scheduler.en.md)
* Using [messages](https://gitlab.com/bztsrc/osz/blob/master/docs/messages.en.md) at different levels (aka. syscalls in OS/Z)
......
......@@ -6,9 +6,10 @@ Fejlesztői sarok
Fejlesztők számára érdekes anyagok
* Az OS/Z [projekt struktúrája](https://gitlab.com/bztsrc/osz/blob/master/docs/project.md)
* [Felhasználói szintről hívható függvények](https://gitlab.com/bztsrc/osz/blob/master/docs/refusr.md)
* [Rendszer által használt függvények](https://gitlab.com/bztsrc/osz/blob/master/docs/refsys.md)
* [Memória kezelés](https://gitlab.com/bztsrc/osz/blob/master/docs/memory.md) az OS/Z-ben
* Az [FS/Z](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.md) fájl rendszer, és a [lemezformátuma](https://gitlab.com/bztsrc/osz/blob/master/include/sys/fsZ.h)
* Az [FS/Z](https://gitlab.com/bztsrc/osz/blob/master/docs/fs.md) fájlrendszer, és a [lemezformátuma](https://gitlab.com/bztsrc/osz/blob/master/include/osZ/fsZ.h)
* [Processzekről](https://gitlab.com/bztsrc/osz/blob/master/docs/process.md)
* [Ütemezés](https://gitlab.com/bztsrc/osz/blob/master/docs/scheduler.md)
* [Üzenetküldés](https://gitlab.com/bztsrc/osz/blob/master/docs/messages.md) különböző szinteken (OS/Z rendszerhívások)
......@@ -28,11 +29,11 @@ Rendszergazdák játszótere
Leírás arról, hogy hogyan üzemeltessük az OS/Z-t
* Rendelkezésre álló [eszköz meghajtók](https://gitlab.com/bztsrc/osz/blob/master/docs/drivers.md)
* [Szolgáltatások](https://gitlab.com/bztsrc/osz/blob/master/docs/services.md) hierarchy and details
* [Virtuális Fájl Rendszer](https://gitlab.com/bztsrc/osz/blob/master/docs/vfs.md) és elérési utak
* [Szolgáltatások](https://gitlab.com/bztsrc/osz/blob/master/docs/services.md) hierarchiája és részletei
* [Virtuális Fájlrendszer](https://gitlab.com/bztsrc/osz/blob/master/docs/vfs.md) és elérési utak
* [Indítási opciók](https://gitlab.com/bztsrc/osz/blob/master/docs/bootopts.md)
* [Többnyelvűség](https://gitlab.com/bztsrc/osz/blob/master/docs/translate.md)
* A [vészhelyzeti parancsértelmező](https://gitlab.com/bztsrc/osz/blob/master/docs/howto4-rescueshell.md) hívája
* A [vészhelyzeti parancsértelmező](https://gitlab.com/bztsrc/osz/blob/master/docs/howto4-rescueshell.md) hívása
* OS/Z [telepítés](https://gitlab.com/bztsrc/osz/blob/master/docs/howto5-install.md)e pendrájvra és a csomagkezelés
* [Szolgáltatások kezelése](https://gitlab.com/bztsrc/osz/blob/master/docs/howto6-services.md).
......
......@@ -18,7 +18,6 @@ During boot, the execution is jumping forth and back from one part to the other.
The entry point that the loader calls is `_start`, which can be found in [src/core/(arch)/start.S](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/start.S).
It disables interrupts, sets up segments registers, distinguishes CPU cores, and puts APs in a spinloop.
It also initializes
Finally on the BSP jumps to the C startup code `main()` in [src/core/main.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/main.c) which is a platform independent code.
To boot up the computer, `core` does the following:
......@@ -30,31 +29,30 @@ To boot up the computer, `core` does the following:
5. `env_init` parses the [environment variables](https://gitlab.com/bztsrc/osz/blob/master/docs/bootopts.en.md) in [src/core/env.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/env.c) passed by the loader.
6. `pmm_init()` sets up Physical Memory Manager in [src/core/pmm.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/pmm.c).
7. `vmm_init()` sets up Virtual Memory Manager and paging in [src/core/(arch)/vmm.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/vmm.c).
8. `drivers_init()` in [src/core/drivers.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/drivers.c), creates `IDLE` task (the CPU "driver") and enumerates system buses to locate and load [device drivers](https://gitlab.com/bztsrc/osz/blob/master/docs/drivers.en.md). It will also initialize the IRQ Routing Table (IRT).
7. `sys_init()` in [src/core/sys.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/sys.c), creates `IDLE` task (the CPU "driver") and enumerates system buses to locate and load [device drivers](https://gitlab.com/bztsrc/osz/blob/master/docs/drivers.en.md). It will also initialize the [IRQ Routing Table](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/isr.c#L117) (IRT).
5. next it loads a [system service](https://gitlab.com/bztsrc/osz/blob/master/docs/services.en.md), `sys_service(SRV_FS)` which is a normal system service, except it has the initrd entirely mapped in in it's bss.
6. user interface is initialized with `sys_service(SRV_UI)`. These first three services (aka `IDLE`, `FS`, `UI`) are mandatory, unlike the rest (hence the upper-case).
7. loads additional, non-critical tasks by several `sys_service()` calls, like the `syslog`, `inet`, `sound` and `init` system services.
8. drops supervisor privileges by calling `sys_enable()`.
9. that function switches to the FS task, which arranges memory so that it can receive mknod calls from drivers and blocks.
10. then the scheduler, `sched_pick()` in [src/core/sched.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/sched.c) chooses driver and service tasks one by one. Note that pre-emption is not enabled at this point. Driver tasks perform hardware initialization and they fill up the IRT.
11. when all tasks are blocked and the `IDLE` task first scheduled, a call to `sys_ready()` in [src/core/sys.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/sys.c) will be made, which
12. enables IRQs with entries in IRT. It also enables timer IRQ and with that pre-emption may begin.
13. optionally the early syslog is dumped at the boot console. At this point the `core` has done with booting.
14. now that all storage device drivers are finished with their initialization, as a last thing `sys_ready()` sends a SYS_mountfs message to the `FS` task.
15. the control is passed to [FS task](https://gitlab.com/bztsrc/osz/blob/master/src/fs/main.c), which in turn parses [fstab](https://gitlab.com/bztsrc/osz/blob/master/etc/sys/etc/fstab). When mounting finished, `FS` notifies all the other system services and normal operation begins.
16. as soon as it's scheduled, one of the system services, the `init` task will load and start user session services.
8. `drivers_init()` in [src/core/drivers.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/drivers.c), creates `IDLE` task (the CPU "driver"), initializes the interrupt controller and the IRQ Routing Table (IRT), and enumerates system buses to load the required [device drivers](https://gitlab.com/bztsrc/osz/blob/master/docs/drivers.en.md) with `drivers_add()`.
9. next `core` loads a [system service](https://gitlab.com/bztsrc/osz/blob/master/docs/services.en.md), `service_add(SRV_FS)` which is a normal system service, except it has the initrd entirely mapped in in it's bss.
10. user interface is loaded with `service_add(SRV_UI)`. These first three services (aka `IDLE`, `FS`, `UI`) are mandatory, unlike the rest (hence the upper-case).
11. loads additional, non-critical tasks by several `service_add()` calls, like the `syslog`, `inet`, `sound` and `init` system services.
12. drops supervisor privileges and starts co-operative multitasking by calling `drivers_start()`.
13. that function switches to the FS task, which arranges memory so that it can receive mknod calls from drivers.
14. then the scheduler, `sched_pick()` in [src/core/sched.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/sched.c) chooses driver and service tasks one by one. Note that pre-emption is not enabled at this point.
15. driver tasks perform hardware initialization and they fill up the IRT.
16. when all tasks are blocked and the `IDLE` task is scheduled for the first time, a call to `drivers_ready()` in [src/core/drivers.c](https://gitlab.com/bztsrc/osz/blob/master/src/core/drivers.c) is made, which
17. enables IRQs with entries in the IRT. It also enables scheduler and wallclock IRQ and with that pre-emption may begin.
18. now that all storage device drivers are finished with their initialization, as a last thing `drivers_start()` sends a SYS_mountfs message to the `FS` task. At this point the `core` has done with booting.
19. the control is passed to [FS task](https://gitlab.com/bztsrc/osz/blob/master/src/fs/main.c), which in turn parses [fstab](https://gitlab.com/bztsrc/osz/blob/master/etc/sys/etc/fstab).
20. when finished with mounting file systems, `FS` notifies all the other system services to initialize.
21. as soon as it's scheduled, one of the system services, the `init` task will load and start user session services.
If rescueshell was requested in [environment](https://gitlab.com/bztsrc/osz/blob/master/etc/sys/config), then [bin/sh](https://gitlab.com/bztsrc/osz/blob/master/src/sh/main.c) is loaded instead of `init`.
(NOTE: If OS/Z was compiled with debug support and `debug=tests` passed in [environment](https://gitlab.com/bztsrc/osz/blob/master/etc/sys/config),
then `core` loads [system test](https://gitlab.com/bztsrc/osz/blob/master/src/test/main.c) instead of `init`, which will perform various unit and functionality tests.)
then `core` loads [bin/test](https://gitlab.com/bztsrc/osz/blob/master/src/test/main.c) instead of `init`, which will perform various unit and functionality tests on the system.)
User land
---------
The first real 100% userspace process is started by the [init](https://gitlab.com/bztsrc/osz/blob/master/src/init/main.c) system service.
The first real 100% user space process is started by the [init](https://gitlab.com/bztsrc/osz/blob/master/src/init/main.c) system service.
If it is the first run ever, then `bin/identity` is called to query computer's identity (such as hostname and other configuration) from the user.
Finally `init` starts all user services. User services are classic UNIX daemons, among others the user session service that provides a login prompt.
......@@ -62,16 +60,16 @@ User session
------------
As OS/Z is a multi-user operating system, it needs to authenticate the user. It is done by the `logind` daemon. When
the identity of the user is known, a session can be started by executing a user specific script. As soon as that script
ends the session is over, and execution is returned to `logind`, which will display the user login screen again.
the identity of the user is known, a session can be started by executing a user specific script in the name of that particular user.
As soon as that script ends the session is over, and execution is returned to `logind`, which will display the user login screen again.
This differs from POSIX operating systems, which usually have several ttys (provided by getty), one of which is the graphical
session (typically tty8, provided by X). In OS/Z there's a graphical session first (provided by the `UI` task), and you can start
a shell to get a tty (called pseudo-tty in UNIX terminology, provided by terminal emulators).
interface (typically tty8, provided by X). In OS/Z there's a graphical interface first (provided by the `UI` task), and you can
start a shell to get a tty (called pseudo-tty in UNIX terminology, usually provided by terminal emulators).
End game
--------
When the `init` system service quits, the execution is [passed back](https://gitlab.com/bztsrc/osz/blob/master/src/core/msg.c) to `core`.
Then OS/Z says "Good Bye" with `kprintf_reboot()` or with `kprintf_poweroff()` (depending on the exit status), and the platform
dependent part restarts or turns off the computer.
When the `init` system service quits, the execution is [passed back](https://gitlab.com/bztsrc/osz/blob/master/src/core/msg.c) to
`core`. Then OS/Z says "Good Bye" with `kprintf_reboot()` or with `kprintf_poweroff()` (depending on the exit status), and the
platform dependent part restarts or turns off the computer.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -15,13 +15,11 @@ The `core` is always compiled for a specific [machine](https://gitlab.com/bztsrc
which can be controlled in [Config](https://gitlab.com/bztsrc/osz/blob/master/Config) with `ARCH` and `PLATFORM` variables.
Valid combinations are:
| ARCH | PLATFORM | OPTIMIZE | Description |
| ------- | -------- | -------- | ----------- |
| x86_64 | ibmpc | x | For old machines, uses PIC, PIT, RTC, enumerates PCI bus |
| x86_64 | acpi | 0 | For new machines, APIC, IOAPIC, HPET and parses ACPI tables |
| x86_64 | acpi | 1 | For new machines, SIMD, x2APIC, x2IOAPIC, HPET and parses ACPI tables |
| aarch64 | rpi | 0 | Raspberry Pi 3+ |
| aarch64 | rpi | 1 | Raspberry Pi 3+, NEON |
| ARCH | PLATFORM | Description |
| ------- | -------- | ----------- |
| x86_64 | ibmpc | For old legacy machines, uses PIC, PIT, RTC, enumerates PCI bus |
| x86_64 | acpi | For new machines, LAPIC, IOAPIC, HPET and parses ACPI tables |
| aarch64 | rpi | Raspberry Pi 3+ |
If you have the "dialog" tool installed on your system, you can run the following to get a nice ncurses based interface.
......@@ -36,13 +34,13 @@ Compilation
-----------
The make system is created in a way that you can say `make all` in almost every directory. If you do that in the top level
directory, it will compile everything and will also build disk image for you, but surpressing messages. In subdirectories make
will always display the full command executed during compilation.
directory, it will compile everything and will also build disk image for you, but surpressing messages, only showing errors.
In subdirectories make will always display the full command executed during compilation.
For example if you enter `src/fs` and issue `make all` there, then only the filesystem subsystem will be recompiled, and
you'll be able to see the exact commands used.
So to compile all the things, simply type
So to compile all the things, in the top level directory simply type
```shell
$ make all
......@@ -98,7 +96,7 @@ See what you've done!
---------------------
The live disk image is generated to [bin/osZ-(ver)-(arch)-(platform).dd](https://gitlab.com/bztsrc/osz/blob/master/bin). Use the
`dd` command to write it on a USB stick or boot with qemu, bochs or VirtualBox.
`dd` command to write it on a USB stick or SD card, or boot with qemu, bochs or VirtualBox.
```
$ dd if=bin/osZ-latest-x86_64-acpi.dd of=/dev/sdc
......
OS/Z Fordítása
==============
Eszközök
--------
Szükséges eszközök
------------------
- GNU eszköztár (make, gcc, binutils (gas, ld, objcopy, strip), lásd [tools/cross-gcc.sh](https://gitlab.com/bztsrc/osz/blob/master/tools/cross-gcc.sh))
- gcc és ld helyett LLVM Clang és LLVM lld is használható
......@@ -15,15 +15,13 @@ A `core` mindig egy adott [gépre](https://gitlab.com/bztsrc/osz/blob/master/doc
[Config](https://gitlab.com/bztsrc/osz/blob/master/Config) fájlban az `ARCH` és `PLATFORM` változókkal állíthatunk be.
Az érvényes kombinációk a következők:
| ARCH | PLATFORM | OPTIMIZE | Leírás |
| ------- | -------- | -------- | ----------- |
| x86_64 | ibmpc | x | Régi gépekhez, PIC, PIT, RTC, PCI buszon detektál |
| x86_64 | acpi | 0 | Új gépekhez, APIC, IOAPIC, HPET és ACPI táblákat értelmez |
| x86_64 | acpi | 1 | Új gépekhez, SIMD, x2APIC, x2IOAPIC, HPET és ACPI táblákat értelmez |
| aarch64 | rpi | 0 | Raspberry Pi 3+ |
| aarch64 | rpi | 1 | Raspberry Pi 3+, NEON |
| ARCH | PLATFORM | Leírás |
| ------- | -------- | ----------- |
| x86_64 | ibmpc | Régi gépekhez, PIC, PIT, RTC, PCI buszon detektál |
| x86_64 | acpi | Új gépekhez, LAPIC, IOAPIC, HPET és ACPI táblákat értelmez |
| aarch64 | rpi | Raspberry Pi 3+ |
Ha van telepítve "dialog" segédprogram a gépegre, akkor a következő parancs egy kényelmes ncurses alapú felülettel segít.
Ha van telepítve "dialog" segédprogram a gépedre, akkor a következő parancs egy kényelmes ncurses alapú felülettel segíti a beállítást:
```shell
$ make config
......@@ -36,19 +34,18 @@ Fordítás
--------
A fordítási környezet úgy lett kialakítva, hogy majdnem minden könyvtárban kiadhatod a `make all` parancsot. Ha ezt a főkönyvtárban
teszed, akkor mindent lefordít és a lemezképeket is kigenerálja neked, de részletes üzenetek nélkül. Alkönyvtárakban kiadva a
make mindig megjeleníti a teljes parancsot, amit a fordításkoz és linkeléshez használ.
teszed, akkor mindent lefordít és a lemezképeket is kigenerálja neked, de részletes üzenetek nélkül, csak a hibákat megjelenítve.
Alkönyvtárakban kiadva a make mindig megjeleníti a teljes parancsot amit a fordításkoz és linkeléshez használ.
Például ha belépsz az `src/fs` mappába és ott adod ki a `make all` parancsot, akkor csak a fájl rendszer szolgáltatás fordítódik le,
és látni fogsz minden egyes felhasznált parancsot.
Például ha belépsz az `src/fs` mappába és ott adod ki a `make all` parancsot, akkor csak a fájlrendszer szolgáltatás fordítódik le,
és látni fogod a kiadott parancsokat is.
Szóval ha mindent szeretnél fordítani, akkor csak add ki
Szóval ha mindent szeretnél fordítani, akkor csak add ki a főkönyvtárban a
```shell
$ make all
```
Valami ilyesmit kell hogy láss:
parancsot. Valami ilyesmit kell hogy láss:
```
$ make all
......@@ -92,13 +89,13 @@ Nem-EFI betöltő
Ha újra akarod fordítani a `loader/boot.bin` és `loader/bootboot.bin` fájlokat, akkor szükséged lesz a [fasm](http://flatassembler.net)-ra.
Sajnos a GAS nem eléggé okos 16, 32 és 64 bites utasítások keverésében, ami elengedhetetlen a BIOS-ról induláskor. Hogy megtarthassam
az ígéretem, hogy csak GNU eszköztárra lesz szükség, hozzáadtam az előre lefordított BOOTBOOT bonárisokat a forrásokhoz.
az ígéretem, hogy csak GNU eszköztárra lesz szükség, hozzáadtam az előre lefordított BOOTBOOT binárisokat a forrásokhoz.
Nézd mit csináltál!
-------------------
Az indítható lemezképet a [bin/osZ-(ver)-(arch)-(platform).dd](https://gitlab.com/bztsrc/osz/blob/master/bin) néven generálja. Ezt a
`dd` paranccsal kiírhatod pendrávjra vagy SD kártyára, illetve futtathatod qemu, bochs vagy VirtualBox alatt.
Az indítható lemezkép [bin/osZ-(ver)-(arch)-(platform).dd](https://gitlab.com/bztsrc/osz/blob/master/bin) néven generálódik ki. Ezt a
`dd` paranccsal kiírhatod pendrájvra vagy SD kártyára, illetve futtathatod qemu, bochs vagy VirtualBox alatt.
```
$ dd if=bin/osZ-latest-x86_64-acpi.dd of=/dev/sdc
......
......@@ -7,8 +7,9 @@ Supported devices
* VESA 2.0 VBE, GOP, VideoCore (set up by [loader](https://gitlab.com/bztsrc/osz/blob/master/loader), 32 bit frame buffer)
* x86_64: syscall, NX protection
* x86_64-ibmpc: [PIC](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/pic.S), [PIT](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/pit.S), [RTC](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/rtc.S)
* PS2 [keyboard](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2/keyboard.S) and [mouse](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2/mouse.S)
* PS2 [keyboard](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2_8042/keyboard.h) and [mouse](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2_8042/mouse.h)
* AArch64: SVC, WNX protection
* aarch64-rpi: [BCM interrupt controller](https://gitlab.com/bztsrc/osz/blob/master/src/core/aarch64/rpi/intr.c), ARM Generic Timers, ARM Local Timer
Planned drivers
---------------
......@@ -22,8 +23,8 @@ There are two different kind of drivers: software drivers and hardware drivers.
of the system service task's address space (like file system drivers or tty and x11 drivers), while hardware drivers
have their own tasks.
Drivers are shared libraries which are loaded into separate address spaces after a common event dispatcher, [service.S](https://gitlab.com/bztsrc/osz/blob/master/src/libc/x86_64/service.S).
They are allowed to access IO address space with in/out instructions and to map MMIO at their bss. Otherwise driver tasks
Drivers are shared libraries which are loaded into separate address spaces after a common event dispatcher, [driver.c](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/driver.c).
They are allowed to access IO address space with in/out instructions and to map MMIO in their address space. Otherwise driver tasks
are normal userspace applications. You can compile the `core` for a platform with ARCH and PLATFORM variables in [Config](https://gitlab.com/bztsrc/osz/blob/master/Config).
For supported platforms, see [compilation](https://gitlab.com/bztsrc/osz/blob/master/docs/compile.en.md).
......@@ -32,19 +33,17 @@ For supported platforms, see [compilation](https://gitlab.com/bztsrc/osz/blob/ma
Device drivers are located in [src/drivers](https://gitlab.com/bztsrc/osz/blob/master/src/drivers), groupped in categories.
Each [driver class](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/README.en.md) has one directory, and
under these directories each driver has exactly one sub-directory. The compiled
driver will be placed in `sys/drv/(class)/(sub-directory).so`. For example, `src/drivers/input/ps2/main.c` will be compiled
to `sys/drv/input/ps2.so`.
driver will be placed in `sys/drv/(class)/(sub-directory).so`. For example, `src/drivers/input/ps2_8042/main.c` will be compiled
to `sys/drv/input/ps2_8042.so`.
Note that for performance, CPU, memory management, timers and interrupt controllers do not have separate drivers, they are built
into [core](https://gitlab.com/bztsrc/osz/tree/master/src/core). To switch among them, you'll have to edit `PLATFORM` and
`OPTIMIZE` in [Config](https://gitlab.com/bztsrc/osz/blob/master/Config) and recompile.
into [core](https://gitlab.com/bztsrc/osz/tree/master/src/core). To switch among them, you'll have to edit `PLATFORM` and recompile.
| PLATFORM | OPTIMIZE | Interrupt controller | Scheduler timer | Wallclock timer |
| ------------ | -------- | -------------------- | --------------- | ---------------- |
| x86_64-ibmpc | x | PIC | PIT | RTC |
| x86_64-apic | 0 | IOAPIC | LAPIC Timer | HPET |
| x86_64-apic | 1 | x2IOAPIC | x2APIC Timer | HPET |
| aarch64-rpi | x | BCM Interrupt Ctrl | ARM CNTP_TVAL | BCM System Timer |
| PLATFORM | Interrupt controller | Scheduler timer | Wallclock timer | System bus |
| ------------ | -------------------- | --------------- | ---------------- | ----------- |
| x86_64-ibmpc | PIC | PIT | RTC | PCI |
| x86_64-apic | IOAPIC | LAPIC Timer | HPET | PCI express |
| aarch64-rpi | BCM Interrupt Ctrl | ARM CNTP_TVAL | ARM Local Timer | - |
### Files
......@@ -60,8 +59,9 @@ Both files are newline (0x0A) separated list of words. The devices file has the
| Entry | Description |
| ----- | ----------- |
| * | Any, means the driver should be loaded regardless to bus enumeration. |
| pciXXX:XXX | A PCI vendor and device id pair |
| clsXXX:XXX | A PCI Class definition |
| pciXXXX:XXXX:XXXX:XXXX | A PCI vendor and device id pair with subsystem vendor id and subsystem id |
| pciXXXX:XXXX | A PCI vendor and device id pair, without subsystem identifiers |
| clsXX:XX | A PCI Class definition |
| FS | File system driver |
| UI | User interface driver |
| inet | Networking protocol driver |
......@@ -72,11 +72,11 @@ These informations along with the driver's path will be gathered to `sys/drivers
will be looked up in order to find out which shared object should be loaded for a specific
device.
Platform files just list platforms, like "x86_64-ibmpc" or "aarch64-rpi". At compilation time it will be checked,
and if the platform it's compiling for not listed there, the driver won't be compiled. This
Platforms file just list the platforms, like "x86_64-ibmpc" or "aarch64-rpi". Joker can be used, like "x86_64-*". At compilation time
this will be checked, and if the platform it's compiling for not listed there, the driver won't be compiled. This
is an easy way to avoid having platform specific drivers in non-compatible images, yet
you won't have to rewrite multi-platform drivers for every architecture (like an usb storage
driver). If the platform file is missing, the driver will be compiled for all platforms.
you won't have to rewrite multi-platform drivers for every architecture (like an USB mass-storage
driver). If the platforms file is missing, the driver will be compiled on all platforms.
### Developing drivers
......
OS/Z Device Drivers
===================
OS/Z Eszközmeghajtók
====================
Supported devices
-----------------
* VESA 2.0 VBE, GOP, VideoCore (set up by [loader](https://gitlab.com/bztsrc/osz/blob/master/loader), 32 bit frame buffer)
* x86_64: syscall, NX protection
* VESA 2.0 VBE, GOP, VideoCore (a [betöltő](https://gitlab.com/bztsrc/osz/blob/master/loader) állítja, 32 bites frame buffer)
* x86_64: syscall, NX védelem
* x86_64-ibmpc: [PIC](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/pic.S), [PIT](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/pit.S), [RTC](https://gitlab.com/bztsrc/osz/blob/master/src/core/x86_64/ibmpc/rtc.S)
* PS2 [keyboard](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2/keyboard.S) and [mouse](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2/mouse.S)
* AArch64: SVC, WNX protection
* PS2 [billentyűzet](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2_8042/keyboard.h) és [egér](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/input/ps2_8042/mouse.h)
* AArch64: SVC, WNX védelem
* aarch64-rpi: [BCM megszakítás vezérlő](https://gitlab.com/bztsrc/osz/blob/master/src/core/aarch64/rpi/intr.c), ARM Generic Timers, ARM Local Timer
Planned drivers
---------------
Tervezett eszközök
------------------
* x86_64-apic: HPET
Description
-----------
Leírás
------
There are two different kind of drivers: software drivers and hardware drivers. Software drivers are loaded into one
of the system service task's address space (like file system drivers or tty and x11 drivers), while hardware drivers
have their own tasks.
Kétfajta eszközmeghajtó létezik: szoftveres és hardveres meghajtó. A szoftveres meghajtók valamelyik rendszer szolgáltatás
címterébe töltődnek be (például a fájlrendszer meghajtók vagy a tty és x11 meghajtók), míg a hardveres meghajtóknak
saját külön taszkjuk van.
Drivers are shared libraries which are loaded into separate address spaces after a common event dispatcher, [service.S](https://gitlab.com/bztsrc/osz/blob/master/src/libc/x86_64/service.S).
They are allowed to access IO address space with in/out instructions and to map MMIO at their bss. Otherwise driver tasks
are normal userspace applications. You can compile the `core` for a platform with ARCH and PLATFORM variables in [Config](https://gitlab.com/bztsrc/osz/blob/master/Config).
For supported platforms, see [compilation](https://gitlab.com/bztsrc/osz/blob/master/docs/compile.md).
A meghajtók megosztott függvénykönyvtárak, amiket a saját címterükbe tölt be a rendszer egy közös diszpécser után, lásd [driver.c](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/driver.c).
Elérik a B/K címeket az in/out függvényekkel és az MMIO is le van képezve a címterükbe. Ettől eltekintve az eszközmeghajtók
sima felhasználói szintű alkalmazások. A `core` mindig egy adott platformra fordul, amit az ARCH és PLATFORM változók szabályoznak
a [Config](https://gitlab.com/bztsrc/osz/blob/master/Config)-ban. A lehetséges kombinációkért lásd a [fordítás](https://gitlab.com/bztsrc/osz/blob/master/docs/compile.md)-nál.
### Directories
### Könyvtárak
Device drivers are located in [src/drivers](https://gitlab.com/bztsrc/osz/blob/master/src/drivers), groupped in categories.
Each [driver class](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/README.md) has one directory, and
under these directories each driver has exactly one sub-directory. The compiled
driver will be placed in `sys/drv/(class)/(sub-directory).so`. For example, `src/drivers/input/ps2/main.c` will be compiled
to `sys/drv/input/ps2.so`.
Az eszközmeghajtók az [src/drivers](https://gitlab.com/bztsrc/osz/blob/master/src/drivers) alatt találhatók, kategorizálva.
Minden [eszköz osztály](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/README.md) pontosan egy könyvtár, és alatta minden
eszközmeghajtónak külön almappája van. A lefordított meghajtó a `sys/drv/(osztály)/(almappa).so` alá kerül. Páldául az
`src/drivers/input/ps2_8042/main.c` a `sys/drv/input/ps2_8042.so`-ba kerül lefordításra.
Note that for performance, CPU, memory management, timers and interrupt controllers do not have separate drivers, they are built
into [core](https://gitlab.com/bztsrc/osz/tree/master/src/core). To switch among them, you'll have to edit `PLATFORM` and
`OPTIMIZE` in [Config](https://gitlab.com/bztsrc/osz/blob/master/Config) and recompile.
Megjegyzés: hatékonyságnövelés érdekében a CPU kezelő, memória kezelő és megszakítás vezérlő a [core](https://gitlab.com/bztsrc/osz/tree/master/src/core)-ba
került, nincs külön meghajtójuk. Hogy leceréljük ezeket, a `PLATFORM` vátozót kell állítani és újrafordítani.
| PLATFORM | OPTIMIZE | Interrupt controller | Scheduler timer | Wallclock timer |
| ------------ | -------- | -------------------- | --------------- | ---------------- |
| x86_64-ibmpc | x | PIC | PIT | RTC |
| x86_64-apic | 0 | IOAPIC | LAPIC Timer | HPET |
| x86_64-apic | 1 | x2IOAPIC | x2APIC Timer | HPET |
| aarch64-rpi | x | BCM Interrupt Ctrl | ARM CNTP_TVAL | BCM System Timer |
| PLATFORM | Megszakítás vezérlő | Ütemező időzítő | Falióra | Rendszerbusz |
| ------------ | -------------------- | --------------- | ---------------- | ------------ |
| x86_64-ibmpc | PIC | PIT | RTC | PCI |
| x86_64-apic | IOAPIC | LAPIC Timer | HPET | PCI express |
| aarch64-rpi | BCM Interrupt Ctrl | ARM CNTP_TVAL | ARM Local Timer | - |
### Files
### Fájlok
Among the source files of the driver, there are two special ones:
A meghajtó fájlai között kettő kitüntetett szerepet kap:
| Name | Description |
| Név | Leírás |
| ---- | ----------- |
| devices | List of device ids, that this driver supports |
| platforms | List of platforms for which this driver should be compiled |
Both files are newline (0x0A) separated list of words. The devices file has the following entries:
| Entry | Description |
| ----- | ----------- |
| * | Any, means the driver should be loaded regardless to bus enumeration. |
| pciXXX:XXX | A PCI vendor and device id pair |
| clsXXX:XXX | A PCI Class definition |
| FS | File system driver |
| UI | User interface driver |
| inet | Networking protocol driver |
| (etc) | |
These informations along with the driver's path will be gathered to `sys/drivers` by
[tools/drivers.sh](https://gitlab.com/bztsrc/osz/blob/master/tools/drivers.sh). This database
will be looked up in order to find out which shared object should be loaded for a specific
device.
Platform files just list platforms, like "x86_64-ibmpc" or "aarch64-rpi". At compilation time it will be checked,
and if the platform it's compiling for not listed there, the driver won't be compiled. This
is an easy way to avoid having platform specific drivers in non-compatible images, yet
you won't have to rewrite multi-platform drivers for every architecture (like an usb storage
driver). If the platform file is missing, the driver will be compiled for all platforms.
### Developing drivers
If you want to write a device driver for OS/Z, [here](https://gitlab.com/bztsrc/osz/blob/master/docs/howto3-develop.md) you can find more information.
| devices | eszközazonosítók listája, amiket ez a meghajtó kezel |
| platforms | azon platformok listája, amikre ezt az eszközmeghajtót le kell fordítani |
Mindkét fájl újsor (0x0A) határolt szólista. A devices fájlban a következő bejegyzések lehetnek:
| Bejegyzés | Leírás |
| --------- | ----------- |
| * | bármi, azt jelenti, hogy a busz pásztázástól függetlenül be kell tölteni a meghajtót |
| pciXXXX:XXXX:XXXX:XXXX | PCI vendor és device id pár alrendszer vendor id és alrendszer id párral |
| pciXXXX:XXXX | PCI vendor és device id pár, alrendszer azonosítók nélkül |
| clsXX:XX | PCI osztály definíció |
| FS | fájlrendszer meghajtó |
| UI | felhasználói felület meghajtó |
| inet | hálózati protokoll meghajtó |
| (stb) | |
Ezek az információk az eszközmeghajtó elérési útjával együtt a `sys/drivers` fájlba kerülnek, amit a
[tools/drivers.sh](https://gitlab.com/bztsrc/osz/blob/master/tools/drivers.sh) állít elő. Ezt az adatbázist
induláskor használja a rendszer annak megállapítására, hogy melyik eszközmeghajtókat kell betölteni.
A platforms fájl csak felsorolja a platformokat, például "x86_64-ibmpc" vagy "aarch64-rpi". Használható joker is,
például "x86_64-*". Fordításkor ellenőrzi a rendszer, és ha az a platform amire épp fordítunk nincs felsorolva, akkor a
meghajtót nem fordítja le. Ez egy egyszerű módja annak, hogy elkerüljük a nem kompatíbilis eszközmeghajtók lefordítását,
ugyanakkor lehetővé tegyük, hogy a platformfüggetlen meghajtókat (mint páldául az USB adattároló) ne kelljen újraírni
minden platformhoz. Ha a platforms fájl hiányzik, az eszközmeghajtó minden platformra lefordul.
### Eszközmeghajtók írása
Ha eszközmeghajtóval szeretnéd bővíteni az OS/Z-t, [itt](https://gitlab.com/bztsrc/osz/blob/master/docs/howto3-develop.md)
találsz hozzá leírást.
......@@ -12,7 +12,7 @@ for x86_64 and aarch64.
The file system is designed to be recoverable by `fsck` as much as possible. A totally screwed up superblock can be reconstructed
by examining the sectors on a disk, looking for inodes of meta data. RAID mirroring is also possible with this file system.
For detailed bit level specification and on disk format see [fsZ.h](https://gitlab.com/bztsrc/osz/blob/master/include/sys/fsZ.h). For
For detailed bit level specification and on disk format see [fsZ.h](https://gitlab.com/bztsrc/osz/blob/master/include/osZ/fsZ.h). For
the higher level abstraction layer, see [VFS](https://gitlab.com/bztsrc/osz/blob/master/docs/vfs.md).
Implementations
......@@ -20,7 +20,7 @@ Implementations
The file system driver is implemented 3 times:
1. in the [loader](https://gitlab.com/bztsrc/osz/blob/master/loader), which supports GPT and FAT to locate initrd, and FS/Z, cpio, tar, sfs to locate kernel inside the initrd. This is a read-only implementation, that requires defragmented files.
2. in the [core](https://gitlab.com/bztsrc/osz/blob/master/src/core/fs.c), which is used at early boot stage to load various files (like the FS/Z file system driver) from initrd. This is also a read-only implementation for defragmented files.
3. as a [file system driver](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/fs/fsz/main.c) for the FS service, which is a fully featured implementation.
3. as a [file system driver](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/fs/fsz/main.c) for the FS task, which is a fully featured implementation with read/write and fragmanetation support.
FS/Z Super Block
----------------
......@@ -40,29 +40,29 @@ allowing spare files and gaps inside files.
File ID
-------
The file id (fid in short) is a logical sector number, which points to a sector with i-node structure. That can be checked
by starting with the magic bytes "FSIN".
The file id (fid in short) is a logical sector number, which points to a sector with an i-node structure. That can be checked
by checking the sector starting with the magic bytes "FSIN".
Inode
-----
The most important structure of FS/Z. It describes portion of the disk as files, directory entries etc. It's the first
1024 bytes of a logical sector. It can contain several versions thus allowing not only easy snapshot recovery, but per file
recovery as well.
1024 bytes of a logical sector (or 2048 if big inode flag is set in the superblock). It can contain several versions thus
allowing not only easy snapshot recovery, but per file recovery as well.
FS/Z also stores meta information (like mime type and checksum) on the contents, and supports meta labels in inodes.
Contents have their own address space mapping (other than LSNs). To support that, FS/Z has two different LSN translation
Contents have their own address space mappings (other than LSNs). To support that, FS/Z has two different LSN translation
mechanisms. The first one is similar to memory mapping, and the other stores variable sized areas, so called extents.
Sector List
-----------
Sector List (sl)
----------------
Used to implement extents and marking bad and free sector areas on disks. A list item contains a starting LSN and the number
of logical sectors in that area, describing a continuous area on disk. Therefore every extent is 32 bytes long.
of logical sectors in that area, describing varying length continuous areas on disk. Every extent is 32 bytes long.
Sector Directory
----------------
Sector Directory (sd)
---------------------
A sector that has (logical sector size)/16 entries. The building block of memory paging like translations. As with sector lists,
sector directories can handle LSNs up to 2^128 (or 2^96 if data checksum enabled), but describe fix sized, non-continous areas on
......
FS/Z Fájl Rendszer
==================
FS/Z Fájlrendszer
=================
Úgy lett megtervezve, hogy elképzelhetetlen mennyiségű adatot legyen képes tárolni. Klasszikus UNIX fájl rendszer, inode-okkal
és szuperblokkal, de a meglévők limitációi nélkül. Nincs felső határ szabva a fájlok vagy könyvtárak számára FS/Z-ben (kivéve
Úgy lett megtervezve, hogy elképzelhetetlen mennyiségű adatot legyen képes tárolni. Klasszikus UNIX fájlrendszer, inode-okkal
és szuperblokkal, de a meglévők limitációi nélkül. Nincs felső határ szabva a fájlok vagy könyvtárak számának FS/Z-ben (kivéve
a fizikai kapacitást). A logikai szektorszámozás 2^128 biten van tárolva hogy jövőbiztos legyen. A jelenlegi implementáció csak
2^64 bitet használ (elegendő 64 Zettabájtos lemezekhez 4096-os logikai szektormérettel, és 1 Yottabájtosakhoz 64k-s logikai
szektormérettel).
A logikai szektorméret 2048, 4096, 8192... stb. lehet. A javasolt méret megegyezik a mindenkori architektúra memória lapméretével.
Ez 4096 x86_64-on és aarch64-en.
Ez 4096 x86_64-on és AArch64-en.
A fájl rendszer új lett kialakítva, hogy sérült lemez esetén az `fsck` a lehető legtöbbet visszanyerhesse. Egy teljesen elrontott
A fájlrendszer új lett kialakítva, hogy sérült lemez esetén az `fsck` a lehető legtöbbet visszanyerhesse. Egy teljesen elrontott
szuperblokk esetén az adatai visszanyerhetők a többi szektor elemzésével, inode-okat és metaadatokat keresve. Szoftver szintű
RAID tükrözés szintén lehetséges ezzel a fájl rendszerrel.
RAID tükrözés szintén lehetséges ezzel a fájlrendszerrel.
A pontos, bitszintű specifikáció és a lemezen lévő formátum megtalálható az [fsZ.h](https://gitlab.com/bztsrc/osz/blob/master/include/sys/fsZ.h)
A pontos, bitszintű specifikáció és a lemezen lévő formátum megtalálható az [fsZ.h](https://gitlab.com/bztsrc/osz/blob/master/include/osZ/fsZ.h)
fájlban. A magasabb szintű absztrakciós réteg leírásáért pedig lásd [VFS](https://gitlab.com/bztsrc/osz/blob/master/docs/vfs.md).
Implementációk
--------------
A fájl rendszer 3 különböző helyen került implementálásra:
1. a betöltő [loader](https://gitlab.com/bztsrc/osz/blob/master/loader)-ben, ami GPT-t, FAT-et használ az initrd megtalálására, és FS/Z-t, cpio-t, tar-t, sfs-t a kernel keresésére az initrd-ben. Ez egy csak olvasni tudó, töredezettségmentes fájl rendszer implementáció.
2. a [core](https://gitlab.com/bztsrc/osz/blob/master/src/core/fs.c)-ban, ami az indulás korai szakaszában tölt be fájlokat az initrd-ről (például az FS/Z fájl rendszer meghajtót). Ez szintén egy csak olvasni tudó, töredezettségmentes fájl rendszer implementáció.
3. mint az FS szolgáltatás [fájl rendszer meghajtója](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/fs/fsz/main.c), ami egy teljes értékű implementáció.
A fájlrendszer 3 különböző helyen került implementálásra:
1. a betöltő [loader](https://gitlab.com/bztsrc/osz/blob/master/loader)-ben, ami GPT-t, FAT-et használ az initrd megtalálására, és FS/Z-t, cpio-t, tar-t, sfs-t a kernel keresésére az initrd-ben. Ez egy csak olvasni tudó, töredezettségmentes fájlrendszer implementáció.
2. a [core](https://gitlab.com/bztsrc/osz/blob/master/src/core/fs.c)-ban, ami az indulás korai szakaszában tölt be fájlokat az initrd-ről (például az FS/Z fájl rendszer meghajtót). Ez szintén egy csak olvasni tudó, töredezettségmentes fájlrendszer implementáció.
3. mint az FS taszk [fájlrendszer meghajtója](https://gitlab.com/bztsrc/osz/blob/master/src/drivers/fs/fsz/main.c), ami egy teljes értékű implementáció, írás/olvasás és tördezettség támogatással.
FS/Z Szuperblokk
----------------
A szuperblokk a legelső logikai szektor a mádián és opcionálisan a legutolsó szektoron megismételve. Ha a két szuperblokk eltér,
A szuperblokk a legelső logikai szektor a médián és opcionálisan a legutolsó szektoron megismételve. Ha a két szuperblokk eltér,
akkor a CRC ellenőrző összeg alapján eldönthető, melyik a helyes.
Logikai Szektorszám (LSN)
-------------------------
A logikai szektor méret a szuperblokkban van rögzítve. A szektorszám egy skaláris, szuperblokkhoz képesti relatív szám
2^218-on ábrázolva, ez utóbbi ezért mindig a 0-ás LSN-en található, függetlenül attól, hogy a lemez tartalmaz-e