summaryrefslogtreecommitdiff
path: root/Kernel/CMakeLists.txt
AgeCommit message (Collapse)Author
2022-12-11Kernel+LibC+LibCore+UserspaceEmulator: Implement `faccessat(2)`sin-ack
Co-Authored-By: Daniel Bertalan <dani@danielbertalan.dev>
2022-12-03Kernel+SystemServer: Don't hardcode coredump directory pathLiav A
Instead, allow userspace to decide on the coredump directory path. By default, SystemServer sets it to the /tmp/coredump directory, but users can now change this by writing a new path to the sysfs node at /sys/kernel/variables/coredump_directory, and also to read this node to check where coredumps are currently generated at.
2022-11-08Kernel: Split the Ext2FileSystem.{cpp,h} files into smaller componentsLiav A
2022-11-08Kernel: Split the ISO9660FileSystem.{cpp,h} files to smaller componentsLiav A
2022-11-08Kernel: Split the DevPtsFS files into smaller componentsLiav A
2022-11-08Kernel: Split the Plan9FileSystem.{cpp,h} file into smaller componentsLiav A
2022-11-08Kernel: Split the ProcFS core file into smaller componentsLiav A
2022-11-08Kernel: Split the FATFileSystem.{cpp,h} files into smaller componentsLiav A
2022-11-08Kernel: Split the TmpFS core files into smaller componentsLiav A
2022-11-08Kernel: Split the SysFS core files into smaller componentsLiav A
2022-11-05Kernel: Add support for jailsLiav A
Our implementation for Jails resembles much of how FreeBSD jails are working - it's essentially only a matter of using a RefPtr in the Process class to a Jail object. Then, when we iterate over all processes in various cases, we could ensure if either the current process is in jail and therefore should be restricted what is visible in terms of PID isolation, and also to be able to expose metadata about Jails in /sys/kernel/jails node (which does not reveal anything to a process which is in jail). A lifetime model for the Jail object is currently plain simple - there's simpy no way to manually delete a Jail object once it was created. Such feature should be carefully designed to allow safe destruction of a Jail without the possibility of releasing a process which is in Jail from the actual jail. Each process which is attached into a Jail cannot leave it until the end of a Process (i.e. when finalizing a Process). All jails are kept being referenced in the JailManagement. When a last attached process is finalized, the Jail is automatically destroyed.
2022-10-26Kernel/aarch64: Unify building kernel source files in CMakeLists.txtTimon Kruiper
This now builds most of the kernel source files for both x86(_64) and the aarch64 build. Also remove a bunch of stubbed functions. :^)
2022-10-25Kernel+Userland: Move /sys/firmware/power_state to /sys/kernel directoryLiav A
Let's put the power_state global node into the /sys/kernel directory, because that directory represents all global nodes and variables being related to the Kernel. It's also a mutable node, that is more acceptable being in the mentioned directory due to the fact that all other files in the /sys/firmware directory are just firmware blobs and are not mutable at all.
2022-10-25Kernel/ProcFS: Remove all unnecessary componentsLiav A
Now that all global nodes are located in the /sys/kernel directory, we can safely drop the global nodes in /proc, which includes both /proc/net and /proc/sys directories as well. This in fact leaves the ProcFS to only have subdirectories for processes and the "self" symbolic link to reflect the current process being run.
2022-10-25Kernel: Introduce global variables and stats in /sys/kernel directoryLiav A
The ProcFS is an utter mess currently, so let's start move things that are not related to processes-info. To ensure it's done in a sane manner, we start by duplicating all /proc/ global nodes to the /sys/kernel/ directory, then we will move Userland to use the new directory so the old directory nodes can be removed from the /proc directory.
2022-10-22Kernel: Remove the DevTmpFS classLiav A
Although this code worked quite well, it is considered to be a code duplication with the TmpFS code which is more tested and works quite well for a variety of cases. The only valid reason to keep this filesystem was that it enforces that no regular files will be created at all in the filesystem. Later on, we will re-introduce this feature in a sane manner. Therefore, this can be safely removed after SystemServer no longer uses this filesystem type anymore.
2022-10-20Kernel/aarch64: Stub enough functions to build Random.cppTimon Kruiper
Also update Random.cpp such that it builds for aarch64.
2022-10-20Kernel/aarch64: Stub enough functions to build Process.cppTimon Kruiper
ProcessProcFSTraits.cpp is also added the CMakeLists.
2022-10-20Kernel/aarch64: Stub WaitQueueBlocker::unblock to build WaitQueue.cppTimon Kruiper
2022-10-20Kernel/aarch64: Stub more functions to build Thread.cppTimon Kruiper
2022-10-18Kernel/aarch64: Stub more functions to be able to build Scheduler.cppTimon Kruiper
With all these functions stubbed, Scheduler.cpp is now buidable!
2022-10-18Kernel: Reintroduce `ScopedAddressSpaceSwitcher` to aarch64 buildJesse Buhagiar
2022-10-18Kernel: Reintroduce `Mutex.cpp` to aarch64 buildJesse Buhagiar
A few more stubs have been added to support the building of this file
2022-10-18Kernel: Reintroduce `Credentials.cpp` to aarch64 buildJesse Buhagiar
2022-10-18Kernel: Include `KBufferBuilder.cpp` in aarch64 buildJesse Buhagiar
2022-10-18Kernel: Add even more AARCH64 stubsGunnar Beutner
2022-10-17Kernel: Implement TimeManagement for aarch64Timon Kruiper
This sets up the RPi::Timer to trigger an interurpt every 4ms using one of the comparators. The actual time is calculated by looking at the main counter of the RPi::Timer using the Timer::update_time function. A stub for Scheduler::timer_tick is also added, since the TimeManagement code now calls the function.
2022-10-17Kernel: Mark Version.h as a dependency of Kernel rather than ALLAndrew Kaster
2022-10-14Kernel: Add support for the FAT32 filesystemUndefine
This commit adds read-only support for the FAT32 filesystem. It also includes support for long file names.
2022-10-14Kernel: Abstract platform-specific current time methods from SchedulerLiav A
This change ensures that the scheduler doesn't depend on a platform specific or arch-specific code when it initializes itself, but rather we ensure that in compile-time we will generate the appropriate code to find the correct arch-specific current time methods.
2022-10-14Kernel: Bake version information into the Kernelkleines Filmröllchen
This is done by generating a Kernel/Version.h header with major version, minor version, and git hash.
2022-10-14Kernel: Remove -nodefaultlibs compiler optionsGunnar Beutner
This was necessary until a few months ago because of b0rked toolchain options.
2022-10-13Kernel: Add StdLib.cpp and UserOrKernelBuffer.cpp to aarch64 buildTimon Kruiper
Also remove UserOrKernelBuffer::{read, write} and __stack_chk_fail from Dummy.cpp and init.cpp respectively.
2022-10-03Kernel/Storage: Remove the ramdisk implementationLiav A
Nobody uses this because the x86 prekernel environment is corrupting the ramdisk image prior to running the actual kernel. In the future we can ensure that the prekernel doesn't corrupt the ramdisk if we want to bring support back. In addition to that, we could just use a RAM based filesystem to load whatever is needed like in Linux, without the need of additional filesystem driver. For the mentioned corruption problem, look at issue #9893.
2022-09-23Kernel: Introduce the IOWindow classLiav A
This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23Kernel: Move x86-specific timer code handling to Arch/x86/Time directoryLiav A
The APICTimer, HPET and RTC (the RTC timer is in the context of the PC RTC here) are timers that exist only in x86 platforms, therefore, we move the handling code and the initialization code to the Arch/x86/Time directory. Other related code patterns in the TimeManagement singleton and in the Random.cpp file are guarded with #ifdef to ensure they are only compiled for x86 builds.
2022-09-23Kernel/Graphics: Move x86-specific support for VGA to Arch/x86 directoryLiav A
The new VGAIOArbiter class is now responsible to conduct x86-specific instructions to control VGA hardware from the old ISA ports. This allows us to ensure the GraphicsManagement code doesn't use x86-specific code, thus allowing it to be compiled within non-x86 kernel builds.
2022-09-20Kernel: Move x86-specific init sequence code to the x86/Arch directoryLiav A
The code in init.cpp is specific to the x86 initialization sequence, so move it to the Arch/x86 directory in the same fashion like the aarch64 pattern.
2022-09-20Kernel: Move x86-specific IRQ controller code to Arch/x86 directoryLiav A
The PIC and APIC code are specific to x86 platforms, so move them out of the general Interrupts directory to Arch/x86/common/Interrupts directory instead.
2022-09-20Kernel: Move PCI IDE driver code to the Arch/x86 directoryLiav A
That code heavily relies on x86-specific instructions, and while other CPU architectures and platforms can have PCI IDE controllers, currently we don't support those, so this code is a special case which needs to be in the Arch/x86 directory. In the future it could be put back to the original place when we make it more generic and suitable for other platforms.
2022-09-20Kernel: Move x86 Bochs VBE code to the Arch/x86 directoryLiav A
To do this, we make the QEMUDisplayConnector class more standalone so it does not need to inherit from the BochsDisplayConnector class.
2022-09-20Kernel: Move x86-specific HID code to the Arch/x86 directoryLiav A
The i8042 controller with its attached devices, the PS2 keyboard and mouse, rely on x86-specific IO instructions to work. Therefore, move them to the Arch/x86 directory to make it easier to omit the handling code of these devices.
2022-09-20Kernel: Don't compile ISA IDE controller code in non-x86 buildsLiav A
The ISA IDE controller code makes sense to be compiled in a x86 build as it relies on access to the x86 IO space. For other architectures, we can just omit the code as there's no way we can use that code again. To ensure we can omit the code easily, we move it to the Arch/x86 directory.
2022-09-20Kernel: Move VMWare backdoor communication code to the x86 directoryLiav A
The VMWare backdoor handling code involves many x86-specific instructions and therefore should be in the Arch/x86 directory. This ensures we can easily omit the code in compile-time for non-x86 builds.
2022-09-20Kernel: Move PCI initialization x86-specific code to the arch directoryLiav A
It seems more correct to let each platform to define its own sequence of initialization of the PCI bus, so let's remove the #if flags and just put the entire Initializer.cpp file in the appropriate code directory.
2022-09-20Kernel: Move PCSpeaker code to the x86-specific architecture directoryLiav A
The PCSpeaker code is specific to x86 platforms, thus it makes sense to put in the Arch/x86 subdirectory.
2022-09-20Kernel/PCI: Move IO based HostBridge code to x86 arch-specific directoryLiav A
The simple PCI::HostBridge class implements access to the PCI configuration space by using x86 IO instructions. Therefore, it should be put in the Arch/x86/PCI directory so it can be easily omitted for non-x86 builds.
2022-09-20Kernel: Abstract platform-specific serial port access from kprintfLiav A
kprintf should not really care about the hardware-specific details of each UART or serial port out there, so instead of using x86 specific instructions, let's ensure that we will compile only the relevant code for debug output for a targeted-specific platform.
2022-09-20Kernel/x86: Move RTC and CMOS code to x86 arch-specific subdirectoryLiav A
The RTC and CMOS are currently only supported for x86 platforms and use specific x86 instructions to produce only certain x86 plaform operations and results, therefore, we move them to the Arch/x86 specific directory.
2022-09-20Kernel: Move IO delay code to x86 architecture subdirectoryLiav A
Many code patterns and hardware procedures rely on reliable delay in the microseconds granularity, and since they are using such delays which are valid cases, but should not rely on x86 specific code, we allow to determine in compile time the proper platform-specific code to use to invoke such delays.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 20:49:06 +0000