ticket summary component version milestone type owner status created _changetime _description _reporter 2 IRQs can theoretically starve helenos/kernel/generic mainline enhancement Jakub Jermář new 2009-04-09T15:27:15+02:00 2009-05-06T20:47:47+02:00 With the new IRQ dispatcher, it is possible that a device generating lots of interrupts will starve other devices sharing the same collision chain. The solution is to rotate the IRQ structures in the dispatcher's hash table so that some kind of round robin within the collision chain is enforced. Jakub Jermář 4 HelenOS/sparc64 unstable with CONFIG_TSB helenos/kernel/sparc64 mainline defect Jakub Jermář reopened 2009-04-09T15:32:50+02:00 2017-11-11T17:07:06+01:00 "I found out that when I double the size of the buffer allocated for the TSB, the problem disappears. However, the size used for TSB allocation seems right. Therefore, it seems like something is damaging the content of the TSB memory. I still haven't seen this show elsewhere than on one of the Ultra 60's. Disabling TSB during compile time is a workaround for this bug. By further investigating the issue, I have come to the conslusion that the bug was introduced in revision 2161. It is more likely that an already existing bug was exposed by fixing another bug in 2161. 2161 fixes a bug which prevented the TSB from functioning at all. So it looks like a TSB issue. I have never seen this with r2128. The earliest revision I saw this bug on is r 2174. I have not investigated the revisions in between yet. The problem seems to be independent from whether the kernel was translated with gcc 4.1.1 or gcc 4.1.2. I saw this only on one Ultra 60 when trying to boot revisions around 2233 from a CD-ROM. What happened was one of the three scenarios: 1. the kernel booted just fine, but the ns task got the data_access_error exception (as reported in klog) and died; several tasks died afterwards, most likely due to the fact that they could not connect to ns; the kconsole was responsive in this case and I could investigate the content of the klog 2. the kernel booted just fine, but the ns task exitted and no exception was reported in klog; some other tasks died after ns exitted; the kconsole was responsive in this case and I could investigate the content of the klog 3. the kernel booted but then it looked as hung - no console task UI and the kconsole was not responsive" Jakub Jermář 5 Support uspace with the ability to join threads helenos/unspecified mainline enhancement mpr assigned 2009-04-09T15:33:35+02:00 2013-07-12T22:07:05+02:00 The kernel should provide userspace threads with syscalls for joining other threads, given their thread ID. This is essential to prevent leaking memory in form of userspace stacks of terminated threads. Martin Decky 9 Current fibril model can confuse kernel's view on threads helenos/lib/c mainline enhancement Jakub Jermář new 2009-04-09T15:36:39+02:00 2011-03-26T15:06:06+01:00 "Since the times of HelenOS 0.2.0, the fibril (formerly pseudo threads) scheduling uses a task-global queues for inactive fibrils. Thanks to this arrangement, fibrils can migrate among kernel threads. The problem here is that also kernel threads with userspace context (userspace threads) have some fibril characteristics and can migrate just as any other fibril. This is a potential problem: imagine the userspace context of a kernel thread is migrated to another thread. The migrated thread then calls thread_exit(). From the kernel's point of view, a wrong thread is terminated; its userspace context will however survive and will be migrated to another thread, deepening the confusion. Note that this behaviour also negatively impacts thread cycle accounting. A possible solution is to turn the global queues into thread-local queues and enable migration only per explicit request. That would demand other changes in userspace thread/fibril cleanup. Another solution might be to selectively disable migration of thread contexts, i.e. coexistence of the task-global and thread-local fibril queues." Jakub Jermář 10 Register window thrashing helenos/kernel/sparc64 mainline enhancement new 2009-04-09T15:37:06+02:00 2010-05-10T20:23:41+02:00 "The following snippet of userspace pseudo code demonstrates situation in which the kernel might repeatedly spill and fill several windows from the OTHERWIN area: for (i = 0; i < 10000; i++) { syscall(); } If the syscall handler spills N userspace windows, all N windows will be restored from the userspace window buffer on return from the syscall in each iteration. This sub-optimal behaviour was first pointed out by Mikulas Patocka." Jakub Jermář 11 Support PAE on ia32 helenos/kernel/ia32 mainline enhancement Martin Decky new 2009-04-09T15:37:38+02:00 2018-10-15T15:43:09+02:00 "Add support for Physical Address Extension to our ia32 port so that more than 4G of physical memory can be addressed. Details:: On all currently supported 32-bit platforms (arm32, ia32, mips32, ppc32), HelenOS assumes 32-bit physical addresses. This allows the system to make use of 4G of physical memory in total. Some of these architectures, however, provide extensions (e.g. PAE on ia32, LPAE on arm32) that make it possible to address more physical memory by using wider physical addresses (e.g. 36-bit or 40-bit). There are actually two goals for this project. The first is to modify HelenOS to use a dedicated type for representing physical addresses instead of the current `uintptr_t` or `void *`, because the assumption that both virtual and physical addresses have the same amount of bits will no longer hold. The second goal is to implement the actual support for PAE in the form of PAE page table format and PAE feature detection and initialization. What Gains and Benefits will this bring?:: By having the PAE support on ia32, HelenOS will be able to utilize more of the installed memory. HelenOS will also become ready to support similar features on other architectures (think LPAE on arm32). Difficulty:: High Required skills:: Kernel programming skills are needed and the applicant should be strong in C and should have the ability to understand the HelenOS memory management subsystem quickly. Documentation:: * [wiki:DeveloperDocs/CPUArch#IA-32 Developer documentation for IA-32 architecture] * [https://github.com/HelenOS/helenos/blob/master/kernel/doc/mm#L6 HelenOS abstraction for virtual address translation] * [https://github.com/HelenOS/helenos/tree/master/kernel/arch/ia32/src/mm Memory management implementation for IA-32] ([https://github.com/HelenOS/helenos/blob/master/kernel/arch/ia32/include/arch/mm headers]) Possible mentors:: HelenOS Core Team, Jakub Jermar" Jakub Jermář 12 Eliminate one of two copies during IPC_M_DATA_WRITE helenos/kernel/generic mainline enhancement new 2009-04-09T15:39:32+02:00 2016-05-04T20:55:57+02:00 "With the addition of the IPC_M_DATA_SEND call method, a new space for kernel improvements opened. In particular, the change of the current behaviour, in which a pair of copy_to_uspace() and copy_from_uspace() is required, is desirable so that the data is transfered only once (the current implementation copies the data twice). In more detail, the processing of the IPC_M_DATA_SEND call method is as follows. The sender makes the IPC_M_DATA_SEND call via an IPC syscall. The kernel allocates a buffer and copies the data from userspace into the buffer using copy_from_uspace(). The call is delivered to the destination task. The recipient evaluates the parameters such as the suggested destination address and size, and eventually answers. If the answer is positive, the kernel then copies the data from the buffer into the destination task's address space using copy_to_usapce(). This solution is portable and generic, but as has been already stated above, there are two data transfers instead of one. Here are some ideas I have about how to improve the situation. (1) After the recipient agrees to receive the data, the data will be copied directly from one address space to the other via each task's userspace virtual addresses. There are instructions for this on sparc64, other architectures may or may not provide such hardware support; however, there are some obstacles and necessary improvements that would have to be dealt with and that would have to be implemented (e.g. handling of page faults for other than the active address space). (2) emulation of (1) for architectures that have no hardware support for (1). The data will be copied from one physical location (frame) into another using kernel virtual addresses. The kernel will need to make sure that both the source and destination physical frame, respectively, is mapped in both the source and destination address space, respectively. Should the mapping for that frame be non-existent in one of the address spaces, the kernel will need to create the mapping for the task by simulating page faults (prefaulting). Currently, the mapping is created on-demand during a page fault. Support for prefaulting will need to be implemented. Previously, I had some worries about the source address space disappearing (i.e. dying or exiting) before the answer arrives. Nevertheless, this issue is not specific to these improvements and needs to be solved even now. As I can tell, there is a protection in that the source task cannot exit if it has any unanswered calls." Martin Decky 16 mips32 loaders need to maintain cache coherence helenos/boot/mips32 mainline enhancement new 2009-04-09T15:41:35+02:00 2018-10-12T20:23:40+02:00 "The mips32 loader needs to establish cache coherence after it copies the kernel and other components around memory (corner case of self modifying code). arm32 already does the right thing. sparc64 already does the right thing. ppc32 seems to flush something, but the issue still needs to be investigated/confirmed. ia64, as of now, does not relocate neither the kernel nor the components so the caches are coherent." Jakub Jermář 32 ppc32: use proper permissions on pages helenos/kernel/ppc32 mainline enhancement Martin Decky new 2009-04-10T13:08:13+02:00 2019-10-08T12:23:06+02:00 Set properly read-only bits on page mapping on ppc32. Martin Decky 38 Unify sysinfo, bootinfo, OFW tree helenos/unspecified mainline enhancement new 2009-04-10T13:25:19+02:00 2018-02-12T22:15:19+01:00 Replace the ad hoc bootinfo structures and perhaps also sysinfo with a unified platform-independent info structure, possibly similar to the canonized OFW tree which is used on sparc64 Martin Decky 40 Implement support for Sgi Octane (mips64) helenos/kernel/mips64 enhancement Martin Decky new 2009-04-10T13:27:06+02:00 2016-05-04T20:45:00+02:00 "Implement support for Sgi Octane machines (mips64 big-endian architecture). Details:: The Octane is a SMP machine built by Sgi in the 1997 - 2000 time frame. It is based on the MIPS R12000 CPU and a proprietary Crossbow ASIC crossbar switch instead of a system bus. It uses the ARCS boot firmware and originally runs with Sgi IRIX. The goal of this ticket is to implement at least a basic support for Sgi Octane (basic kernel functionality), i.e. support for booting, memory management, SMP, framebuffer output and keyboard input. What Gains and Benefits will this bring?:: Sgi Octane is an excellently engineered workstation with 64bit MIPS CPUs, SMP support and interesting hardware design that is inspiring even after many years. Implementing HelenOS support for Octane should hint any possible portability issues in HelenOS and it should also improve some minor functionality aspects of the kernel. Difficulty:: Very high Required skills:: Since there is very little publicly available hardware documentation of the Sgi Octane (except the CPU itself and other discrete components), the HelenOS support needs to be largely based on the reverse-engineered code in [http://www.linux-mips.org/~skylark/ Linux] and [http://www.openbsd.org/sgi.html OpenBSD]. Therefore a successful applicant will need to have very good skills in programming in the C language and the ability to learn and reuse know-how contained in reverse-engineered code of other operating system projects. Note:: We have a single Sgi Octane machine physically available for development, debugging and testing. Documentation:: * [http://www.linux-mips.org/~skylark/ Linux Sgi Octane port] * [http://www.openbsd.org/sgi.html OpenBSD Sgi Octane port] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 41 Add support for iMac G5 (ppc64) mainline enhancement Martin Decky new 2009-04-10T13:27:50+02:00 2009-04-10T13:27:50+02:00 Add support for iMac G5 (PowerPC 970FX). Martin Decky 42 Kconsole notifications in a separate thread helenos/kernel/generic mainline enhancement new 2009-04-10T13:33:41+02:00 2009-05-06T20:46:58+02:00 Do not send kconsole notifications in kernel from the main kconsole thread, but from a separate thread. This should avoid some deadlock situations when the generation of the IPC message needs to allocate memory. Martin Decky 43 Switch between virtual terminals using Alt+Fn helenos/srv/console mainline enhancement new 2009-04-10T13:34:44+02:00 2020-01-30T14:25:20+01:00 Currently plain F1, F2, ... keys are used. But it is not wise to reserve these keys and do not allow end-user applications to use them. Martin Decky 54 VFS to FUSE connector helenos/fs/other mainline enhancement new 2009-04-15T13:40:13+02:00 2011-03-08T22:06:21+01:00 "Implement a connector between the HelenOS VFS server and FUSE. Details:: The VFS-to-FUSE connector should act as an endpoint file system server task which plugs itself into the HelenOS VFS framework and implements the VFS output protocol, and also interface with or mimic the libfuse library. The individual FUSE file system implementation can either directly link to the connector or run as a separate server task. What Gains and Benefits will this bring?:: This should allow us to add a lot of file system implementations just by porting them from other systems with FUSE support. Difficulty:: medium Required skills:: A successful applicant will have good skills of programming in the C language and also the ability to program in a multi-server environment, which includes communicating using HelenOS IPC. Documentation:: - [wiki:FSDesign Implementation and design of the file system layer] - [http://fuse.sourceforge.net/ FUSE: Filesystem in Userspace] - [wiki:IPC IPC for Dummies] Possible mentors:: HelenOS Core Team, Jakub Jermar, Martin Decky" Martin Decky 55 Some keyboards do not support autorepeat helenos/srv/kbd mainline enhancement new 2009-04-15T19:39:46+02:00 2011-01-28T14:14:15+01:00 Some keyboards (e.g. NS16550 on Sun Ultra 60) do not support autorepeat. Investigate whether this is a problem of the driver, controller or hardware. Martin Decky 62 Support file system date attributes helenos/srv/vfs mainline enhancement new 2009-04-20T13:11:09+02:00 2017-11-11T11:45:38+01:00 Neither VFS nor the individual file systems currently honor the date attributes (e.g. creation and modification times). Jakub Jermář 65 Kernel input devices polling helenos/kernel/generic mainline enhancement new 2009-04-21T14:48:02+02:00 2009-05-06T20:46:07+02:00 "Implement support for kernel input devices polling again according to the proposal [http://lists.modry.cz/cgi-bin/private/helenos-devel/2009-March/002507.html]" Martin Decky 67 TMPFS relies on being single-threaded helenos/fs/tmpfs mainline enhancement new 2009-04-23T13:26:29+02:00 2011-09-26T22:08:24+02:00 The TMPFS file system server protects global data structures such as the ''dentries'' hash table by virtue of running multiple fibrils in only one thread and the fact that the fibrils switch context in a cooperative fashion. This is a possible scalability bottleneck. Jakub Jermář 72 Write back file system data from block cache to the block device periodically helenos/lib/block mainline enhancement Jakub Jermář assigned 2009-05-07T23:10:24+02:00 2017-11-11T11:43:33+01:00 "Currently, the file system modified data ends up in the block cache and is not being written back to the block device. With the addition of unmount support, data do eventually get written back, but it would be beneficial to write back the data periodically in 10s intervals or so." Jakub Jermář 77 Filesystem framework is extremely fragile helenos/srv/vfs mainline enhancement new 2009-05-22T10:42:41+02:00 2011-03-26T15:15:30+01:00 "A bug (e.g. segfault) in a single filesystem implementation server (mounted as non-root) can render the whole filesystem tree unavailable. The VFS implementation should be more robust to overcome problems in a single filesystem implementation, especially if it is non-root." Martin Decky 120 Some HelenOS code breaks strict aliasing rules helenos/unspecified mainline defect new 2009-09-22T16:58:36+02:00 2012-08-30T02:40:24+02:00 "According to GCC man page, -fstrict-aliasing is always active for optimization leves -O2, -O3 and -Os. This means HelenOS is compiled with strict aliasing active. But some code in HelenOS does not observe strict aliasing. GCC strict aliasing rule requires all code to observe aliasing rules as defined by C99 with only one exception -- type punning is allowed through the union type. Specifically type punning is disallowed through pointers. C99 requires that any variable can only be accessed as one specific type, or as char (via char pointer). Important note is that this applies GLOBALLY, not just within the scope of a function or module. Code in HelenOS that is suspect of breaking strict aliasing rules: - memcpy() (unaligned memcpy should be OK, but the aligned version is not) - drawing routines Code not observing the aliasing rules can break any time. Thus such code must be identified and fixed ASAP. If you have any suspicion about code breaking the aliasing rules, please let me know. " Jiri Svoboda 156 Improve support for non-xterm terminal emulators helenos/srv/console mainline enhancement Jiri Svoboda new 2010-01-07T15:57:05+01:00 2020-01-30T14:22:37+01:00 "HelenOS console can be accessed over a serial terminal, which is used by mips32/msim, mips32/gxemul, arm32/gxemul, ia64/ski, etc. The problem is that terminal escape sequences vary from one terminal emulator to another. Currently HelenOS code is tuned to xterm and people who use different terminal emulators have been reporting problems with garbled output and broken keys (such as cursor keys). It would be nice to improve support for other terminal emulators. One possibility is to find out if some specific escape sequences could be substituted for more generic which would work in more terminals. This, however is not very likely. Another way is to add explicit support for several different popular terminal emulators. I cannot think of a good way to detect the terminal type automatically. It would be necessary for the user to either select a default terminal type during build configuration or select the terminal type from HelenOS command line. " Jiri Svoboda 164 Implement stack tracing hooks for ia64 helenos/kernel/ia64 mainline enhancement new 2010-01-14T20:09:42+01:00 2017-11-11T17:02:24+01:00 Implement kernel and libc hooks for stack tracing on ia64. Jakub Jermář 165 Implement stack tracing hooks for mips32 helenos/kernel/mips32 mainline enhancement new 2010-01-14T20:11:08+01:00 2017-11-11T17:02:58+01:00 Implement kernel and libc hooks for stack tracing on mips32. Jakub Jermář 166 Implement kernel stack tracing hooks for ppc32 helenos/kernel/ppc32 mainline enhancement new 2010-01-14T20:14:49+01:00 2017-11-11T17:03:17+01:00 "Implement kernel hooks for stack tracing on ppc32. Besides the hooks, the following should be also done: - create initial stack frame on the initial kernel stack - make sure that in context_restore(), 0(sp) is zero - make sure that exception handlers stop the trace as appropriate" Jakub Jermář 167 Implement kernel stack tracing hooks for sparc64 helenos/kernel/sparc64 mainline enhancement Jakub Jermář new 2010-01-14T20:20:46+01:00 2017-11-11T17:04:11+01:00 "Implement kernel hooks for stack tracing on sparc64. Currently, there are the following open problems: - userspace windows are flushed to the userspace window buffer, so the uspace tracing hooks should somehow find the respective window save areas there - istate_t does not save fp (but it is located in the memory stack near the istate structure) - consider ticket #10 (Register window thrashing) - wait for integration of ticket #142 (sun4v support)" Jakub Jermář 173 Need a command line tool to manage null devices helenos/unspecified mainline enhancement new 2010-01-27T21:19:12+01:00 2017-11-11T16:52:57+01:00 The HelenOS libc provides the devmap_null_create/destroy() API, but there is no utility providing this API to the user though the command line. Jakub Jermář 177 OpenPIC driver for ppc32 helenos/unspecified mainline enhancement new 2010-01-31T15:06:51+01:00 2017-11-11T11:47:43+01:00 Currently we only support Heathrow PIC on ppc32 (G3 Mac). We need to support OpenPIC which is used in G4 Macs. This is needed to support ADB (i.e. keyboard and mouse) on G4, e.g. qemu-system-ppc -Mmac99, and on real hardware. Jiri Svoboda 184 Support for ipc_connect_me_to_timeout() would be useful helenos/srv/ns mainline enhancement new 2010-02-18T11:31:47+01:00 2016-05-04T20:32:23+02:00 "In situations when a client wants to wait for some service for only a limited time, it may be desirable to support timeouts either in the libc or in the naming service. An example of where this would be useful is the networking code. Without this feature we may see individual clients implement this in their own way," Jakub Jermář 201 fflush() should be cheap if output buffer is empty helenos/unspecified mainline enhancement new 2010-02-27T18:46:06+01:00 2017-11-11T11:48:39+01:00 "Currently a non-standard synchronization scheme is used for the console. The console/fb drivers assume that they can delay screen update until an explicit sync operation. This sync operation is achieved via fsync(). fflush() calls fsync() every time. In POSIX fflush() only writes out (flushes) the output buffer (if it is non-empty). But it does not sync the file descriptor, fsync() is a stronger operation. Terminal output in POSIX is updated immediately when data is written to the file descriptor. The big problem in HelenOS is that fflush() is expensive (does fsync(), which results in IPC) even when there is no data in the output buffer. This contributes to the slowness of operations such as fgetc() which try to flush output streams (and currently do it always, not just when we are reading from stdin). Another question is, whether it would be better to make the console behavior more standard, so that an fsync() is not necessary. " Jiri Svoboda 202 fgetc() should be smarter about buffer flushing helenos/unspecified mainline enhancement new 2010-02-27T18:50:46+01:00 2017-11-11T16:41:49+01:00 "Currently fgetc() tries to flush stdout and stderr every time it's called. This is because if we are reading from stdin, the standard behavior is to actually display everything that was sent to stdout before. Right now fgetc() is probably too conservative. Question is how smart it needs to be when deciding whether to flush (so that it's not overly progressive). Is it enough to check whether stream == stdin or do we need to check whether the underlying file descriptor is a console? (We probably should). This problem contributes to slow reading of stdin. See also #200 and #201. " Jiri Svoboda 209 Network IPC bridge helenos/unspecified mainline enhancement new 2010-03-14T17:42:37+01:00 2011-09-26T22:06:43+02:00 "As soon as the implementation of UDP or TCP is relatively stable, one possible networking application is a HelenOS IPC bridge. The network bridge would allow transparent use of a service (or services) running on a remote machine. It would do this by transporting IPC messages (such as DATA_WRITE, DATA_READ, CONNECT_ME_TO, CONNECT_TO_ME and user messages) over a TCP or UDP network socket. This would only work when the protocol does not require the use of shared memory. " Jiri Svoboda 212 Give flexible option to set console colors. helenos/srv/console mainline enhancement new 2010-03-16T15:38:38+01:00 2020-01-30T14:22:23+01:00 "Well,it would nice if the user console has white on black scheme than what it has now, the default one is kind of disturbing for the eye. Next reason is most of developers from other *nix platform will find home with is color scheme,suggestion is to give flexible option to set console colors." akber 215 Need 'interrupt task' functionality helenos/unspecified mainline enhancement new 2010-03-19T11:34:14+01:00 2017-11-11T16:42:22+01:00 "On Unix systems, the running application will receive the SIGINT signal after Ctrl+C is pressed in the terminal. The application can either not handle the signal, in which case it is killed or perform some custom action upon receiving it. We should implement similar functionality in HelenOS (without introducing signals). " Jakub Jermář 216 Need 'end of input' functionality helenos/unspecified mainline enhancement new 2010-03-19T11:52:26+01:00 2017-11-11T16:42:48+01:00 On Unix systems, Ctrl-D is the end-of-transimission control sequence. We could utilize something similar. For instance, pressing Ctrl-D in the VC of a running application will result in closing its standard input. Jakub Jermář 217 Need a way to detach devices helenos/srv/locsrv mainline enhancement new 2010-03-19T18:36:55+01:00 2014-07-03T08:48:15+02:00 "Commands like: - ata_bd - mbr_part - file_bd create new dev_handles and also nodes under /dev. There is currently no graceful way to release these resources so the associated dev_handles and nodes will exist in the system until reboot or until the respective server dies. When implementing support for device detaching, care must be taken not to detach a device which is being currently used. This can be achieved by adding a reference when it is being used (e.g. on mount). It would also be useful to be able to list what devices belong to what services, e.g.: {{{ # devadm list dev_handle driver node ========== ======= ============================= 1 rd bd/initrd 3 - null0 4 ata_bd bd/disk0 5 mbr_part bd/disk0p0 6 mbr_part bd/disk0p1 7 mbr_part bd/disk0p2 8 mbr_part bd/disk0p3 9 file_bd bd/fbdev0 # devadm list mbr_part dev_handle driver node ========== ======= ============================= 5 mbr_part bd/disk0p0 6 mbr_part bd/disk0p1 7 mbr_part bd/disk0p2 8 mbr_part bd/disk0p3 # devadm detach bd/disk0p0 bd/disk0p0 cannot be detached because it is being used. # devadm detach bd/disk0p1 # devadm list mbr_part dev_handle driver node ========== ======= ============================= 5 mbr_part bd/disk0p0 7 mbr_part bd/disk0p2 8 mbr_part bd/disk0p3 }}}" Jakub Jermář 248 i8042 kernel driver should be more robust helenos/kernel/genarch mainline enhancement Martin Decky new 2010-07-07T01:16:11+02:00 2017-11-11T16:44:12+01:00 "The kernel (and possibly also the uspace) i8042 driver should be more robust and deal with unexpected circumstances better. For example, the routine i8042_clear_buffer() might go into an infinite loop if the i8042 behaves strangely or is not even physically present (but only emulated with the help of the chipset and BIOS, as is the case of many recent USB-only machines). Also implementing the recommended initialization and self-test sequence of i8042 should help to detect situations where it is better not to deal with the controller at all." Martin Decky 269 Characters must be written atomically to the console helenos/srv/console defect new 2010-11-05T18:25:08+01:00 2017-11-11T17:18:28+01:00 "Currently the handler of VFS_WRITE in console expects that the provided data buffer consist of entire characters. If it does not, the incomplete characters won't be printed correctly. This might not be the best behavior, because it means that anyone writing to the console file interface needs to know they are writing text (as opposed to binary data). Currently 'cat' command in Bdsh is probably suffering from this. " Jiri Svoboda 281 printf functions are overserialized helenos/lib/c enhancement new 2011-01-09T14:13:25+01:00 2018-10-12T20:27:45+02:00 "Prior to changeset:mainline,791 vprintf() (uspace/lib/c/generic/io/vprintf.c) guarded the call to printf_core() with async_serialize(). Now it uses a ''global'' fibril mutex. This is slightly better, but still not good enough. Mutual exclusion, if any, should only be done per stream. The global lock incurs unnecessary (and potentially dangerous) dependencies between fibrils writing to completely different streams (e.g. to console and to a network socket, when we have sockfs). Actually, do we really want to ensure mutual exclusion for printf (on a specific stream)? AFAICT this is just a workaround for the fact that stream I/O functions are not fibril-safe. If we add the missing locking to stream I/O functions, we can drop the mutex from vprintf() altogether. The worst that could happen when multiple fibrils called printf() in parallel would be that the outputs would be intermixed, which is, IMO, acceptable. If an application needs to ensure that output of different fibrils is not intermixed, it should employ its own locking. " Jiri Svoboda 297 TICK ticks ahead of TICK_COMPARE helenos/kernel/sparc64 defect Jakub Jermář new 2011-02-26T00:57:06+01:00 2017-11-11T17:42:38+01:00 "I noticed a couple of times that the simulated Niagara machine running mainline,869 HelenOS/sparc64 got hung. The problem seems to be that the TICK register runs ahead of the TICK_COMPARE register and thus no tick interrupt is being generated. Since the keyboard on this machine is periodically polled, this also means that the system cannot be controlled via keyboard. This is somewhat similar to issues we have had on mips32. " Jakub Jermář 300 Spurious interrupt on Phenom X4 (quad core) helenos/kernel/ia32 defect Jakub Jermář new 2011-02-28T22:21:26+01:00 2017-11-11T17:43:03+01:00 "When I run the ia32 port of HelenOS mainline on my workstation Kvadrat (AMD Phenom II X4 905e Quad-Core, socket AM3 (Deneb), I am getting a 'cpu: spurious interrupt (inum=1)' message upon each keyboard interrupt (i.e. each time I press or release a key). Screenshot is attached. " Jiri Svoboda 304 Read-only UDF 2.50 (Blu-ray video) helenos/unspecified enhancement reopened 2011-03-01T00:26:29+01:00 2016-05-04T20:37:54+02:00 "Enhance the UDF file-system driver (when it is implemented, see ticket #303) to be able to read plain UDF 2.50 file systems as used in Blu-ray video and Blu-ray data disks. Note that Blu-ray video disk is used just as a measure of completeness of the implementation. Since we will not be able to decrypt the data reading a Blu-ray video disc is itself pointless. The intended use is reading of BD(-R) data disks. " Jiri Svoboda 309 async_data_read_finalize returns EOK even with NULL data and nonzero size helenos/lib/c mainline defect Jakub Jermář new 2011-03-07T18:02:38+01:00 2017-12-23T18:29:46+01:00 "The function async_data_read_finalize returns EOK even with NULL data and nonzero data size argument - I think in this case it should return EINVAL or EPERM. On the other side the async_data_read_start gets EPERM error even if it has provided correct argument, maybe there should be another errno (saying that the other side has behaved in a wrong way). Or, at least, state in the documentation that the EPERM means second side's error." Radim Vansa 310 Support for DWARF Debugging Information Format helenos-debugging enhancement new 2011-03-08T21:42:42+01:00 2018-01-15T18:30:52+01:00 "Implement support for an essential subset of the DWARF Debugging Information Format in HelenOS. Details:: The DWARF Debugging Information Format is a rich, processor architecture independent debugging format supported by the toolchain used to build HelenOS. It encodes information that may otherwise be hard or impossible to get during HelenOS run-time. The goal of this project is to identify aspects of the DWARF format that would improve the debugging capabilities and observability of both the HelenOS kernel and applications, and bring support for those aspects to HelenOS. An example of such an aspect is the support for reliable call stack unwinding. What Gains and Benefits will this bring?:: Besides other possible benefits that depend on the supported features, one key benefit would be the ability to reliably generate stack traces on some architectures that are not stacktracing-friendly, such as mips32. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and at least basic familiarity with binutils, gcc and linker scripts. This project may expose the candidate to mips32 assembly. Documentation:: - [wiki:DeveloperDocs#DebuggingData] - [http://dwarfstd.org/ Dwarf Home] - [http://dwarfstd.org/doc/Dwarf3.pdf DWARF 3] - [http://dwarfstd.org/doc/DWARF4.pdf DWARF 4] Possible mentors:: HelenOS Core Team, Jakub Jermar" Jakub Jermář 312 Coredumps should contain register state helenos/app/taskdump enhancement new 2011-03-09T23:20:55+01:00 2017-11-11T16:45:55+01:00 "Corefiles generated by '''taskdump''' do not contain the register state of the application which crashed or was snapshotted. This is a major shortcoming of our ability to generate coredumps because the coredumps are not that much useful without the register state. The register state is essential when one wants to print / reconstruct a stack trace or see the exact register value which caused the application to crash. " Jakub Jermář 313 Enhancement of user space debugging and observability features helenos-debugging enhancement new 2011-03-09T23:50:27+01:00 2014-02-13T15:38:09+01:00 "Improve or implement features for HelenOS user space debugging and observability. Details:: This is an umbrella project for implementing the following tickets that should significantly improve the observability and debugging of HelenOS user space: #280 Taskdump should print fibril stacks #312 Coredumps should contain register state #314 Debugging information lost for some aborts What Gains and Benefits will this bring?:: User experience and performance of a human troubleshooter aided by these features should be greatly extended as he/she will receive more and better structured information about the problem and will be able to use standard tools (e.g. gdb) for post mortem analysis. In turn, this will enable us to fix some bugs more effectively thanks to improved bug reports and also reduced need to reproduce a bug before fixing it. Difficulty:: Easy to Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to study information from various ABIs and processor manuals. The applicant will be exposed to the internals of the ELF format, so some familiarity with it is considered a plus. The applicant will also come across the HelenOS debugging interface, so it should be a system programming person rather than a strictly application programmer. Documentation:: [wiki:CoreFiles Working with core files] Possible mentors:: HelenOS Core Team, Jakub Jermar" Jakub Jermář 319 Input method for character terminals helenos/srv/kbd enhancement new 2011-03-21T23:47:26+01:00 2020-01-30T14:22:06+01:00 "HelenOS can be controlled with a keyboard or using a character ('serial') terminal (TTY). Such terminals don't support more complex key combos (e.g. Ctrl-Shift-F1) and even some simple combos cannot be used for various reasons. Currently there is no way to enter these combos on a character terminal, making it impossible to control applications such as Text Editor (Ctrl-S, Ctrl-Q) or CLUI-based apps (Bdsh, SBI : Ctrl-Q). An input method needs to be implemented that would allow for standard control combos ([Ctrl-][Alt-][Shift-]key) to be entered. Simply we would reserve one control character for each of Ctrl, Alt, Shift and entering these characters would ''latch'' the corresponding modifier key. Entering another character would release the latched modifier key. " Jiri Svoboda 320 Would be nice to type kconsole commands while 'test *' runs helenos/kernel/generic enhancement Jakub Jermář new 2011-03-22T21:59:08+01:00 2016-09-10T16:34:24+02:00 "In the unfortunate event that kconsole hangs while waiting for completion of: {{{ kconsole> test * }}} it would be extremely helpful to be able to type commands so that basic diagnosis of the problem is possible." Jakub Jermář 346 Scheduler SMP load balancing suboptimal helenos/kernel/generic mainline defect Jakub Jermář new 2011-05-30T20:45:33+02:00 2017-11-11T17:43:23+01:00 When running two CPU-bound single-threaded tasks (e.g. malloc1 test) on a 2-way SMP machine, the load balancing thread moves both of the mostly-ready threads (as well as most of the other ready threads) to a single CPU, keeping the other CPU almost idle. This renders in a very suboptimal utilization of the CPUs. Martin Decky 355 Revive Doxygen reference helenos/unspecified mainline enhancement new 2011-06-19T21:28:59+02:00 2017-11-30T16:05:43+01:00 "In the past it was possible to generate Doxygen reference documentation from HelenOS sources. The code that did this resided in a separate Subversion repository. Either this code should be revived or new code/script introduced to the Bazaar mainline to do this. We should be able to generate the reference documentation, even if it is just for the purpose of checking that our Doxygen comments have the correct syntax. " Jiri Svoboda 358 IRQ pseudocode compiler helenos/lib/other mainline enhancement new 2011-07-15T00:15:27+02:00 2016-05-04T20:33:04+02:00 "Devise a programmer-friendly language for describing HelenOS IRQ pseudocode and then implement its compiler and make HelenOS use it. Details:: Level-sensitive interrupts are tricky to handle especially in a microkernel-based operating system in which the device drivers run as userspace processes. The condition which triggered the interrupt must be cleared before the system is ready to receive another interrupt of the same kind (or the device immediately interrupts the system again), but only the userspace driver knows how to do it. This kind of a chicken-and-egg problem must be solved somehow. HelenOS achieves this in a portable way by letting the userspace driver inject a specialized byte code into the kernel. When an interrupt comes, the kernel uses the pseudocode to figure out whether the driver wants to accept the interrupt and also to clear the condition. IRQ pseudocode in drivers is typically written as a C initializer (array of structs with designated members). This is not very concise/elegant. What's worse, often we need to substitute constants representing various physical addresses into the code, which is done by patching the individual pseudocode instructions at run time by hand. It would be much more elegant to define a text-based language for expressing this symbolic instruction code. Thus the driver could express the pseudocode as a simple string literal that would be then converted to the binary form. The language could allow for named constants, which would make the code much more readable. What Gains and Benefits will this bring?:: It will be easier and more comfortable to write the interrupt-handling part of each driver. The pseudocode will be much more readable and there will be fewer programming errors. Difficulty:: Depending on the devised language, the difficulty will range from easy for an assembly-like language to medium and difficult for a more C-like language, such as the one suggested [#comment:2 here] or in [https://is.cuni.cz/studium/eng/dipl_st/index.php?do=main&doo=detail&did=46276 this master thesis]. Required skills:: A successful applicant will have good skills of programming in the C language and the ability to use both the current and the devised language for writing HelenOS IRQ pseudocode. In case of a more sophisticated language, the candidate shall also have an understanding of grammars and various compiler construction techniques. Documentation:: * [browser:/mainline/uspace/drv/nic/ne2k/ne2k.c#L76 Example of the current IRQ pseudocode in the NE2000 driver] * [#comment:2 Example of possible IRQ pseduocode description language] * [wiki:DeviceDrivers Writing Device Drivers for HelenOS] * [https://is.cuni.cz/studium/eng/dipl_st/index.php?do=main&doo=detail&did=46276 Linux kernel userspace modules (master thesis)] Possible mentors:: HelenOS Core Team, Jiri Svoboda, Jakub Jermar, Martin Decky" Jiri Svoboda 378 Fulltext search for the Mailman archive helenos-web enhancement new 2011-09-26T11:53:44+02:00 2011-09-26T12:22:43+02:00 Implement a fulltext search engine for the Mailman archive (e.g. Namazu). Martin Decky 381 Integrate interrupt controller drivers into DDF helenos/unspecified mainline enhancement new 2011-10-11T17:52:29+02:00 2017-11-12T11:34:02+01:00 "Currently we have interrupt controller drivers in the kernel and a few standalone drivers in uspace. These are, however, not integrated with the DDF and complex interrupt controller hierarchies (local APIC, IO-APIC, MSI interrupts on PCI, etc.) cannot be controlled in this way. The goal is to integrate interrupt controller drivers into DDF and export their functionality in a transparent way to the rest of the DDF (ideally without affecting other drivers). As discussed in the mailing list: > These are the areas where interrupt controllers and their drivers get involved: > > (A1) interrupt comes and we need to acknowledge the interrupt in the controller > - the IRQ dispatching is done separately on each architecture > - on ia32 and amd64, we assume one of two probable interrupt controllers (PIC or > APIC) and we use the trap_virtual_eoi() function to acknowledge the interrupt > in one of them > - for some reason that I can't remember now, we need to be able to specify per > IRQ, whether the IRQ is to be acknowledged prior to calling its handler > or after > - this is always done in the kernel > - situation on ppc32 is somewhat similar > > (A2) interrupt comes and we need to clear it in the controller > - this is what the situation is on sparc64 > - there can be various interrupt controllers > - FHC > - Sabre > - Psycho > - ... > - need to clear the interrupt in the interrupt controller after it is serviced or > there will be no further interrupts of the same kind > - this is done both in the kernel and in the userspace driver, depending on > whether a kernel or userspace driver is used to handle the interrupt > - for this reason, the IRQ structure is passed the cir function and an argument > > (C1) a level interrupt comes and we need to clear the condition which caused it before > reenabling interrupts (i.e. before the userspace driver can run) > - level interrupts will keep on reoccurring until the condition which caused them > is canceled -> unable to return to userspace before the condition is canceled > - canceling of the condition is usually done by reading or writing to one of the > device's register > - handling these interrupts in the kernel is relatively straightforward > - handling these interrupts in the userspace is hard and we use the pseudocode > for this reason (the driver uploads its interrupt handling top-half pseudocode > into the kernel) > > (C2) same as (C1), but need to clear the interrupt in the interrupt controller > - I think this is what prevents us from quickly implementing the Mac keyboard > driver in userspace (am I right Jiri?) > - the interrupt controller userspace driver will have a different address space > from the userspace keyboard driver > - need to use some form of the pseudocode in the userspace interrupt controller > driver? > > As you can see, there is a whole variety of options. I believe it is important to find > a system in this mess. For instance, are (A1) and (A2) the same phenomena? And (C1) and > (C2) are the same too because the interrupt can theoretically need to be cleared in > each node along the way from the device, through all possible bridge devices acting as > interrupt controllers up to the root device tree node? Should the userspace device > driver register the interrupt at the parent node instead of the kernel? (The parent > node can delegate sending of these interrupts to the kernel or its own parent)." Martin Decky 385 Support for address space identifiers on amd64 helenos/kernel/amd64 mainline enhancement Jakub Jermář new 2011-10-17T17:35:59+02:00 2011-10-17T17:35:59+02:00 "Modern amd64 processors (especially those manufactured by Intel) seem to support the idea of address space identifiers, PCIDs in Intel's terminology. Similar to other architectures that make use of ASIDs, PCIDs could be used to avoid TLB flushes on address space switches. Quoting from the Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1: {{{ 4.10.1 Process-Context Identifiers (PCIDs) Process-context identifiers (PCIDs) are a facility by which a logical processor may cache information for multiple linear-address spaces. The processor may retain cached information when software switches to a different linear-address space with a different PCID (e.g., by loading CR3; see Section 4.10.4.1 for details). A PCID is a 12-bit identifier. Non-zero PCIDs are enabled by setting the PCIDE flag (bit 17) of CR4. If CR4.PCIDE = 0, the current PCID is always 000H; otherwise, the current PCID is the value of bits 11:0 of CR3. Not all processors allow CR4.PCIDE to be set to 1; see Section 4.1.4 for how to determine whether this is allowed. }}} " Jakub Jermář 387 The APIC driver needs to get information about the IO APIC from the kernel helenos/srv/irc mainline defect new 2011-10-29T16:05:27+02:00 2017-11-11T17:44:36+01:00 The uspace APIC driver assumes some default values that should rather be obtained from the kernel, which attempts to detect the real values from hardware. These include, the IRQ to IO APIC pin map and the address of the IO APIC. Jakub Jermář 388 There is more to mapping IRQs to IO APIC pins helenos/kernel/ia32 mainline defect Jakub Jermář new 2011-10-29T16:18:52+02:00 2012-04-30T10:48:16+02:00 "The kernel provides two mechanisms for mapping an IRQ number to an IO APIC pin. At a time, only one mechanism is active, depending on whether the SMP was configured using the MPS code or the ACPI MADT parsing code. It turns out that especially the MPS way is more complicated than originally believed by its author. The problem is that the IRQ is specified as a tuple (bus, bus-relative IRQ number) while the current understanding is rather one-dimensional and absolute. For legacy ISA IRQs it appears to work, but for translating e.g. PCI IRQs, we need to do something more sophisticated." Jakub Jermář 391 Async exchange abort helenos/unspecified mainline enhancement new 2011-11-08T10:53:40+01:00 2011-11-08T11:09:20+01:00 "Async exchange is the unit of work for a server, It is used to request the server to perform some operation(s) and then wait for response(s) which indicates the result. Often an operation can take long or indefinite time to complete so. Therefore a way is needed to tell the server to abort the operation. The user calls async_exchange_abort() or similar, the async framework communicates this to the server via a private IPC method. The server-side async framework internally marks the specified exchange as aborted. The server user code can ask whether the current exhange is aborted. Abort-aware synchronization primitives (async_condvar_wait()) are provided that return with a special error code when the exchange is aborted. While this abort operation could be implemented at the protocol level, it is very common and it could simplify the implementation of servers considerably if we supported this in async framework directly. This feature would benefit cases such as user administratively aborting a task, detaching a device, etc. Necessary changes and gotchas: * need to reserve method numbers for purposes of async framework * need an alternate or extended version of async_condvar_wait() and possibly other functions * servers need to be made aware in order to make use of the feature (mark exchange boundaries, handle abort conditions) " Jiri Svoboda 392 Async per-port connection handlers helenos/unspecified mainline enhancement new 2011-11-08T11:08:35+01:00 2012-01-04T08:49:27+01:00 "Currently a server can set a single handler for all incoming connections using async_set_client_connection(). This makes it problematic to accommodate differt types of connections in a single server. We have libraries/frameworks/APIs (e.g. libdrv, loc API) that register with a naming service and want to accept connections made via that naming service. We cannot have a server that would be a DDF driver and loc service provider, for example, because of this (each API wants to usurp the connection handler). Currently a service is basically identified using a task ID. If we extend this identification with a ''port number'' and make services be identified with ''task ID:port number'', we can easily compose multiple servers in a single task. Port numbers would be assigned dynamically by the async framework and would be transparent to the user code. Port numbers would be transmitted as the first argument of a connect call. Proposed changes: * add function to allocate async port * add function to register connection handler for a port (as an alternative to a catch-all connection handler) * where desired, change the naming registration functions so that port where the service resides can be specified " Jiri Svoboda 393 Async single connection per session helenos/unspecified mainline enhancement new 2011-11-08T11:17:06+01:00 2012-04-24T14:52:07+02:00 "Currently EXCHANGE_PARALLEL is implemented using multiple IPC connections. This causes problems - often the framework lacks information on how to create the additional connections. (It does not know how many arguments get eaten by interposed naming services, callback connections). This can be all solved by multiplexing all exchanges into a single connection. This can now be implemented without changes to the async API. The framework would transparently tag each IPC call with an exchange ID (these would need to be allocated by the framework)." Jiri Svoboda 402 Port QEMU to HelenOS helenos/app/other mainline enhancement Vojtech Horky accepted 2011-12-21T20:39:32+01:00 2017-02-10T18:26:00+01:00 "Port [http://wiki.qemu.org/ QEMU] emulator to HelenOS Details:: QEMU is a machine emulator that is able to emulate environment of various hardware platforms, including PC, PowerPC, ARM or SPARC.[[br]] The goal of porting this emulator to HelenOS is to allow developers run the emulation of HelenOS inside HelenOS. It is unlikely that single person would be able to port all features of QEMU to HelenOS. First of all, the scope of QEMU is really big (it offers also means for virtualization) to be ported during such short period. Next, HelenOS itself may not provide all the functionality needed (for example, there is no port of SDL to HelenOS and the graphical toolkit in HelenOS offers only very limited set of features).[[br]] Because of these limitations, the applicant shall choose a reasonable subset of QEMU features (e.g. it is not necessary to support all emulated peripherals) and focus on porting these. On the other hand, the solution must provide functional emulator with at least rudimentary graphical output. What Gains and Benefits will this bring?:: The biggest benefit of this task is in the ability to run HelenOS inside HelenOS, thus possibly speeding-up development process and, as a more distant goal, develop HelenOS fully inside HelenOS. Also, the ability of an OS to run inside itself (i. e. be self-hosting) can be seen as a proof of maturity of the system. Difficulty:: Medium to High Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX application environment. Previous experience with development of machine emulator or some virtualization tool would be beneficial to the applicant. Documentation:: * [http://wiki.qemu.org/ QEMU homepage] * [http://wiki.qemu.org/Manual QEMU user's manual] * [http://wiki.qemu.org/Documentation/GettingStartedDevelopers Getting started developing QEMU] * [BinutilsMaintenance Maintenance instructions for another ported application (binutils)] Possible mentors:: HelenOS Core Team, Vojtech Horky" Jiri Svoboda 408 ia32, amd64: Number of CPUs is limited to 8 helenos/kernel/ia32 mainline enhancement Martin Decky accepted 2012-01-16T21:37:09+01:00 2016-05-04T20:48:54+02:00 "Due to the use of APIC Flat Mode the number of CPUs which can be woken up during the kernel initialization is limited to 8. The problem has been described in more details in the mailing list by Jakub Jermar: > I suspect this is because we configure the APICs to run in the flat > mode, which has this rather low limit. Quoting the Intel manual: > > Flat Model — This model is selected by programming DFR bits 28 through > 31 to 1111. Here, a unique logical APIC ID can be established for up to > 8 local APICs by setting a different bit in the logical APIC ID field of > the LDR for each local APIC. A group of local APICs can then be selected > by setting one or more bits in the MDA. > > And the corresponding part of apic.c::l_apic_init(): > > /* Program Destination Format Register for Flat mode. */ > dfr_t dfr; > > dfr.value = l_apic[DFR]; > dfr.model = MODEL_FLAT; > l_apic[DFR] = dfr.value; " Martin Decky 410 Can't have more than 1GiB of memory on ppc32 helenos/kernel/ppc32 mainline defect Martin Decky new 2012-01-25T00:41:44+01:00 2017-11-11T17:44:51+01:00 The current ppc32 kernel (but also revisions prior to the kernel non-identity feature merge) will not boot when the machine has more than 1GiB of memory. The booting process stays in the Booting the kernel... screen. Jakub Jermář 414 Graceful system shutdown helenos-infrastructure mainline enhancement Jakub Jermář new 2012-02-18T14:35:54+01:00 2018-12-18T20:07:47+01:00 "Design and implement graceful shutdown of HelenOS. Details:: The current support for shutdown in HelenOS is rather minimal. It is possible to halt the CPUs or reboot the machine. What is missing is a ''graceful'' way to tell running tasks that the system is about to be shut down. For example, the reboot sequence now consists of forceful kill of all existing tasks. The goal is to design and implement way to notify tasks of imminent shutdown (reboot) to allow them terminate in a clean and consistent way. The design decisions must reflect microkernel-specific issues, such as order of shutdown of vital services (e. g. VFS, naming service or drivers). What Gains and Benefits will this bring?:: The benefits of this task come at rather low level but are nevertheless very important. Graceful shutdown means that drivers could terminate communication with hardware in a predictable manner or that filesystem servers would be able to unmount file systems cleanly. Difficulty:: Medium to High. The solution will require work both in kernel and in userspace. Required skills:: A successful applicant will have good skills of programming in the C languages and the ability to survive in a non-standard non-POSIX application environment. Documentation:: * [http://en.wikipedia.org/wiki/Runlevel Runlevels used in Unix systems] * [DeviceDrivers Device drivers in HelenOS] * [source:mainline/kernel/generic/src/main/shutdown.c@mainline,1422#L42 Current reboot sequence in HelenOS] Possible mentors:: HelenOS Core Team, Vojtech Horky" Jakub Jermář 417 Port HelenOS to an existing 32-bit MIPS board / computer helenos/kernel/mips32 mainline enhancement Jakub Jermář assigned 2012-02-18T14:48:56+01:00 2016-05-04T20:49:48+02:00 "Port HelenOS to an existing 32-bit MIPS board / computer. Details:: HelenOS has run on two virtual mips32 platforms since very early in its history. At one point in time, a version of HelenOS even ran on the simulated MIPS Malta evaluation board. Unfortunately, the support for the only real MIPS hardware has been removed after some serious bit rot occurred in it. The current version of HelenOS/mips32 runs only on the machine emulated by the msim simulator and on the GXemul's ```oldtestmips``` machine. The goal of this project is to port HelenOS to a real 32-bit MIPS machine, such as the MIPS Malta evaluation board. What Gains and Benefits will this bring?:: It turns out that our mips32 support will be more useful if we change our focus from running on exotic and, sometimes, troublesome virtual platforms that are each supported by exactly one simulator, to running on existing hardware which is also emulated by multiple simulators (Qemu, GXemul, Simics etc.) Difficulty:: This project falls somewhere between medium and difficult on our difficulty scale. The fact that an ancient version of HelenOS once ran on MIPS Malta makes it a little bit less difficult as there will be no surprises in the core kernel support needed (i.e. no changes are expected). On the other hand, HelenOS has evolved and grown extraordinarily since then and there will be some new problems to solve, such as defeating the 4M boot image size limit. Moreover, the peripheral devices on the MIPS Malta evaluation board are basically PC-peripherals so the project can be extended in an interesting way by making sure HelenOS can make use of some of these devices. Required skills:: A successful applicant will be an experienced C programmer feeling comfortable touching all areas of HelenOS ranging from the boot code to the kernel and user space. The candidate shall not be afraid of learning / using the MIPS assembly and tweaking the HelenOS build configuration files. Documentation:: * [http://www.mips.com/products/development-kits/malta/] * [http://www.mips.com/products/product-materials/processor/development-systems/] * [http://www.linux-mips.org/wiki/Mips_Malta] * [http://qemu.weilnetz.de/qemu-doc.html#MIPS-System-emulator] * [http://gxemul.sourceforge.net] Possible mentors:: HelenOS Core Team, Jakub Jermar" Jakub Jermář 419 HelenOS as a Genode platform helenos/unspecified mainline enhancement new 2012-02-24T13:27:05+01:00 2016-02-19T15:43:57+01:00 "Port the Genode Operating System Framework to HelenOS. Details:: The Genode Operating System Framework can run on top of several kernels, including Linux and several L4 variants. As SPARTAN (the kernel part HelenOS) is a decent and mostly feature-complete microkernel, there is reason to believe that the Genode Framework can be used (with proper adaptation) as an alternative user space for HelenOS or coexist side-by-side with the native HelenOS user space. The level of integration between the native HelenOS user space and Genode can be varying and it is an integral part of the project to assess the proper design of the combined userland. There are several technical differences between native HelenOS user space and Genode (C vs. C++, communication style, etc.), but they can be bridged by various means. What Gains and Benefits will this bring?:: Using HelenOS as a new platform for Genode can benefit both projects. It can bring Genode to new processor architectures and can expose Genode to a non-L4 microkernel API, thus improving its universality. On the other hand, HelenOS will be exposed to a new userland, which will test it under different type of load and give it new set of features, currently unsupported by HelenOS (e.g. a graphical user interface). Difficulty:: High Required skills:: A successful applicant will have good skills of programming both in the C and C++ languages and the ability to learn and modify the internals of HelenOS and Genode. Also good software design skills and experience is required. Note:: This is a cross-project topic with [http://genode.org/community/gsoc_2012#Combining_Genode_with_the_HelenOS/SPARTAN_kernel Genode]. Documentation:: * [wiki:DeveloperDocs] * [http://genode.org/ Genode Operating System Framework] Possible mentors:: HelenOS Core Team, Martin Decky" Jakub Jermář 421 Non-anomymous DMA allocation needs to trigger on-demand mapping helenos/kernel/generic mainline defect Martin Decky new 2012-03-06T15:30:49+01:00 2017-11-11T17:45:37+01:00 "The current mainline implementation of non-anonymous DMA mapping is very rudimentary. The current code basically only looks up a physical translation of the given virtual address As the kernel uses on-demand mapping, if the uspace supplies a memory address to SYS_DMAMEM_MAP which has not been touched yet after its mapping into the address space, the translation fails (as the on-demand page mapping has not been established yet). The implementation would basically need to trigger the on-demand mapping." Martin Decky 423 DMA allocations need to survive address space destruction helenos/kernel/generic mainline defect Jakub Jermář new 2012-03-06T16:26:28+01:00 2017-11-11T17:45:57+01:00 The current DMA allocator does not track/lock DMA mappings beyond address space destruction. This can be potentially fatal as a DMA memory once assigned to hardware can be overwritten by the hardware if the original driver dies and the physical frames from its address space are recycled. Martin Decky 424 RPC/IPC generator helenos-infrastructure mainline enhancement new 2012-03-06T17:06:54+01:00 2018-01-15T19:33:31+01:00 "Implement compiler (generator) for the remote procedure calls over the IPC in HelenOS. Details:: IPC is almost everywhere in HelenOS and most of the time it looks as a remote procedure call (RPC). However, the wrapping code is written by hand although most of it merely wraps IPC calls and error handling. Writing this wrapper code can be quite easily automated to reduce the amount of repetitive code. [[br]][[br]] The task is to create an interface definition language (IDL) and a generator that would create the respective C code to execute the RPC. [[br]][[br]] The IDL would define interfaces where each interface would have its unique name, optionally list of parent interfaces (that are extended) and a list of methods (calls) and events (callbacks). Each method and event has its name, return type and list of input and output arguments together with their types. [[br]][[br]] The IPC in HelenOS is mostly asynchronous and thus the concept of calls and callbacks is necessary. However, the implementation shall not provide only the naive implementation of classical callbacks but also the concept of futures (promises) to allow writing the servers in the same pseudo-synchronous manner as it is today. [[br]][[br]] In the first iteration, the IDL can support only basic types (plain integers and blocks of memory would be sufficient for majority of the interfaces), features such as structures or arrays can be added later. [[br]][[br]] The result of the compilation (generation) would be a set of C sources and headers files containing: * enums declaring method and event codes * typedefs encapsulating the interface instance for server and client * method and event ops structures * method and event dispatcher (switch statement) - on the called side * method and event call marshalling functions - on the calling side * method and event call unmarshalling functions - on the called side * code to set up and tear down the interface (mainly the callback session) [[br]] It would be preferable to have the generator written in Python as most of the build tools are implemented in Python. What Gains and Benefits will this bring?:: There should be no impact at all to the functionality of HelenOS as an operating system. The benefit would be in making the code more readable because a lot of similar code would be removed, being replaced by an automatically generated one. The presence of such generator would also simplify the process of adding a new interfaces. In the longer term, it would simplify creating bindings for other languages (e.g. OOP-style generator for C++). Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C and Python languages and the ability to survive in a non-standard non-POSIX application environment. Knowledge of similar tools (e.g. IDL compiler for CORBA) would be beneficial. Documentation:: * [wiki:IPC Introduction to HelenOS IPC] * [wiki:AsyncSessions IPC sessions in HelenOS] * [wiki:Tracing Tracing IPC calls] Possible mentors:: HelenOS Core Team, Martin Decky, Jiri Svoboda" Jiri Svoboda 425 Implement support for Lemote Fuloong/Yeeloong (mips64) helenos/kernel/mips64 enhancement Martin Decky new 2012-03-07T16:26:39+01:00 2016-05-04T20:56:45+02:00 "Implement support for Lemote Fuloong and/or Yeeloong machines (mips64 little-endian architecture). Details:: Fuloong is a mini-PC and Yeeloong is a netbook built by Lemote and based on the Loongson 2F CPU, which is itself a MIPS64-derived CPU developed at the Institute of Computing Technology at Chinese Academy of Sciences. Both machines use industry-standard components such as a PCI bus, USB, SATA, etc. They use the U-boot boot loader as a firmware and runs Linux. The goal of this ticket is to implement at least a basic support for either machine, i.e. support for booting, memory management, framebuffer output, PCI support, USB support and USB keyboard support. What Gains and Benefits will this bring?:: The Lemote machines are decent and state-of-the-art desktop/netbook machines with a 64bit MIPS CPU and very popular in the academia not only in China. Implementing HelenOS support for the Loongson CPU should hint any possible portability issues in HelenOS and it should also improve some minor functionality aspects of the kernel. Difficulty:: High Required skills:: A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation in English and Chinese, source code of other operating system projects and emulators). Documentation:: * [http://dev.lemote.com/ Lemote development resources] * [http://dev.lemote.com/wiki/ Lemote wiki] * [http://dev.lemote.com/trac/ Lemote-related projects] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 427 Tickless/event-driven kernel helenos/kernel/generic mainline enhancement Martin Decky new 2012-03-08T20:40:06+01:00 2016-05-04T20:42:49+02:00 "The kernels of many operating systems have already switched or are planning to switch to tickless operation (i.e. avoiding strictly periodic timer interrupts and scheduling timers on-demand). The benefits are lower overhead, better power-saving possibilities (even without any specific power management features) and a more natural design of the timers without a fixed timer period. The most significant drawback is naturally more complex timer bookkeeping, but as empirical evidence shows it is manageable. **Clarification:** The term ""tickless"" is usually understood as a means to avoid periodic timer interrupts in idle states. However, an ""event-driven"" kernel design can actually go even further and avoid all periodic timer interrupts. See the following references in the context of Linux: * http://linuxplumbersconf.org/ocw/proposals/103 * http://events.linuxfoundation.org/sites/events/files/eeus13_mckenney.pdf * http://events.linuxfoundation.org/sites/events/files/slides/BareMetalLPC.2013.09.22a_0.pdf" Martin Decky 432 Rock Ridge extension in cdfs helenos/unspecified mainline enhancement new 2012-03-26T17:32:01+02:00 2012-04-17T17:50:15+02:00 The cdfs server that implements the ISO 9660 file system for HelenOS VFS needs to support the long file names defined by the Rock Ridge extension. Jiri Svoboda 433 Restartable system calls helenos/kernel/generic mainline enhancement Jakub Jermář new 2012-03-27T15:29:04+02:00 2012-03-27T15:29:04+02:00 "There are several scenarios where we want to examine or set/modify the state of a thread, including checkpoint and resume, migration and debugging. There are certain points in the thread's execution where its state is simple and well-known to the system, such as when crossing the boundary between user and kernel space. However, some system calls can block indefinitely and we want to be able to access the thread state upon user request, within some reasonable time limit (e.g. as soon as the alloted time quantum expires, within one clock tick, etc). In general the state of a thread running in the kernel is more complex and could be described by the contents of the kernel stack and current register state. This state representation is much larger and is not portable between system restarts and different system nodes (in the hypothetical scenario of migrating between cluster nodes). Fortunately, SPARTAN system calls have relatively simple behavior. Most of them simply perform some action (side effect), but do not block indefinitely under normal conditions. For such system calls we can simply wait until they complete. Most system calls that are designed to sleep (thread_usleep, thread_udelay, futex_sleep, ipc_wait) will only have some visible side effect after they finish the sleep. Therefore they could be modified to be abortable/restartable. This would mean adding an extra return status to the sleeping primitives being used and adjusting the functions in the call stack to handle the condition and unroll the operation. The system calls that might cause problems are ipc_call_sync_{fast|slow}. These first send a message and then wait for answer. Either these need to be eliminated (if they are not really needed) or some special provisions must be made for handling these. This enhancement would simplify Udebug - it would no longer have need for 'stoppable' sections - we could restart the system calls instead and stop at a specific point in the syscall code. It would also allow a simpler and more robust implementation of thread checkpoint/resume (compared to the implementation in the thesis [http://is.cuni.cz/eng/studium/dipl_st/index.php?id=&tid=&do=main&doo=detail&did=47846 Task snapshotting in HelenOS]) - one that would allow safe checkpoint/resume across different kernel revisions and different cluster nodes. An alternate approach / one possibility for solving the problem of synchronous IPC calls would be to have a few extra, well-defined CPR points in the kernel. This does not seem as elegant as the solution proposed above, though." Jiri Svoboda 436 Cursor not always visible during movement helenos/srv/console mainline defect new 2012-04-05T22:35:12+02:00 2020-01-30T14:40:33+01:00 "After the last rewrite of the console server, the cursor is not made visible when moving. Previously the cursor would become immediately visible upon movement regardless of its current blink phase. Now when we move the cursor (e.g. arrow keys in bdsh), it will stay on or off depending on how it was in the beginning. This can be pretty confusing/annoying." Jiri Svoboda 438 Indexed sequence ADT helenos/unspecified mainline enhancement new 2012-04-12T16:21:58+02:00 2018-03-04T19:26:24+01:00 "A sequence (list) is an ordered collection of elements. The elements have no keys, just values. Sequences can be split at any element, concatenated, new element can be prepended/appended. An indexed sequence also allows to find an element efficiently by its index (numerical position) in the sequence and, conversely, to obtain the index of an element. A weighed indexed sequence also assigns (non-negative) weight (or width) to each element, in which case for indexing purposes an element counts as much as its weight/width is. Implement a weighed indexed sequence ADT in HelenOS libc. A weighed indexed sequence can be efficiently implemented as slightly modified self-balancing search tree. The handling of the keys is slightly different and the algorithm needs to keep track of weights of subtrees during the rotations. Indexed sequences and weighed indexes sequences are useful for destructive sequence editors, such as: * text/file editors * audio editors * accessing characters UTF-8 strings by character index Intended use: The current sheet implementation in the text editor is inefficient for larger files. It could be easily re-implemented as an indexed sequence of lines. Then it would work well for files with large number of lines (although not for files with very few very long lines). " Jiri Svoboda 440 Serial terminal emulation/deemulation library helenos/unspecified mainline enhancement Jiri Svoboda accepted 2012-04-17T18:12:01+02:00 2020-01-30T14:40:15+01:00 "In the world of UNIX-like operating systems command-line applications can make use of a pseudo-graphical UI via [n]curses or a similar library. This provides commands like move cursor, set color, etc. Conversely keyboard input (including some control keys like arrows, Page Up, etc) can be retrieved by the application. However only a dumb serial line / character device is assumed to connect the application to the console. Therefore all the pseudo-graphical commands are marshaled into a character stream (escape sequences) by the curses library and unmarshaled by the console. Conversely the keyboard input is marshaled by the console and unmarshaled by the curses library. This is the common cause of many problems. In HelenOS the application talks directly to the console via an IPC interface (much like in some other OS). This has many benefits, but there is one catch: How do we communicate with the UNIX-like world that expects serial terminals? There are two cases: * Console is driven by something that normally talks to a serial terminal (1) * A serial terminal [emulator] talks to something which expects a console (2) The examples of (1) are: ported application that generates terminal sequences manually, remote stty client (telnet, ssh). The examples of (2) are: remote serial terminal server (ssh server, telnet server), HelenOS serial HID (such as in msim, GXemul, ski, serial line). The latter case (2) is more difficult, because an input method needs to be implemented to extend the capabilities of the serial input to the capabilities of a keyboard device (such as key combos). Currently the serial terminal-related functionality in HelenOS is scattered about. We need a library that would be able to translate from and to serial terminal escape sequences (for both graphical commands and key inputs) for different terminal types. We also need an input method for serial terminals. This library/libraries could then be used in existing code (serial HID, remcons) and future code (telnet/ssh client, stty emulator for msim). " Jiri Svoboda 443 IPC hangup should awaken blocked clients helenos/lib/c mainline defect Jakub Jermář new 2012-04-24T15:05:17+02:00 2017-11-11T17:46:50+01:00 "There is a difference between the behavior on IPC_M_PHONE_HUNGUP for blocked servers and blocked clients. For our purpose, servers are fibril blocked in `async_get_call_timeout()` and clients are fibrils blocked in `async_wait_for()` or `async_wait_timeout()`. The async framework will attempt to wake up a blocked server from `route_call()` but it will let a blocked client continue to sleep. We should fix this for the blocked clients and, also, callers of `fibril_condvar_wait()` too so that if the fibril receives IPC_M_PHONE_HUNGUP, the blocking fibril will interrupt its sleep with a return value indicating the sleep was interrupted." Jakub Jermář 445 slab_reclaim() holds a spinlock when making calls to frame allocator helenos/kernel/generic mainline enhancement Jakub Jermář new 2012-04-24T15:35:49+02:00 2017-11-11T16:54:05+01:00 "`slab_reclaim()` holds a spinlock when making calls to frame allocator. It is actually possible that multiple spinlocks are held along the call path from `slab_reclaim()` to `frame_free()`. This fact prevents the frame allocator from using normal MUTEX_PASSIVE variant of mutexes in favor of the weird MUTEX_ACTIVE variant of mutexes when waiting for physical memory. The solution is either to drop all mutexes before delving into the frame allocator from `slab_reclaim()` and carefully reacquiring them after the return, or to modify functions called from `slab_reclaim()` to free memory to a local list which will be processed later on in `slab_reclaim()` after all spinlocks are released. The later is complicated by the fact that slab caches may have user-defined destructors, in which the user can call slab/frame_free() directly. " Jakub Jermář 446 High memory corrodes memory reservations helenos/unspecified mainline defect new 2012-04-24T15:57:25+02:00 2017-11-11T17:47:03+01:00 "Memory reservations were introduced before the physical memory was split into low memory and high memory. In order to make use of the high memory, we started to see the following pattern in the kernel: {{{ frame = (uintptr_t) frame_alloc(ONE_FRAME, FRAME_HIGHMEM | FRAME_ATOMIC); if (frame) { page = km_map(frame, PAGE_SIZE, PAGE_READ | PAGE_WRITE); } else { frame = (uintptr_t) frame_alloc(ONE_FRAME, FRAME_LOWMEM); page = PA2KA(frame); } }}} Now, the problem with this is that the first non-blocking allocation request for high memory may fail, so that the caller will default to allocating from low memory. Because reservations do not differentiate between low and high memory, the caller may sleep in the second blocking allocation request. It can happen that the reserved memory will become soon available in high memory, but since the caller now only waits for low memory, it will never wake up. We need to be able to merge the allocation request into a single, atomic allocation. This may require making memory reservations aware of the two kinds of memory and will likely change the mechanism of waiting for physical memory." Jakub Jermář 447 Boot from persistent file system helenos/unspecified mainline enhancement new 2012-04-26T18:47:44+02:00 2024-03-06T12:41:04+01:00 "Currently we always boot HelenOS from the initial ram disk (initrd). The boot stage (bootimage, Multiboot, etc.) loads the kernel, a set of initial servers and the initial ram disk. This initial ram disk contains the entire system image. It is possible to mount a persistent file system to a non-root location, though. This has several drawbacks. As the system becomes larger the boot takes longer since the entire initial ram disk must be loaded immediately (and possibly decompressed and also deserialized, if it's using tmpfs). If we placed configuration files in the image they would not be preserved across reboots. It is currently possible to set up a HelenOS system image manually on a persistent file system. However this assumes the set of initial servers is able to mount the root file system (without using a file system). This only works with non-DDF driver as Devman requires the file system (with driver binaries and .ma files). This means that, for example, booting the system directly from an ATA disk will only work until #415 (Convert the ATA block device driver into a regular DDF driver) is implemented. There are two main proposed strategies for making persistent boot work in this case: * extend DDF to work (possibly in a limited fashion) even without a root file system * use a two-stage boot with initrd and then, somehow, switch to the persistent file system (initrd needs to contain a sufficiently large subset of the system that allows mounting the persistent file system) There were several variants proposed to address the 'switch' from initrd to the persistent file system: * mount the persistent file system in a non-root (/) location, ask all servers that are already running (and using the file system) to switch to the new location * same as above, but combined with chrooting into the persistent file system so that it becomes root (/) * swap the initrd with the persistent file system transparently in VFS (pivot mount), as seen in Linux We need to design an implement a strategy for booting from persistent file systems. An interesting read is [http://lwn.net/Articles/412131/ Ghosts of Unix past, part 2: Conflated designs] which suggests an interesting alternative approach to pivot mounts, lazy unmounts etc. Also [http://lwn.net/Articles/414618/ Ghosts of Unix past, part 3: Unfixable designs] has more on Linux mounting and signals." Jiri Svoboda 448 Forced vs. non-forced administrative device removal helenos/unspecified mainline enhancement new 2012-04-27T17:56:50+02:00 2018-10-15T10:21:54+02:00 "Similar to an unmount operation, administrative device removal (devctl offline) can be forced or non-forced. Non-forced removal will fail if there are any clients connected to an exposed function [of some child of a nexus device]. Forced removal must succeed even if there are active clients. Extend DDF to distinguish between forced an non-forced removal (e.g. by adding a simple flag to the relevant calls). Ideally all drivers should support both. Forced removal is slightly trickier, because it must succeed at any time, even if the driver is actively processing some transactions. " Jiri Svoboda 460 Extend devctl with driver management helenos/unspecified mainline enhancement Jiri Svoboda assigned 2012-05-08T11:27:39+02:00 2017-10-20T15:24:18+02:00 "Currently on a running system if I feel like a driver was not attached because I am missing a PCI ID in one of my driver `*.ma` files, I can edit that file, but then there is no way to tell the Device manager to reload that `.ma` file. `devctl` could be extended with a command to reload the `.ma` file for a specific driver (or all drivers), possibly also with a command to list all available drivers (loaded drivers), load or unload a driver." Jiri Svoboda 461 No interrupts for uspace on real hardware when SMP enabled helenos/srv/irc mainline defect Jakub Jermář accepted 2012-05-09T11:23:38+02:00 2017-11-11T17:42:14+01:00 As of mainline,1487, no USB devices work for me at all on bare metal (either Sony Vaio with UHCI or AMD workstation with OHCI). If I plug in a device, nothing seems to happen. The device does not power on and it does not appear in the device tree, I also don't see anything in the USB logs. Tried this with several different devices (keyboard, mouse, mass storage). Jiri Svoboda 464 FPU preserved registers not preserved across fibril switches helenos/lib/c mainline defect Jakub Jermář new 2012-06-20T14:59:11+02:00 2017-11-11T17:40:44+01:00 "To make it possible for two fibrils to do floating point math without influencing each other, it is necessary to save/restore the preserved FPU context registers, as prescribed by the respective ABI. The preservation of preserved FPU registers has not been consistently implemented across all architectures. E.g. mips32 and ia64 seem to be preserving some FPU state, while sparc64, ia32 and amd64 don't. Scratch FPU registers don't need to be preserved." Jakub Jermář 466 Command-specific tab completion in kernel console helenos/kernel/generic mainline enhancement Aurelio Colosimo assigned 2012-07-17T12:03:19+02:00 2016-03-16T14:44:05+01:00 "Current mainline ([changeset:mainline,1539 rev. 1539]) offers tab completion of kernel console commands and hints listing (see #50). The actual command is completed from list of commands. For arguments, symbol table is searched. It would be more convenient to use this completion for `call*` commands only and provide context-specific completion for other commands. For example, `test` would offer list of existing tests while `ipc` could list existing tasks. For the `ipc` or similar commands, the hint listing could be made more user-friendly by printing task name next to its number. Printing the hints in more columns could be a next step. Implementation note (idea): to avoid code repetition, command structure could be extended with two callback function - one for getting next hint and one for retrieving hits count for given prefix. " Vojtech Horky 467 Use of bit fields in AHCI driver is not clearly justified based on the specs helenos/unspecified mainline defect new 2012-07-19T17:11:58+02:00 2012-07-20T13:56:35+02:00 "The new AHCI driver (ahci_hw.h) uses C bit fields to describe hardware registers. C bit fields are not portable, as the packing of bit fields into words depends on the processor-specific ABI. For example, for SPARC and x86 this order is reverse (another question, of course, is the byte-endianness of the words we are packing into). Drivers should work across disparate CPU architectures. I suggest replacing the use of bit fields with bitwise operations, with the help of bitops.h." Jiri Svoboda 468 Implement IPC_M_DATA_READ_WRITE helenos/kernel/generic mainline enhancement Jakub Jermář new 2012-07-31T14:13:28+02:00 2016-05-04T20:41:47+02:00 "Implement IPC_M_DATA_READ_WRITE as a atomic bidirectional combination of IPC_M_DATA_READ and IPC_M_DATA_WRITE. This should serve both as an optimization and as a precaution against a DoS attack described in the discussion bellow: http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-July/008540.html http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-July/008541.html" Martin Decky 470 Mac Mini (Mid 2011) boot issues helenos/boot/amd64 mainline defect new 2012-08-07T19:14:38+02:00 2018-10-12T18:46:53+02:00 "When trying to boot HelenOS on the Mac Mini (Mid 2011), the BIOS GRUB image fails completely (not even GRUB is loaded). The EFI GRUB image boots fine. After the boot, ns is killed in as_area_create(), possibly due to physical memory corruption or faulty physical memory map used by the kernel. The root cause might be either in EFI GRUB or in SPARTAN." Martin Decky 471 Dell PowerEdge 7150 PS/2 keyboard input not working helenos/srv/kbd mainline defect new 2012-08-07T19:19:23+02:00 2018-10-12T19:10:15+02:00 As of [changeset:mainline,1560], the PS/2 keyboard input on Dell PowerEdge 7150 IA-64 machine is not working (in user space). This might have something to do with the move of the PS/2 and/or keyboard driver to DDF. Martin Decky 472 PCI bus not detected on iMac G4 helenos/drv/pciintel mainline defect new 2012-08-07T19:41:54+02:00 2017-11-11T17:39:31+01:00 The PCI bus is not detected on iMac G4 (Flat Panel), thus rendering the machine without any user input (it is USB HID only). The reason is that the PCI bus configuration space physical address is not hardwired on this platform, but needs to be decoded from the OFW device tree. Martin Decky 474 Mac Pro (Early 2009) UHCI keyboard error helenos/srv/kbd mainline defect new 2012-08-07T23:20:38+02:00 2018-10-12T18:58:16+02:00 The USB 1.1 HID keyboard is not operational on Mac Pro 4.1 (Early 2009) despite being connected via UHCI. Martin Decky 480 VFS deadlocks when FS calles VFS operation (namespace_rwlock) helenos/srv/vfs mainline enhancement Jakub Jermář new 2012-08-21T13:12:57+02:00 2012-08-21T13:12:57+02:00 "Jakub on mailing list: The solution with a global namespace lock traded flexibility for simplicity. When your fs implementation uses the VFS input interface (e.g. via libc wrappers) it always creates a possibility for a deadlock because it creates a loop and there may always be some locks taken or resources consumed along the codepaths that form the loop. The more operations this loop involves, the more likely it is that there will be a deadlock. We should probably change this behavior and remove this inflexibility as it is a potential security problem at the same time; if we want to have unprivileged file systems (or just privileged less than VFS), VFS needs to be able to gracefully survive someone's attempt to do crazy stuff. http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008685.html http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008691.html http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008692.html http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008693.html" Zdenek Bouska 494 Need abortable async_get_call() variant helenos/lib/c mainline enhancement Jakub Jermář new 2012-09-11T12:14:14+02:00 2012-09-11T12:14:53+02:00 "There is an async_get_call() which will block forever when no call is received, there is also async_get_call_timeout() which will terminate after a pre-specified timeout has expired. In some cases, such as serving a remote console (see con_srv.c) we need to terminate the message loop when the network connection is closed, but the console client is not sending any messages. Currently async_get_call_timeout() is used as a work around. What we need is a variant of async_get_call() that can be aborted at the caller's discretion. Likely the caller will need to pass (or obtain) some object/handle that can be later used to identify the wait that should be aborted. One suggestion was passing a condition variable that will be later signaled, but there may be other (better?) options. " Jiri Svoboda 495 A keypress still required for shell to return control after a task is killed helenos/unspecified mainline defect new 2012-09-16T09:32:10+02:00 2017-11-11T17:38:14+01:00 Even after [changeset:mainline,1665], a keypress is needed for a shell to display the termination message and to return control after a task spawned from it is killed. Jakub Jermář 496 Provide library implementations for common CRC's helenos/lib/c mainline enhancement new 2012-09-23T11:46:33+02:00 2017-11-11T16:55:02+01:00 Provide implementations for standard CRC's such as CRC-16-ANSI in a library (libc or even a specialized library of some sort). This will prevent duplication of the same CRC's in various subsystems. Jakub Jermář 502 Zero configuration networking helenos/unspecified mainline enhancement new 2012-11-30T17:14:05+01:00 2013-04-23T15:18:26+02:00 "[http://en.wikipedia.org/wiki/Zeroconf Zero configuration networking] allows automagic configuration of network settings, host name resolution and service discovery in a network without the need for central administration/configuration. This is very convenient for small networks with mutual trust among participants (such as home networks). Examples of current implementations are Windows uPNP, Mac OS X Bonjour, and the free software implementation [http://en.wikipedia.org/wiki/Avahi_%28software%29 Avahi]. Sadly there is no definite IETF standard. HelenOS should support Zeroconf out of the box (not saying it should be enabled by default). Suggest implementation should be iteroperable with Avahi (mDNS, DNS-SD, IPV4LL). * IPv4LL #536 * Multicast DNS #537 * DNS-SD " Jiri Svoboda 505 Remcons should implement the console protocol fully helenos/unspecified mainline enhancement Jiri Svoboda accepted 2012-12-06T00:33:08+01:00 2020-01-30T14:39:52+01:00 Currently remcons only supports plain text output, but not other console operations (such as setting attributes, cursor position and visibility). Jiri Svoboda 508 Parallel sessions don't mix well with call forwarding helenos/lib/c mainline defect Jakub Jermář new 2013-01-09T09:10:18+01:00 2017-11-12T11:34:19+01:00 "As of [changeset:mainline,1739], there appear to be two problems with parallel sessions: * `devman_device_connect(EXCHANGE_PARALLEL, ...)` works only by accident * `devman_parent_device_connect(EXCHANGE_PARALLEL, ...)` does not work at all The fundamental issue here is that the first session phone gets created as a result of forwarding the `IPC_M_CONNECT_ME_TO` call through `devman`, which applies some transformations to it prior to forwarding it further along to the destination driver. In contrast, all additional phones are cloned from the first one, which is already directly connected to the respective driver, using the remembered original session arguments. The problem here is that in this latter case, the arguments don't go through the same set of transformations as in the former case. As a result of this, `devman_device_connect()` works only because the device handle is still passed unmodified as ARG2 and both the translated and unmodified methods accidentally lead to the same behaviour. On the other hand, `devman_parent_device_connect()` will fail on the first attempt to clone the original session phone because the numeric value of the original method (i.e. DEVMAN_CONNECT_TO_PARENTS_DEVICE) is not recognized by libdrv's driver_connection(), which in turn returns ENOENT. In addition, the handle does not get translated as is necessary, which would also likely make the function fail." Jakub Jermář 512 Implement/port an NTP client helenos/unspecified mainline enhancement new 2013-01-26T19:14:47+01:00 2013-01-26T19:14:47+01:00 Because a hardware real time clock may not be available on some platforms and requires hardware driver, a simple NTP client can be used as a platfrom-independent substitute for networked computers. Jiří Zárevúcky 516 CPU hotplug helenos/kernel/generic mainline enhancement Jakub Jermář new 2013-03-06T16:06:18+01:00 2013-03-06T16:06:18+01:00 Add the ability to offline and online a CPU while the system is running (e.g. using {{{devctl}}}). This might be a good topic for a bachelor or master thesis (for that purpose it could be combined with memory hotplug). Jiri Svoboda 517 Port the clang (LLVM) compiler to HelenOS helenos/app/other mainline enhancement new 2013-03-08T10:01:30+01:00 2016-02-13T16:01:45+01:00 "Port the [http://clang.llvm.org/ clang] (C frontend to LLVM) compiler to run in HelenOS. Details:: Integrate a reasonably recent version of clang into HelenOS so that it can be used to compile C programs from within HelenOS. [[br]][[br]] clang is partially written in C++ and thus it would be necessary to introduce a rudimentary support for C++ into HelenOS libraries. The first requirement is a C++ cross-compiler but that is already prepared by the toolchain script. Next is support for some C++ constructs in HelenOS libraries (exceptions and stack unwinding) that is missing but shall not be that difficult to add. Last thing is the STL but there are many implementations around and it shall not be a big problem to find some BSD-licensed that would be easily portable. Performance of the STL is currently not an issue, the main factor shall be the simplicity of bringing it into HelenOS. What Gains and Benefits will this bring?:: One of the strategic goals for HelenOS is becoming self-hosting. During previous GSoC, a PCC compiler (Portable C compiler) was ported to HelenOS but it is not possible to compile all sources with it, while clang is able to compile kernel completely and there are only very minor issues with few userspace files. Thus, having clang it would be possible to compile whole HelenOS inside HelenOS (there is already a working port of GNU binutils in HelenOS). [[br]][[br]] There is a parallel effort to bring GCC to HelenOS and it would be very nice to have the possibility to choose between more compilers when compiling HelenOS. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C and C++ language and the ability to survive in a non-standard non-POSIX application environment. The applicant should also be familiar with the basic concepts behind compilers and the build toolchain. Documentation:: * [DeveloperDocs#Clanguage C language standard] * [BinutilsMaintenance Maintenance instructions for another ported application (binutils)] * [http://clang.llvm.org/ clang homepage] Possible mentors:: HelenOS Core Team, Vojtech Horky" Vojtech Horky 520 Driver for VESA-compatible graphics adapter helenos/gui mainline enhancement new 2013-03-13T19:26:22+01:00 2020-01-30T14:39:39+01:00 "Implement a driver for a VESA-compatible graphics card pluggable into the HelenOS graphics stack. Details:: HelenOS has its own compositing server but it currently depends on kernel to properly set the mode of the graphics card. Effectively this means that the configuration of the resolution is done at compile time (through a configuration menu option) and there is no way to e.g. change the resolution at run-time. [[br]][[br]] The goal of this ticket is to implement a driver for a graphics card that would be pluggable to the graphics stack and to the driver framework implemented in HelenOS and that would allow the most common operations with the graphics card. Because there is no graphics driver currently implemented in HelenOS, it is reasonable to create a rather simple variant of the driver that would not use any advanced vendor-dependent features but that would only use the VESA BIOS extensions to switch the resolution. The implemented driver shall support following features: Detect possible resolutions and inform the graphics stack about them. Provide an user interface to change the resolution, color depth and possibly refresh rate. Implement the graphics mode-setting. Detection of a second monitor would be a very nice feature. [[br]][[br]] Since the protected-mode interface of the VESA BIOS is rather complicated and generally unreliable. the preferred way is to run the real-mode VESA BIOS code in a sandbox environment (e.g. using an x86 emulator). This is a common approach in the majority of operating systems and provides the best degree of compatibility. What Gains and Benefits will this bring?:: The current VESA BIOS mode setting code in HelenOS is a very minimalistic and involves a boot-time jump to real mode and a kernel driver. Creating a full-fledged graphics driver in user space would allow to remove the kernel driver and reduce the number of relict drivers still present in kernel. It is expected that the user space driver would provide extra features (run-time detection of possible resolution, etc.) that are not available in the kernel driver and that would improve the experience when using HelenOS GUI. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial. Documentation:: * [wiki:DeveloperDocs/Peripherals#Graphics Developer documentation] * [wiki:UsersGuide/GUI GUI user's guide] * [http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html Announcement of the graphics stack at HelenOS mailing list] * [https://code.launchpad.net/~petr-koupy/helenos/gui lp:~petr-koupy/helenos/gui] (original GUI branch) Possible mentors:: HelenOS Core Team, Martin Decky" Vojtech Horky 524 Implement support for Ben NanoNote (mips32) helenos/kernel/mips32 mainline enhancement Martin Decky new 2013-03-28T18:23:15+01:00 2016-05-04T20:44:27+02:00 "Implement support for the Ben !NanoNote small form factor computer (mips32 little-endian architecture). Details:: Ben !NanoNote is a small form factor portable computer based on the Ingenic Semiconductor JZ4740 SoC (MIPS-II compatible 32bit CPU). The machine is extremely well documented (there are practically no proprietary undocumented hardware components) and while its extensibility is limited to an SDIO port, it can be used as a model hardware for HelenOS since a complete support for it is within the reach of a single trimester work. What Gains and Benefits will this bring?:: Ben !NanoNote would be an ideal demonstrator for HelenOS because it is portable, compact and a complete support for all internal components and common peripherals is within practical reach. Difficulty:: Medium to High Required skills:: A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation, source code of other operating system projects). Documentation:: * [http://en.qi-hardware.com/wiki/Ben_NanoNote Official Ben NanoNote site with complete documentation] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 525 Service manager helenos/app/init mainline enhancement Michal Koutny accepted 2013-03-28T19:29:55+01:00 2016-05-04T20:33:32+02:00 "Design and implement a replacement for the current init task, i. e. a full-fledged service manager. Details:: The current init task in HelenOS is very roughly equivalent to the Unix init process. Its purpose is to coordinate the bootstrap sequence in user space, start all necessary services and components of the user session. However, the current init is even more rudimentary than the traditional SysV init: it is a more-or-less sequential program that performs some hard-coded actions with only limited and mostly compile-time configuration options. The goal of this ticket is to design and implement a general bootstrap and service managing infrastructure for HelenOS that would allow a flexible and declarative way of configuring the bootstrap process and services, their run-time monitoring, starting, stopping and (possibly automatic) restarting. While using different implementation means, the infrastructure should provide similar features as [http://www.freedesktop.org/wiki/Software/systemd systemd for Linux], including (but not limited to) dependency management and concurrent execution of independent tasks. The goal is not to port systemd to HelenOS, but to reimplement from scratch its non-trivial features. What Gains and Benefits will this bring?:: Even in monolithic systems the importance of a reliable service managing infrastructure is becoming more and more obvious. In a microkernel system, where even the basic system functionality depends on many components and services, a reliable and configurable service management is even more important. This ticket will enable HelenOS to move past the rudimentary hard-coded service configuration to a more flexible open infrastructure. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C languages and the ability to survive in a non-standard non-POSIX application environment. Documentation:: * [http://www.freedesktop.org/wiki/Software/systemd systemd] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 526 Port DOSBox to HelenOS helenos/app/other mainline enhancement new 2013-03-28T19:59:32+01:00 2016-05-04T20:34:27+02:00 "Port the [http://www.dosbox.com/ DOSBox x86 emulator] to HelenOS Details:: DOSBox is a special-purpose x86 emulator targeting primarily 1980's and 1990's DOS games and applications. It contains an integrated emulator of MS-DOS system calls, command interpreter and various other components. It tries to faithfully emulate specific hardware devices (e.g. VGA and SVGA graphics cards, various sound cards, etc.) while several other hardware models are extremely simplified. This allows DOSBox to run many real-mode and protected-mode applications from the ""golden"" MS-DOS era, but it is not a complete machine emulator in the usual sense. The goal is to port DOSBox to HelenOS (using the native HelenOS graphics stack), preserving the most important features while possibly omitting others (e.g. the sound output). The solution must provide a functional emulator with at least rudimentary graphical output. What Gains and Benefits will this bring?:: DOSBox would be a great application for testing and optimization of the brand new graphics stack of HelenOS. And of course, the basic possibility to play some vintage DOS games in HelenOS might make the system more attractive for hobbyists. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX application environment. Previous experience with the source code of DOSBox, SDL and other software components would be beneficial. Documentation:: * [http://www.dosbox.com/ DOSBox x86 emulator] * [http://sourceforge.net/projects/dosbox/files/dosbox/0.74/ DOSBox source code] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 528 Address space area leak in remote_ahci_read/write_blocks() helenos/lib/other mainline defect new 2013-04-04T13:28:35+02:00 2017-11-11T17:36:29+01:00 "It looks like there is a leak of a shared address space area in `remote_ahci_write_blocks()` and `remote_ahci_read_blocks()`: {{{ void *buf; async_share_out_finalize(cid, &buf); const uint64_t blocknum = (((uint64_t) (DEV_IPC_GET_ARG1(*call))) << 32) | (((uint64_t) (DEV_IPC_GET_ARG2(*call))) & 0xffffffff); const size_t cnt = (size_t) DEV_IPC_GET_ARG3(*call); const int ret = ahci_iface->read_blocks(fun, blocknum, cnt, buf); async_answer_0(callid, ret); } }}} `buf` is passed to `ahci_read/write_blocks()`, but it is never as_destroy()'ed in either of them nor in any other part of the ahci driver or `libdrv`." Jakub Jermář 535 tester print4 is slow on remcons helenos/unspecified mainline defect new 2013-04-18T09:15:00+02:00 2017-11-11T17:17:32+01:00 If you telnet into HelenOS and run 'tester print4' the output is excessively slow. It appears that each character is written out and sent over the network separately. Likely buffering that should be happening either in remcons or libc I/O code does not happen. Jiri Svoboda 536 IPv4 link-local address autoconfiguration helenos/unspecified mainline enhancement new 2013-04-23T15:03:50+02:00 2013-10-07T10:53:32+02:00 Implement IPv4 link-local adress autoconfiguration as per [http://tools.ietf.org/html/rfc3927 RFC 3927] (Dynamic Configuration of IPv4 Link-Local Addresses). Jiri Svoboda 537 Multicast DNS helenos/unspecified mainline enhancement new 2013-04-23T15:14:25+02:00 2013-04-30T20:54:09+02:00 "Implement the ability to configure an mDNS link-local host name (and announce it on the network), to resolve link-local host names, resolve conflicts, as per [http://tools.ietf.org/html/rfc6762 RFC 6762] Multicast DNS. Optionally, continuously monitor the link-local namespace (for an always up-to-date picture) and allow listing out all local host names." Jiri Svoboda 538 HTTP CONNECT proxy traversal helenos/unspecified mainline enhancement new 2013-05-21T16:01:35+02:00 2013-05-21T16:01:35+02:00 "The HTTP CONNECT method is described in IETF draft standard [http://tools.ietf.org/html/rfc2817 RFC 2817] sections 5.2 and 5.3. It can be used by a client to ask an HTTP proxy to create a TCP connection on its behalf, accross a restrictive router or firewall. Some existing applications have built-in support for HTTP CONNECT such as SSH. Support for this method can, however, be implemented in a way that is transparent to applications. Whenever a client makes a TCP connection, HTTP CONNECT should be used, if applicable. Some questions to consider: * where to implement this * how to configure which destinations (do not) require the use of a proxy " Jiri Svoboda 541 Hard real-time features helenos/unspecified mainline enhancement new 2013-06-11T16:32:50+02:00 2016-05-04T20:42:08+02:00 "Implement one or more features that are needed to support hard real-time workloads. Details:: This ticket summarizes the features that should be implemented in HelenOS in order to support hard real-time workloads, i.e. strict predictability in the time domain for specific tasks or threads. As is the case of other general-purpose operating systems with real-time extensions, the hard real-time features should not render the system unusable for common non-real-time workloads, both types of tasks should be able to run in the system at the same time (the non-real-time workloads would naturally occupy the idle time of the real-time workloads). The primary goal is to define classes of tasks or threads with their own real-time scheduling (either FIFO or round-robin) that can preempt non-real-time threads (including kernel threads). Next comes the API to actually run the real-time scheduled entities, either via a static off-line schedule for FIFO tasks or via a dynamic on-line scheduling for periodic and aperiodic tasks (rate monotonic, deadline monotonic, earliest deadline first algorithms). In order for the hard real-time tasks to be more than standalone isolated tasks, various features of the system need to be modified or adapted to be predictable in the time domain. This includes the synchronization primitives (priority inheritance, priority ceiling, immediate priority ceiling protocols), IPC (usually synchronous due to the predictability), memory management (predictable page fault handling), multicore scheduling (pinning of real-time tasks to specific CPUs), etc. Due to the specific nature of this ticket, the implementation should be accompanied by a reasonable body of text advocating the desired real-time guarantees of the implementation. What Gains and Benefits will this bring?:: Even a limited support for hard real-time workloads will allow HelenOS to be usable for many embedded use cases where time predictability (not necessarily for all system components) is a requirement. Difficutly:: Medium to High Required skills:: A successful applicant will need to have very good skills in programming in the C language and also a good knowledge of the real-time concepts and algorithms. Documentation:: * [http://en.wikipedia.org/wiki/Real-time_computing Real-time computing] * Giorgio C. Buttazo: Hard Real-time Computing Systems – Predictable Scheduling Algorithms and Applications, 2nd edition, ISBN: 978-0-387-23137-2, Springer Verlag, 2005 Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 547 VFS_IN_RENAME does not work with directories helenos/srv/vfs mainline defect Jiří Zárevúcky new 2013-07-28T21:24:57+02:00 2018-11-06T16:39:37+01:00 "Internally, VFS server implements RENAME as a sequence of link and unlink. However, at least the EXT4 filesystem does not support unlinking non-empty directories, even when other hard link exists. Furthermore, the filesystem implementation may choose to reject the second link entirely. Thus it would be helpful if filesystems implemented the rename operation directly, instead of playing with links like this." Jiří Zárevúcky 550 Driver wildcard matching helenos/unspecified mainline enhancement new 2013-08-22T15:55:51+02:00 2013-08-22T15:55:51+02:00 "Currently drivers are matched to device nodes based on exact string match (each driver declares a set of match IDs and each device node has a set of match IDs). Typically a bus driver encodes a set of properties to the match-ID string (e.g. vendor ID, device ID, class ID, subclass ID, etc.) Different drivers may match different subsets of these properties, e.g. a subclass driver will match the class ID, a driver for a specific device will match vendor ID and device ID, etc. This forces the bus driver to export one match-ID string for every possible property subset a device driver might want to match against. I.e. if we consider N properties for matching, the bus driver needs to export up to 2^N^-1 match-ID strings. This is not very elegant. One option would be to introduce some kind of wildcard-search, for example if the bus driver defines a device's match ID string to be {{{ vendor-id=a&device-id=b&class=c&subclass=d }}} a driver's match ID could be a pattern like: {{{ vendor-id=a&device-id=b&class=*&subclass=* }}} (or something completely different) There are different possibilities, depending whether the match ID would be considered a flat string or to have some structure understood by the framework, etc. " Jiri Svoboda 553 e1k support for 8086:1502 (82579LM Gigabit Network Connection rev 04) helenos/unspecified mainline enhancement new 2013-09-13T15:34:17+02:00 2018-12-04T16:14:58+01:00 "My Lenovo X230 has the following network adapter: {{{ 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) }}} the support for which should be added to e1k driver. " Jiri Svoboda 561 IPv6 stateless configuration helenos/unspecified mainline enhancement new 2013-10-06T23:29:56+02:00 2013-10-07T00:06:20+02:00 "Currently we automatically configure a link-local IPv6 address. Add support for router solicitation / router advertisement in order to get: * network prefix / globally routable address * default router address * DNS server address See * [http://tools.ietf.org/html/rfc4862 RFC 4862] IPv6 Stateless Address Autoconfiguration * [http://tools.ietf.org/html/rfc6106 RFC 6106] IPv6 Router Advertisement Options for DNS Configuration " Jiri Svoboda 562 Source and destination address selection helenos/unspecified mainline enhancement Jiri Svoboda accepted 2013-10-07T10:52:37+02:00 2013-10-16T21:24:55+02:00 "If you try to connect to or ping a host that has an AAAA DNS record (e.g. google.com), we will always try to use that regardless whether there is any (global-scope) IPv6 address configured. Thus on a host with only IPv4 connectivity this will fail. There are cases where we are faced with several alternatives for both source and destination address, such as: * IPv4 vs IPv6 * link-local vs. global-scope address (both IPv4 and IPv6) We need to devise some strategy for proper selection of source and destination address. For inspiration how this problem can be approached see * http://tools.ietf.org/html/rfc3484 (I don't think it's necessary to implement *exactly* this way, i.e. we don't necessarily need a configurable policy table)." Jiri Svoboda 564 Implement support for 9P helenos/srv/vfs mainline enhancement Jakub Jermář new 2013-10-29T05:51:07+01:00 2016-05-04T20:58:37+02:00 The design of the 9P network file protocol (originally from Plan 9) seems to map nicely to the design of HelenOS VFS. It could be a nice demonstrator of the capabilities of the VFS and networking stack, but it could be also quite practical (QEMU uses 9P over Virtio for native host/guest file system sharing). Martin Decky 571 Driver for Broadcom VideoCore IV (Raspberry Pi) helenos/drv/other mainline enhancement new 2014-02-09T13:58:50+01:00 2018-01-15T18:23:56+01:00 "Implement a driver for the graphics unit in Raspberry Pi pluggable into the HelenOS graphics stack. Details:: HelenOS can boot on Raspberry Pi but the output is currently limited to serial only. [[br]][[br]] The goal of this ticket is to implement a driver for the !VideoCore IV chip that would be pluggable to the graphics stack and to the device driver framework implemented in HelenOS. The driver should at least support the HDMI port of Raspberry Pi and setting the optimal graphics mode depending on the output device connected to the HDMI port. What Gains and Benefits will this bring?:: Currently HelenOS does not provide any form of graphical output when running on Raspberry Pi. Adding support for graphical output would improve the experience when using HelenOS on this platform. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial. Documentation:: * [wiki:UsersGuide/GUI GUI user's guide] * [http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html Announcement of the graphics stack at HelenOS mailing list] * [https://code.launchpad.net/~petr-koupy/helenos/gui lp:~petr-koupy/helenos/gui] (original GUI branch) * [http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf BCM2835 documentation] * [http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf VideoCore IV Architecture Reference Guide] Possible mentors:: HelenOS Core Team, Martin Decky" Vojtech Horky 572 USB DisplayLink driver helenos/drv/other mainline enhancement new 2014-02-10T10:55:14+01:00 2020-01-30T14:38:53+01:00 "Implement a driver for a !DisplayLink adapter pluggable into the HelenOS graphics stack. Details:: Although HelenOS has its own compositing server, the number of supported graphical adapters is rather low. On PCs, the compositor still relies on kernel to properly initialize the GPU, on other platforms the support is even more rudimentary. [[br]][[br]] The goal of this ticket is to implement a driver for a USB !DisplayLink adapter that would be pluggable to the graphics stack and to the device driver framework implemented in HelenOS. The driver should support at least proper mode setting (with optimal resolution detection) and unaccelerated graphics output. The driver should be also portable to any HelenOS platform that support the USB bus. What Gains and Benefits will this bring?:: Implementing a driver for graphical output over USB would allow to use HelenOS graphical interface on any platform with USB support. This would improve the experience when using HelenOS GUI in general. It would also open space for experiments with multi-monitor setup in HelenOS. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial. Documentation:: * [wiki:DeveloperDocs/Peripherals#Graphics Developer documentation (graphics)] * [wiki:DeveloperDocs/Peripherals#USB Developer documentation (USB)] * [wiki:UsersGuide/GUI GUI user's guide] * [http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html Announcement of the graphics stack at HelenOS mailing list] * [https://code.launchpad.net/~petr-koupy/helenos/gui lp:~petr-koupy/helenos/gui] (original GUI branch) Possible mentors:: HelenOS Core Team, Vojtech Horky" Vojtech Horky 576 Network file server and network file system client helenos/srv/vfs mainline enhancement Jakub Jermář new 2014-02-13T17:44:22+01:00 2016-06-06T16:50:26+02:00 "Implement and networked file server and networked file system client. Details:: The HelenOS networking stack is mature and there are some networked servers and clients already implemented, but the system still lacks an user-friendly way of accessing remote file systems and serving its own file system to remote hosts over the network. [[br]][[br]] The goal of this ticket is twofold: (a) Implementing a networked file server that would serve a part of the local file system in HelenOS to remote host over the network. (b) Implementing a file system client (a file system driver) that would allow to access some remote file server over the network and possibly mount the remote file storage as a file system. [[br]][[br]] Both the server and the client should support at least one of the following common communication protocols. The server and the client for HelenOS should also have at least some protocols in common in order to be interoperable. * SFTP * 9P * SMB * NFS What Gains and Benefits will this bring?:: Having a working and interoperable file server and file system client will have a huge number of benefits for HelenOS, ranging from easier debugging and testing (accessing the files of the running HelenOS system remotely and storing data to remote hosts) to practical day-to-day usability. Difficulty:: Medium to High Required skills:: A successful applicant will have good skills of programming in the C languages and the ability to survive in a non-standard non-POSIX application environment. Experience with networking in general and file sharing protocols in particular will be very beneficial. Documentation:: * [http://tools.ietf.org/search/draft-ietf-secsh-filexfer-13 SFTP protocol specification] * [http://plan9.bell-labs.com/sys/man/5/INDEX.html 9P protocol specification] * [http://msdn.microsoft.com/en-us/library/cc246231.aspx SMB protocol specification] * [https://www.ietf.org/rfc/rfc3530.txt NFSv4 protocol specification] Possible mentors:: HelenOS Core Team, Martin Decky" Martin Decky 577 AC'97 Audio driver helenos/drv/other mainline enhancement new 2014-02-16T07:32:24+01:00 2021-11-08T20:43:14+01:00 "Implement a driver for an audio device compliant with the AC'97 specification pluggable into the HelenOS audio subsystem (Hound). Details:: Although HelenOS has a sound server that can mix output from multiple applications, currently only Sound Blaster 16 and Intel HDA hardware is supported. This former is not practically usable on today's hardware outside of emulators such as QEMU. [[br]][[br]] The goal of this ticket is to implement a driver for AC'97 class of audio devices that would be pluggable into to the sound subsystem and to the device driver framework implemented in HelenOS. The driver should at least support audio playback on virtual devices emulated in VirtualBox and QEMU and optionally on actual hardware. [[br]][[br]] AC'97 devices are simpler than Intel HDA devices. This ticket should be considered an easier alternative to ticket #575. The difficulty can be further scaled down by limiting the scope to a specific AC'97 revision. Gains and Benefits:: Although replaced by the newer Intel HDA standard, the AC'97 devices were the de facto standard in previous generations of sound cards for PC. Implementing a driver for sound output output via Intel HD Audio would allow to use HelenOS sound system on real hardware, improving the user experience and overall usefulness of the system from the end-user point of view. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or sound system implementation would be beneficial, as well as the knowledge of I/O device architecture (PCI, MMIO, DMA). Documentation:: * [http://download.intel.com/support/motherboards/desktop/sb/ac97_r23.pdf Audio Codec ‘97] * [http://download.intel.com/design/chipsets/manuals/29802801.pdf Intel ® 82801AA (ICH) & Intel ® 82801AB (ICH0) I/O Controller Hub AC ’97] Possible mentors:: HelenOS Core Team, Jiri Svoboda" Jan Vesely 578 Graphical boot experience helenos/unspecified mainline enhancement new 2014-02-20T15:00:31+01:00 2020-01-30T14:38:22+01:00 "During a normal graphical boot the user should be presented with a seamless and non-disturbing graphical sequence. The exact sequence is a matter of taste, but could be something like - the screen is filled with background color - HelenOS logo is displayed - optionally some kind of progress indicator is displayed - seamless transition to fully initialized desktop On ia32/amd64, for example, this should be able to cover the boot process at the very least from the point the kernel starts up and sets a graphic mode. Mode switching in the middle of the boot process (which we don't do currently) should naturally be avoided. Boot messages from kernel and user space should not be displayed by default. For debugging purposes it's useful to be able to switch-over/fall-back to seeing the boot messages: - automatically when the boot process fails (*) - when the user pushes some key (e.g. Escape) - when the system is configured via a boot time or compile-time option to display the messages (*) This is probably the most difficult one as it means programatically determining all cases where the boot process failed." Jiri Svoboda 581 strftime depends on fringe standard behavior for UTF-8 correctness helenos/lib/c mainline defect Jakub Jermář new 2014-02-27T22:18:56+01:00 2017-11-11T17:17:16+01:00 "The current implementation of `strftime` assumes that bytes corresponds to characters in the formatting string. This (wrong) assumption simplifies the implementation but prevents safe use of this function with non-ASCII strings. The cleanest solution is probably to add new function with different name (similar to `strcpy` vs `str_cpy`) that is UTF-aware and put `strftime` into `libposix`." Vojtech Horky 582 printf() is unnecessarily non-standard in some cases helenos/lib/c mainline defect Jakub Jermář new 2014-02-27T23:53:52+01:00 2014-10-27T10:59:38+01:00 "In some cases, printf() discards bytes that are not valid UTF-8. Notably in case of ""%c"" specifier. The standard version copies uninterpreted bytes to the input without change, and there is no practical benefit from this departure. It is likely there are other non-standard behaviors, so it may be beneficial to find those cases and align them with recent POSIX specification." Jiří Zárevúcky 584 USB still not working on Dell PowerEdge 3250 (ia64) helenos/drv/uhci mainline defect new 2014-04-11T12:03:03+02:00 2017-11-12T14:30:08+01:00 "As of mainline,2094, USB is still not functional on the Itanium PE 3250 server from our [wiki:Lab]. After UHCI HC is detected, the uhci driver reports the following error: {{{ [uhci] error: UHCI hardware failure!. }}} See the attached screenshot for more details. " Jakub Jermář 586 HelenOS on SPARC Enterprise T5120 helenos/unspecified mainline enhancement new 2014-05-22T17:02:26+02:00 2016-01-07T13:30:14+01:00 "Make HelenOS boot on T5120. Currently we get: {{{ SPARC Enterprise T5120, No Keyboard Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. OpenBoot 4.33.6, 8192 MB memory available, Serial #xxxxxxx. ...... 1000 Mbps full duplex Link up Timed out waiting for BOOTP/DHCP reply HelenOS bootloader, release 0.5.0 (Fajtl), revision 2112M (martin@decky.cz-20140520143617-mltwrvqip46ugkt7) Built on 2014-05-22 15:19:09 for sparc64 Copyright (c) 2001-2014 HelenOS project Error: No physical memory detected, halting. }}}" Jiri Svoboda 590 Logset should display registered logs helenos/srv/logger mainline enhancement new 2014-07-01T18:56:00+02:00 2014-07-01T18:56:00+02:00 "Currently it is not possible to tell on a running system which log names are available for use with 'logset' - there is no file in /log unless a message has been logged. So it is typically not useful if you want to increase logging level for a client that has been silent so far. Logset should allow displaying the list of registered logs plus their current logging level." Jiri Svoboda 593 IP datagram reassembly needs to flush datagrams/fragments after some time helenos/net/inet mainline defect Jiri Svoboda new 2014-07-18T11:19:59+02:00 2017-09-06T09:40:26+02:00 "Currently IP datagram reassembly will retain the datagram/fragment records forever if the datagram is not completed and delivered. This leads to increased memory usage over time and could be exploited for a DoS attack. There needs to be some kind of a timeout mechanism so that old datagrams/fragments are discarded eventually." Jiri Svoboda 598 cdfs initial ramdisk helenos/unspecified mainline enhancement new 2014-08-18T15:05:51+02:00 2017-11-11T16:56:13+01:00 Now that cdfs supports long filenames it is usable for the initial ramdisk. Since we already depend on an external utility to generate ISO filesystem for the CD's filesystem, this should be fairly straight-forward. Jiri Svoboda 599 Ultimate way to prevent the decrementer from underflowing helenos/kernel/ppc32 mainline defect Martin Decky new 2014-08-28T19:11:26+02:00 2017-11-11T17:33:55+01:00 "In `kernel/arch/ppc32/src/asm.S`, there is: {{{ iret_syscall: /* Reset decrementer */ li r31, 1000 mtdec r31 }}} This is definitely wrong, especially now when the kernel can program the decrementer with a proper value to achieve its own HZ `clock()` frequency. A more systematic approach for preventing the decrementer from underflowing and missing the decrementer exception is needed." Jakub Jermář 601 Cannot activate kernel console via hotkey on Lenovo Thinkpad X230 helenos/unspecified mainline defect new 2014-09-30T16:48:10+02:00 2017-11-11T17:33:34+01:00 "[changeset:mainline,2257] made Pause/Break the activation key for the kernel console. Unfortunately the Lenovo Thinkpad X230 (and I assume this applies at least to all of the X series) doesn't have the Pause/Break key (not even as a Fn- combo). While this could be considered a Lenovo problem, not HelenOS problem, I would really appreciate having an alternative that works on Lenovo." Jiri Svoboda 603 demo.xm doesn't play correctly helenos/unspecified mainline defect new 2014-10-20T19:44:25+02:00 2014-10-21T15:35:59+02:00 "The newly added demo module demo.xm (a.k.a. Wrath_of_the_Djinn) does not play the way it should. Looking at it closer, looks like you chose to really put trackmod through its paces ^_^ I have identified several features the module uses that are currently not implemented: * arpeggio effect * effect parameter memory * XM volume envelopes * pingpong loop * linear frequency table " Jiri Svoboda 607 Nested traps should probably lower GL too to avoid register corruption helenos/kernel/sparc64 mainline defect Jakub Jermář new 2014-12-02T11:30:19+01:00 2017-11-11T17:33:09+01:00 "On sun4v, the active set of global registers is determined by the GL (global level) register, similarly to the TL (trap level) register, it will be increased by one when a (nested) trap occurs. The UA2005 architecture defines a maximum value for this register (MAXPGL) and the UltraSPARC T1 processor defines MAXPGL=2. Attempts to store a greater value to GL will result in storing MAXPGL. Now, when handling a nested trap, HelenOS lowers the TL value to avoid overflowing it and also to support the preemptible_trap handler, but it does not lower the GL value. It seems to me like there is a potential for corrupting some of the global registers at GL=2: 1. executing in uspace: TL=0, GL=0 2. the uspace code executes the SAVE instruction while CANSAVE=0 3. window_spill trap: TL=1, GL=1 4. trying to save the window to the uspace stack, which is not mapped 5. fast_data_access_MMU_miss: TL=2, GL=2 6. need to call preemptible_handler, lower TL: TL=1, GL=2 7. PREEMPTIBLE_HANDLER_USPACE does INLINE_SPILL_TO_WBUF because CANSAVE=0 8. let's assume the wbuf is not mapped by DTLB, so we trap: TL=2, GL=2 (!) At this point, the nested DTLB trap is sharing the globals at GL 2 with the preemptible handler. When the nested trap returns, chances are that some globals will be corrupted." Jakub Jermář 609 No user interface on bbxm helenos/unspecified mainline enhancement new 2014-12-11T23:47:41+01:00 2017-11-11T16:56:38+01:00 HelenOS mainline,2283 boots all the way up, but there is no user interface that can be used to control the system. Jakub Jermář 610 No user interface on bbone helenos/unspecified mainline enhancement new 2014-12-11T23:49:20+01:00 2017-11-11T16:57:16+01:00 HelenOS mainline,2283 boots all the way up, but there is no user interface that can be used to control the system. Jakub Jermář 612 No user interface on raspberrypi helenos/unspecified mainline enhancement new 2014-12-11T23:57:08+01:00 2017-11-11T16:57:48+01:00 HelenOS mainline,2279 boots all the way up, but there is no user interface that can be used to control the system. Jakub Jermář 620 Make proper unit tests from tester/print tests helenos/lib/c mainline enhancement Jakub Jermář new 2015-02-10T15:02:54+01:00 2017-11-11T17:07:44+01:00 "Some of the `print/print*.c` tests in the `tester` application were already converted to [wiki:PCUT PCUT unit tests] directly in `lib/c`. The rest shall follow. The conversion is rather straightforward, only `print/print6.c` is more complex because of the rounding issues. " Vojtech Horky 621 Raspberry Pi USB controller driver helenos/usb/other mainline enhancement new 2015-02-13T17:12:30+01:00 2018-01-22T19:49:18+01:00 "Implement driver for the Raspberry Pi USB controller that will be part of the HelenOS DDF (Device Driver Framework) and USB stack. Details:: HelenOS features basic support for the popular and inexpensive Raspberry Pi credit-card sized computer. HelenOS can also boast its own USB stack, but because Raspberry Pi uses a non-standard USB controller, HelenOS cannot unfold its full potential on this platform, where most of the peripherals are meant to be attached via USB (mouse, keyboard, network). [[br]][[br]] A prerequisite for the Raspberry Pi USB controller driver would be a simple Raspberry Pi platform driver that would provide attachment points for the USB controller driver and possibly also for other drivers. This small driver represents an ideal qualification task for GSoC students who wish to work on this project. [[br]][[br]] HelenOS currently supports USB 1.1 and USB 2.0. USB 3.0 development branch is available on !GitHub and is awaiting integration into the main development branch. The Raspberry Pi USB controller can be programmed either for USB 1.1 or USB 2.0. What Gains and Benefits will this bring?:: With this driver implemented, it will suddenly become possible to use standard USB devices such as mice and keyboards on HelenOS/Raspberry Pi. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or USB stack implementation would be beneficial. Documentation and references:: * [wiki:DeveloperDocs/Peripherals#USB Developer documentation (USB)] * [http://en.wikipedia.org/wiki/Raspberry_Pi#cite_note-VerifiedPeripheralList-10 Raspberry Pi on Wikipedia] * [http://networkdirection.net/images/stories/RPi%20-%20USB%20Controller%20v1.03.pdf Raspberry Pi USB controller] * [http://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md Raspberry Pi USB documentation on Raspberry Pi project homepage] * [http://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md BCM2835 chip documentation on Raspberry Pi project homepage] * [https://github.com/helenos-xhci-team/helenos Development branch with USB 3.0 support] Possible mentors:: HelenOS Core Team, Jakub Jermar " Jakub Jermář 624 Add support for Supervisor Mode Access Prevention (SMAP) helenos/kernel/amd64 mainline enhancement Jakub Jermář new 2015-03-12T00:08:42+01:00 2016-05-04T20:54:39+02:00 Supervisor Mode Access Prevention (SMAP) is a feature of the Haswell microarchitecture (and later) that prevents the kernel from accessing user space memory. This basically limits the attack surface on the kernel because the kernel can decide to access the user space memory only in certain, tightly controlled situations (e.g. in copy_from_uspace(), copy_to_uspace(), etc.). Martin Decky 627 Atheros Wifi cannot connect helenos/unspecified mainline defect new 2015-04-28T15:48:27+02:00 2015-06-01T14:17:23+02:00 "Tried TP-LINK TL-WN722N, forwarded USB device inside Qemu 2.1.0. The device initializes and I get a list of wireless networks. When I try to connect to any I get an error ""Timeout when authenticating to network"". Tried both with Open authentication and WPA2-PSK and with different APs. " Jiri Svoboda 628 Atheros WiFi reports incorrect link state helenos/unspecified mainline defect new 2015-04-28T15:50:06+02:00 2018-05-18T12:57:46+02:00 "With ar9721 I get link state ""up"" even if it is not connected to any network." Jiri Svoboda 629 Network packet capture helenos/net/other mainline enhancement new 2015-05-19T16:40:39+02:00 2015-05-19T16:40:39+02:00 It would be useful for debugging and diagnostic purposes to have an ability to capture network packets from inside HelenOS. Apart from Ethernet frames we could also capture 802.11 frames. We should be able to write the captured packets in some format understood by [https://www.wireshark.org/ WireShark] ([https://wiki.wireshark.org/Development/LibpcapFileFormat pcap], [https://wiki.wireshark.org/Development/PcapNg pcap-ng]). Jiri Svoboda 630 Listeners in core TCP helenos/unspecified mainline enhancement new 2015-08-11T16:11:16+02:00 2015-08-11T16:11:16+02:00 "While the TCP API has listener objects to listen for new connections, the TCP core does not support them. The API implementation translates them to sentinel connections. (Also, currently there is only one sentinel connection so it is not possible for more than one incoming connection to be in progress of being established at the same time). For better behavior and more straightforward implementation of the API, the TCP core should support listeners natively." Jiri Svoboda 631 trunc(768.3156) == 770?! helenos/unspecified mainline defect new 2015-08-31T19:59:51+02:00 2015-09-04T19:36:21+02:00 "Adding the code fragment {{{ TPRINTF(""trunc(768.3156)=%lf\n"", trunc(768.3156)); }}} to tester yields the output {{{ trunc(768.3156)=770.000000 }}} However the float2 test succeeds, because after multiplication by precision and conversion to integer the result is as expected." Jiri Svoboda 639 hsct depends on last component of build dir coastline mainline defect new 2015-09-20T13:08:52+02:00 2015-10-09T14:21:47+02:00 If I do {{{hsct.st init amd64 build}}} in a directory called something/coast-build/amd64, it succeeds. If I do the same in something/coast-build, it fails. Jiri Svoboda 646 GDB stub for remote debugging helenos-debugging mainline enhancement new 2016-02-18T17:07:50+01:00 2018-01-15T18:32:16+01:00 "Implement GBD stub for remote debugging of HelenOS user processes. Details:: HelenOS currently lacks a feature-rich debugger such as GDB. HelenOS however already features a sophisticated framework for debugging and tracing of user space processes. The goal of this project would therefore be to implement a GDB stub for HelenOS that would communicate with a remote GDB over TCP/IP and/or some other transport using gdb's Remote Serial Protocol on one side and debug the debugged target via the HelenOS debugging framework on the other. GDB already comes with an implementation of the Remote Serial Protocol on the stub side, but it may be necessary to implement this functionality from scratch due to licensing issues and the intrusiveness of the GDB sources. What Gains and Benefits will this bring?:: Upon the completion of this project it would be possible to debug running HelenOS user processes, including drivers and servers, with a full-fledged debugger and all the comforts it offers, such as symbols, debug information and the possibility to use a GUI frontend, without actually porting GDB itself to HelenOS. Difficulty:: medium Required skills:: A successful applicant will have good programming skills in the C language and the ability to survive in a non-standard non-POSIX application environment. HelenOS uses a non-standard networking API for TCP/IP communication, so familiarity with basic networking concepts and ability to quickly grasp new APIs is a plus. The debugging part may require studying of kernel code and modifications of the debugging framework. Documentation:: * [wiki:Tracing Using the Syscall/IPC Tracer] * [http://www.helenos.org/doc/theses/js-thesis.pdf Dynamic linker and debugging/tracing interface for HelenOS] * [https://sourceware.org/gdb/onlinedocs/gdb/ Debugging with GDB] * [https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html Remote Serial Protocol] * [https://sourceware.org/gdb/onlinedocs/gdb/Remote-Stub.html Implementing a Remote Stub] Possible mentors:: HelenOS Core Team, Jakub Jermar, Jiri Svoboda" Jakub Jermář 647 USB support on BeagleBoard XM and BeagleBone computers helenos/drv/other mainline enhancement new 2016-02-18T17:22:22+01:00 2018-01-22T19:54:12+01:00 "Implement drivers for the USB host/OTG controllers as found on the !BeagleBoard XM and !BeagleBone credit-card-sized computers that will be part of the HelenOS DDF (Device Driver Framework) and USB stack. Details:: HelenOS features basic support for the popular !BeagleBoard XM and !BeagleBone credit-card sized computers. HelenOS also has its own USB stack, but because !BeagleBone uses a non-standard USB host controller and !BeagleBoard XM comes with a (sometimes) flaky EHCI host controller, and a non-standard OTG USB controller, HelenOS cannot unfold its full potential on these platforms, where most of the peripherals are meant to be attached via USB (mouse, keyboard, network, etc.). HelenOS currently supports USB 1.1 and USB 2.0. USB 3.0 development branch is available on !GitHub and is awaiting integration into the main development branch. !BeagleBone comes with a USB host controller which actually is an USB OTG controller with some pins grounded so that it acts as a host controller. The goal for the !BeagleBone would therefore be to implement the USB OTG controller driver for the host mode. !BeagleBoard XM USB host controller is USB 2.0 only (EHCI only). On some board revisions the USB host controller is reported to be flaky or is completely absent. The goal for the !BeagleBoard XM would therefore be to try to get the EHCI driver for the host controller working and implement the USB OTG controller driver for host mode. What Gains and Benefits will this bring?:: With these drivers implemented, it will suddenly become possible to use standard USB devices such as mice and keyboards on HelenOS/bbxm and HelenOS/bbone. Difficulty:: Medium to difficult Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or USB stack development would be beneficial. Documentation and references:: * [wiki:DeveloperDocs/Peripherals#USB Developer documentation (USB)] * [https://github.com/helenos-xhci-team/helenos Development branch with USB 3.0 support] * [http://helenos-usb.sourceforge.net/manual/ USB subsystem in HelenOS] * [http://elinux.org/BeagleBoard_Community#USB] * [http://beagleboard.org/beagleboard-xm Official BeagleBoard XM web page] * [http://beagleboard.org/bone Official BeagleBone web page] * [http://processors.wiki.ti.com/index.php/Usb-am335x-quick-start USB AM335x Quick Start] on TI web * [https://en.wikipedia.org/wiki/USB_On-The-Go USB On The Go] article on Wikipedia Possible mentors:: HelenOS Core Team, Jakub Jermar " Jakub Jermář 648 Extend dynamic linking support to (an)other architecture(s) helenos/srv/loader mainline enhancement Jiri Svoboda new 2016-02-18T17:34:34+01:00 2024-03-09T12:33:39+01:00 "HelenOS currently supports dynamic linking only for the ia32 architecture. Extend this support to one or more other architectures. Details:: At the moment, all user programs in HelenOS are statically linked by default. This results in very large boot images. Not only is this a waste of disk space, but some machines supported by HelenOS have some kind of a limit on the size of the boot image and so booting HelenOS on them is becoming increasingly challenging. The temporary solution used so far has been to compress some of the boot components and to exclude the so-called non-essential components from the boot image. However, with the ever growing HelenOS codebase, this stop-gap solution is quickly reaching its limits. Besides of that, init RAM disks with only the bare minimum of applications, drivers and servers are not very useful anyway. Dynamic linking, currently available for ia32 only, can reduce the size of the boot image considerably. Currently, the dynamically linked boot image is 16M smaller than the statically linked image (36.2M). This option should therefore be extended to other architectures supported by HelenOS as well. What Gains and Benefits will this bring?:: Dynamically linked HelenOS results in a much smaller boot image, which in turn allows for more software to be placed in the boot image or to boot on machines where the statically linked image was already hitting the size limit. Difficulty:: medium Required skills:: A successful applicant will have good programming skills in the C language and the ability to survive in a non-standard non-POSIX application environment. He or she will be able to study the relevant ABI specifications. The project will require modifications to the HelenOS build system. Documentation:: * [http://www.helenos.org/doc/theses/js-thesis.pdf Dynamic linker and debugging/tracing interface for HelenOS] * [wiki:DeveloperDocs/CPUArch Links to various ABI specifications per CPU architecture] Possible mentors:: HelenOS Core Team, Jakub Jermar, Jiri Svoboda" Jakub Jermář 649 Implement support for Creator Ci40 (mips32) helenos/kernel/mips32 mainline enhancement Martin Decky new 2016-02-18T17:44:40+01:00 2018-01-28T11:07:32+01:00 "Implement support for Creator Ci40 single-board computer. Details:: Creator Ci40 is an extensible board meant for Internet-of-Things. It serves as a hub for sensors and actuators, connecting them to the network. It features dual-core, dual-threaded MIPS interAptiv CPU, 256MB of RAM, micro-SD card slot, ethernet and 6LoWPAN connectivity to the Clicker modules (e.g. thermometer). Basic support for Ci40 is within the reach of a single trimester work. HelenOS supports the mips32 architecture, but so far has been ported only to MIPS R4000 and MIPS 4Kc CPUs. Creator Ci40 has a MIPS32 interAptive processor so this project will require some kernel code modifications. What Gains and Benefits will this bring?:: Creator Ci40 would be a good demonstrator for HelenOS to show that HelenOS could be deployed as the controller for IoT gadgets. Difficulty:: Medium to High Required skills:: A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation, source code of other operating system projects). Experience with kernel-level programming is a plus. Documentation:: * [https://creatordev.io/ci40-iot-hub.html Creator Ci40 Homepage] * [https://imgtec.com/mips/aptiv/interaptiv/ interAptiv CPU documentation] * [https://tools.ietf.org/html/rfc4944 RFC 4944 IPv6 over IEEE 802.15.4 (6LoWPAN)] Possible mentors:: HelenOS Core Team, Jakub Jermar" Jakub Jermář 651 Implement Turris Omnia support (arm32) helenos/kernel/arm32 mainline enhancement Jiří Zárevúcky assigned 2016-02-18T17:49:20+01:00 2018-02-12T17:23:49+01:00 "Implement support for Turris Omnia open-source router. Details:: Turris Omnia is an open-hardware router for home use. It features dual-core ARM CPU, 1GB of RAM, 4GB of internal storage and 5 LAN ports. The machine is well documented and can be used as a model hardware for the network usability of HelenOS. Turris Omnia offers a lot of functionality (including USB, !WiFi or SIM card slot) thus a complete support would require more than 3 monts but basic functionality is within the reach of a single trimester work. HelenOS supports the ARMv7-A architecture, including the Cortext-A8 processor, but has not yet been ported to a Cortex-A9 processor used by Turris Omnia. This project will therefore require some kernel and platform code modifications. What Gains and Benefits will this bring?:: Turris Omnia would be a good demonstrator for HelenOS to show that HelenOS is capable of a full-fledged routing functionality. Difficulty:: Medium to High Required skills:: A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation, source code of other operating system projects). Kernel developmanet experience is a plus. Documentation:: * [[https://omnia.turris.cz/en/|Turris Omnia Homepage]] * [http://www.marvell.com/embedded-processors/armada-38x/ Marvell ARMADA 385 SoC] * [https://silver.arm.com/download/download.tm?pv=1550621 Cortex-A Series Programmer’s Guide] on ARM web * [https://silver.arm.com/download/download.tm?pv=1603196 ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition Issue C] Possible mentors:: HelenOS Core Team, Jakub Jermar " Jakub Jermář 655 Networking stabilization campaign helenos/net/other mainline enhancement new 2016-02-19T16:34:11+01:00 2017-09-05T16:22:12+02:00 "While the feature set of the HelenOS networking stack is currently reasonable for many practical applications and the networking stack is generally operational, it is still not rock-solid and 100% reliable. The purpose of this ticket is to systematically hunt down the majority of bugs in the networking stack. Details:: There are several open tickets related to the HelenOS networking stack ([ticket:546 #546], [ticket:589 #589], [ticket:627 #627], [ticket:628 #628]) and generally speaking the networking stack is still not behaving flawlessly. People usually avoid stressing the networking stack or putting it under high demand. The practical 100% reliability that one expects from a networking stack is simply just not there yet. The purpose of this ticket is to systematically hunt down the majority of bugs in the networking stack (i.e. all major bugs that can be detected, reproduced, triaged and fixed in the given time frame). This requires designing and implementing a rigorous and robust methodology that would be able to objectively determine whether the degree of reliability of the networking stack actually improves over time. This methodology should be based on a set of stress tests for all major aspects of the networking stack operation, with mostly automatic evaluation of the stress tests. The purpose of this ticket is not to improve the overall performance of the networking stack, although trivial performance bottlenecks and performance issues that break conformance (incorrect timeouts, etc.) are still covered by this ticket. What Gains and Benefits will this bring?:: When the work on this ticket is over, the HelenOS networking stack should no longer be considered a working prototype, but instead a production-ready implementation. Other components can readily rely on the reliability of the networking stack. Difficulty:: High Required skills:: A successful applicant will have good skills of programming in the C language, the ability to understand a non-trivial amount of existing C code and good analytical skills (both for designing the assessment methodology and for finding root causes of bugs). Documentation:: - [http://www.helenos.org/doc/theses/as-thesis.pdf IPv6 for HelenOS] containing a basic testing methodology for the networking stack Possible mentors:: HelenOS Core Team, Jakub Jermar, Martin Decky, Jiri Svoboda" Martin Decky 670 Allow arbitrary number of answerboxes per task helenos/kernel/generic mainline enhancement Jakub Jermář new 2017-02-05T16:22:33+01:00 2017-09-30T12:41:09+02:00 "HelenOS has always used one main answerbox for task's IPC communication. The userspace async framework multiplexes this single communication endpoint for multiple logical connections. Besides of that, the kernel also uses other answerboxes internally such as the debugging kbox and a temporary kernel answerbox when a user page fault is being handled. More recently, the async framework added the notion of async ports to ease writing multi-protocol components. However, async ports are still multiplexed over the main task's answerbox. It would make a good sense to allow a task to create an arbitrary number of answerboxes and couple them with async ports. This would simplify the routing of IPC calls within the task as each logical IPC endpoint would use its own answerbox. Additionally, the realization of this idea would effectively turn HelenOS into a capability-based system (where a capability would be equal to an IPC connection, similar to how Hurd and Genode work with capabilities). For example, the VFS now uses a complex security protocol to pass an open file from a parent task to its child. If VFS associated a port/answerbox with each open file, the parent task could pass its open files simply by connecting the child to those open files' respective answerboxes (e.g. by requesting a few callback connections from the child and forwarding them to VFS)." Jakub Jermář 675 Implement Xen PV network device driver helenos/net/other mainline enhancement new 2017-04-22T14:46:09+02:00 2018-01-23T09:30:43+01:00 "Implement a set of native HelenOS drivers to allow the use of Xen PV network device. Details:: The Xen hypervisor provides [https://wiki.xenproject.org/wiki/Xen_Networking#Paravirtualised_Network_Devices paravirtualized (PV) network devices] to fully-virtualized domains (HVM) in order to enable fast and efficient network communications without the overhead of emulating a real network device. The new functionality should be achieved via a hierarchy of device drivers that implement the Xen PCI Platform device, !XenBus virtual bus and the Xen netfront device. These drivers should plug themselves into the HelenOS Device Driver Framework (DDF) and (the latter also) to the networking stack, and implement the network interface card interface (NICF) in the Xen netfront specific way. What Gains and Benefits will this bring?:: HelenOS might need a Xen PV network device driver if we want to run it in a Xen-based hosting (e.g. Amazon E2C) and serve some web content (e.g. microkernel.info or even self-host helenos.org) to the public from it. Difficulty:: medium to high Required skills:: A successful applicant will have good skills of programming in the C language and the ability to learn and use HelenOS specific I/O functions. A successful applicant should have a fair understanding of the workings of the networking stack and the DDF and NICF too. Documentation:: * [https://wiki.xenproject.org/wiki/PV_on_HVM PV on HVM] Linux PV drivers on HVM * [https://wiki.xenproject.org/wiki/Xen_Windows_GplPv GPL PV drivers for Windows] * [http://www.helenos.org/doc/helnet.pdf HelenOS NICF documentation] * [https://archive.fosdem.org/2012/schedule/event/550/113_helenos_dd.pdf Dive into HelenOS Device Drivers] * [http://www.helenos.org/wiki/DeviceDrivers Writing Device Drivers for HelenOS] Possible mentors:: HelenOS Core Team, Jakub Jermar " Jakub Jermář 678 plb_get_component() is broken wrt. UTF8 helenos/fs/other mainline defect new 2017-05-28T15:51:02+02:00 2017-11-11T17:09:59+01:00 `plb_get_component()` does not assume multibyte characters and is thus broken wrt. UTF8. Jakub Jermář 687 taskdump -t 6 deadlocks VFS and taskdump helenos/kernel/generic mainline defect new 2017-08-29T22:24:15+02:00 2017-11-11T17:23:01+01:00 "When one does: {{{ / # taskdump -t 6 }}} `taskdump` begins a udebug session with task 6 (usually `vfs`), reads its name over udebug and attempts to print a message: {{{ printf(""Dumping task '%s' (task ID %"" PRIu64 "").\n"", app_name, task_id); }}} Now printf() needs to make a call to `vfs`, but since `vfs` is being debugged, there is no-one to process the request and answer it. So `taskdump` cannot proceed towards ending the udebug session with `vfs` and these two tasks hang. Something similar happens when tracing `vfs` using `trace`. It is possible to kill the `taskdump` task, but for some reason `vfs` remains hung." Jakub Jermář 691 "xorriso doesn't support ""-hfs""" helenos/unspecified mainline defect new 2017-09-16T21:34:10+02:00 2017-11-11T17:09:35+01:00 "When building for ppc32: {{{ make[2]: Entering directory '/home/jzr/helenos-workspace/mainline/boot' rm -fr distroot mkdir -p distroot/boot mkdir -p distroot/ppc cp image.boot distroot/boot/ cp yaboot/ofboot.b distroot/boot/ cp yaboot/bootinfo.txt distroot/ppc/ cp yaboot/yaboot distroot/boot/ cp yaboot/yaboot.conf distroot/boot/ xorriso -as genisoimage -hfs -part -map yaboot/maps -no-desktop -hfs-volid ""HelenOS"" -hfs-bless distroot/boot -r -o ../image.iso distroot/ xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:../image.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 302g free xorriso : FAILURE : -as genisoimage: Unsupported option '-hfs' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' make[2]: *** [Makefile.yaboot:42: ../image.iso] Error 5 make[2]: Leaving directory '/home/jzr/helenos-workspace/mainline/boot' make[1]: *** [Makefile:35: all] Error 2 make[1]: Leaving directory '/home/jzr/helenos-workspace/mainline/boot' make: *** [Makefile:53: all] Error 2 }}}" Jiří Zárevúcky 697 Kernel console is painfully slow on Freerunner helenos/unspecified mainline defect new 2017-10-10T10:57:23+02:00 2020-01-30T14:26:18+01:00 As of mainline,2797, kernel console is running really slow on Neo Freerunner. The initial screen fill as well as each subsequent scroll take seconds to complete. The same was observed with release 0.7.0, but not with 0.4.3. Jiri Svoboda 710 Second run of ApacheBench against HelenOS websrv times out helenos/net/tcp mainline defect new 2017-11-19T11:10:04+01:00 2017-11-19T11:10:04+01:00 "As of 75fcf9b27, running the testcase from #515 results in a timeout for the second run (make sure to start websrv in HelenOS before running this): {{{ bash-4.4$ ab -c 4 -n 10 -t 30 -g results.out http://localhost:8080/index.html This is ApacheBench, Version 2.3 <$Revision: 1807734 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Finished 130 requests Server Software: Server Hostname: localhost Server Port: 8080 Document Path: /index.html Document Length: 478 bytes Concurrency Level: 4 Time taken for tests: 30.032 seconds Complete requests: 130 Failed requests: 0 Total transferred: 64610 bytes HTML transferred: 62140 bytes Requests per second: 4.33 [#/sec] (mean) Time per request: 924.057 [ms] (mean) Time per request: 231.014 [ms] (mean, across all concurrent requests) Transfer rate: 2.10 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 68 921 784.7 777 2596 Waiting: 47 894 772.3 751 2550 Total: 68 921 784.6 777 2596 Percentage of the requests served within a certain time (ms) 50% 777 66% 1233 75% 1589 80% 1787 90% 2079 95% 2317 98% 2519 99% 2532 100% 2596 (longest request) bash-4.4$ ab -c 4 -n 10 -t 30 -g results.out http://localhost:8080/index.html This is ApacheBench, Version 2.3 <$Revision: 1807734 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) apr_pollset_poll: The timeout specified has expired (70007) Total of 116 requests completed }}} Even after the second run ends with the above error, `top` shows there is still some activity happening inside `tcp`." Jakub Jermář 711 Library support for foreign C software (tracking ticket) helenos/lib/other mainline enhancement new 2017-11-22T00:26:58+01:00 2017-11-22T00:31:27+01:00 "This is a tracking ticket for anything relevant to legacy software support in HelenOS. Particularly, but not limited to, any enhancements to libposix, and enhancements for functionality necessary to implement libposix functions, should be linked to by this issue. Note that some functionality (for example, fork()/exec() library calls, or particular properties of standard POSIX application environment) will forever be intentionally unsupported." Jiří Zárevúcky 712 Port Git to HelenOS ported-software mainline enhancement new 2017-11-22T00:31:03+01:00 2018-01-23T09:49:46+01:00 "Port [https://git-scm.com/ Git] version control system to HelenOS. Details:: Git is a distributed version control system that is also used for the main HelenOS development branch. [[br]][[br]] The goal of porting this tool to HelenOS is to allow developers checkout source code of HelenOS inside HelenOS and possibly fix bugs directly inside HelenOS environment. The goal is to port only the command-line parts of Git as HelenOS does not yet offer a full-fledged GUI toolkit. [[br]][[br]] Git itself is written in C and HelenOS provides a POSIX emulation layer (called libposix) that should simplify the porting. However, libposix does not offer all the functionality found in POSIX-compatible systems and thus this task will require improvements in libposix too. What Gains and Benefits will this bring?:: The biggest benefit of this task is in the ability to allow modification of HelenOS inside HelenOS, thus possibly speeding-up development process and, as a more distant goal, develop HelenOS fully inside HelenOS. Difficulty:: Medium Required skills:: A successful applicant will have good skills of programming in the C language, knowledge of the Git VCS and the ability to survive in a non-standard non-POSIX application environment. Documentation:: * [https://git-scm.com/ Git homepage] * [PortingSoftware Porting POSIX software to HelenOS] Possible mentors:: HelenOS Core Team, Vojtech Horky " Jiří Zárevúcky 718 Implement mitigations for Meltdown and Spectre helenos/kernel/amd64 mainline enhancement new 2018-01-06T02:04:40+01:00 2018-01-06T17:01:57+01:00 "Note: To my knowledge, HelenOS is not used as part of any important infrastructure, so this has low priority. https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html" Jiří Zárevúcky 719 Terminal resizing and scrolling helenos/gui mainline enhancement new 2018-01-19T22:10:43+01:00 2020-01-30T14:25:48+01:00 "Add the ability to scroll through terminal output and resize the terminal window. Details:: Terminal is still the main interface when working with HelenOS. Current implementation provides a fixed-sized window without an ability to scroll backwards through the history of output. The task is to extend the functionality of terminal with two most common features: scrolling to see output of commands that are no longer directly visible and the ability to resize the terminal window. The resizing must update contents of the terminal (e.g. wrap long lines) - current implementation extends/shrinks the area but not the contents itself. It is expected that the scrolling would be added as a separate feature of the widget library. Terminal resizing is then a specific feature of the terminal application. An optional extension might be implementing the resizing for TUI applications such as the editor. What Gains and Benefits will this bring?:: While implementation of this features is not innovative from design perspective, it would greatly improve user experience. It is possible to use the terminal without these features but the control is cumbersome and ineffective. Difficulty:: medium Required skills:: A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with a graphics stack implementation would be beneficial. Documentation:: * [http://www.helenos.org/doc/theses/pk-thesis.pdf Graphics Stack for HelenOS] * [wiki:UsersGuide/GUI GUI's Users Guide] Possible mentors:: HelenOS Core Team " Vojtech Horky 720 DMA operations require cache maintenance helenos/unspecified mainline defect new 2018-02-24T11:32:56+01:00 2018-02-24T11:32:56+01:00 In general, two cache maintenance operations are needed when doing DMA (assuming cacheable buffers): before and after. We need to provide APIs for this and also modify our existing drivers. Jakub Jermář 722 Find a way to check consistent use of errno_t type. helenos/unspecified mainline enhancement new 2018-03-08T17:22:36+01:00 2018-03-08T17:22:36+01:00 For historical reference: https://github.com/HelenOS/helenos/pull/10 Jiří Zárevúcky 730 Atheros WiFi driver crashes upon attach helenos/unspecified mainline defect new 2018-05-18T12:56:55+02:00 2018-05-25T22:55:30+02:00 "The driver crashes with assertion failure upon loading. Apparently there are two attempts at calling ddf_dev_data_alloc(). The immediate cause seems to be because the driver is calling usb_device_create_ddf(). I'm not sure whether this is incorrect or obsolete.. In any case I am not sure how usb+nic driver could have ever worked: libnic allocates and uses dev data (which it absolutely should not do since it's a top-half framework). If USB does the same..." Jiri Svoboda 732 Fill in gaps in ISO C standard library support helenos/unspecified mainline enhancement Jiri Svoboda accepted 2018-06-15T18:41:06+02:00 2018-06-15T18:42:04+02:00 "HelenOS libc has some gaps with regard to what ISO C requires from the standard library. These need to be filled in. Some functionality is present in libposix instead and needs moving and potentially significant rework. Detailed progress is tracked in [wiki:LibCLibPosixTODO Libc / libposix TO DO list] Not all functionality needs to be made available to native HelenOS code (-D_HELENOS_SOURCE) if we prefer using an alternative API (e.g. string.h). Some APIs may have lower priority since they are not widely used or very useful (e.g. wchar.h/wctype.h). " Jiri Svoboda 740 tester float2 test fails helenos/app/tester mainline defect new 2018-09-15T11:57:24+02:00 2018-11-20T20:09:08+01:00 "As of commit cc74cb5c5f69f9cd7b915a29908ded2daedb158d, tester float2 still / again fails on e.g. ia64/ski, amd64 and ppc32: {{{ HelenOS release 0.7.2 (Boosted Effort), revision f8048d1b96 Built on 2018-09-06 18:31:39 Running on ia64 (term/vc0) Copyright (c) 2001-2018 HelenOS project Welcome to HelenOS! http://www.helenos.org/ Type 'help' [Enter] to see a few survival tips. / # tester float2 Single precision sin failed (0.158561 != 0.158533, arg 4) Single precision sin failed (-0.206408 != -0.206380, arg 7) Single precision sin failed (-0.044199 != -0.044182, arg 8) Floating point imprecision bdsh: Command failed (exit code -1) }}} " Jakub Jermář 746 Proper implementation of SIF helenos/unspecified mainline enhancement Jiri Svoboda assigned 2018-10-12T15:40:30+02:00 2018-11-20T18:49:49+01:00 Replace the placeholder SIF implementation with a proper one that implements efficient updates (less than O(N)) and transactions. Jiri Svoboda 747 Volume server configuration needs to be persistent helenos/unspecified mainline enhancement new 2018-10-12T15:43:54+02:00 2018-11-20T18:52:00+01:00 Currently volume server configuration is in /cfg. Thanks to this it is available during boot so volsrv knows where to find the system (/w) volume. Nevertheless any configuration made while the system is running will be lost after reboot. Need to make sure volume server configuration is persistent, while keeping /w configuration available during boot. Jiri Svoboda 748 Persistent network configuration helenos/unspecified mainline enhancement new 2018-10-12T15:53:58+02:00 2018-11-20T18:52:59+01:00 "Network configuration in HelenOS is not preserved across reboots, even if persistent /w is available. Making it persistent is tricky, since we don't have a way to persistently identify IP links. The current configuration model is too static and does not account for things like Wi-FI or walking around with a laptop and plugging an Ethernet cable into different networks. Perhaps the configuration model should be changed to introduce a 'network connection' as the persistent entity against which we would anchor the configuration. Then we would detect network connection on a IP link by examining the SSID (for wireless), HW MAC address (for wired), etc." Jiri Svoboda 751 ppc32 boot fails when boot and stack allocations are in some places helenos/kernel/ppc32 mainline defect new 2018-10-22T00:05:18+02:00 2018-12-13T18:20:07+01:00 "Prior to commit [https://github.com/HelenOS/helenos/commit/d59718e246e2f30ad97e0364fac7e75455fcb7d1 d59718e2], this is easily reproducible by adding `. = . + 8192;` into the kernel linker script, leaving enough space for kernel stack to be allocated in the created gap. Instead of booting properly and printing output, kernel will keep running but fills the screen with garbage. If the stack is put after boot allocations, this does not occur, so that's what the workaround commit does. However, the problem reoccurs if balloc is moved some distance (<600kB) from its usual position." Jiří Zárevúcky 754 Toolchain build fails with cryptic message when dependecies are missing helenos/unspecified mainline defect new 2018-10-29T10:13:56+01:00 2018-12-13T18:22:12+01:00 "I had to reinstall my Fedora 28 and rebuild the HelenOS toolchain. The toolchain build failed. That's expected because a pristine F28 installation does not have all the packages installed that are needed to build it. The problem is, in the past, the build would fail with an error that would easily lead you to which package you are missing. This time, the build failed with cryptic message that left me wondering, complaining about libtool commands failing (but there was no issue with libtool). I thought toolchain.sh was broken so I went back in history and used older toolchain.sh. That got me useful error messages so I installed the required packages and after a successful toolchain build I tried again with the latest toolchain.sh and it worked. So the only problem is that it's now impossible to determine what package is missing from the error you get during toolchain build. 889cdb1c2046af9d31d314fa691773fa2e4f9119 Always answer the IPC_M_PHONE_HUNGUP message -- BROKEN e5fe873e6ece249ae475d58dae9a738bfe8b8ea0 Use Travis CI for per-commit builds (#12) -- OK " Jiri Svoboda 755 Shared libraries should be shared in memory, too helenos/unspecified mainline enhancement new 2018-10-29T17:06:51+01:00 2018-11-20T18:51:09+01:00 "HelenOS supports shared objects, namely libc, (on some architectures), which helps reducing disk consumption (e.g. size of the ISO) and to some degree memory consumption (by reducing size of the initial RAM disk). However, the shared libraries get loaded into anonymous memory for each task, wasting RAM. We need to be able to actually map the files and make use of shared mapping to conserve RAM. This is especially useful when running on resource-limited HW. This will likely require improvements to the memory management." Jiri Svoboda 757 Need sqrt function helenos/unspecified mainline defect new 2018-11-02T09:57:31+01:00 2018-12-13T18:23:01+01:00 "This commit 516e7808c5e1e23b10a77bb1429054a16f6fedc3 removed sqrt and most other functions from libmath claiming they are ""either very imprecise or downright broken"" despite all math functions passing at least some tests. Now I need sqrt for statistics computation." Jiri Svoboda 760 vreg's can be modified by an arbitrary thread running on another CPU helenos/kernel/amd64 mainline defect Jakub Jermář accepted 2018-11-02T20:47:19+01:00 2018-11-21T11:46:07+01:00 On amd64 and ia32, `vreg_init()` creates a user-writable page for each CPU with the intention to offer this page via the FS, resp. GS, register as an array of virtual registers that can be used by uspace to implement eg. TLS. Unfortunately, this page can be accessed and written to also from other CPUs without any limits. Jakub Jermář 765 Hsct build of some packages dumps a lot of cores coastline mainline defect new 2018-11-12T09:30:45+01:00 2018-12-13T18:25:47+01:00 Builds of some harbours such as libmpc attempt to execute tests, which are HelenOS binaries, on the host OS (Linux, in this case) and they dump core. That amounts to 64 cores for libmpc build. Each core dump generates a desktop notification on Fedora/XFCE. This practically renders the desktop unusable for a few minutes. Jiri Svoboda 768 CI/Travis need more config space coverage ci mainline enhancement new 2018-11-13T11:44:08+01:00 2018-11-21T09:07:54+01:00 "HelenOS has a number of features that can be disabled or enabled during build configuration. CI/Travis only test the preconfigured profiles. This sometimes lead to build breaking when other configuration is set. While it is not feasible to test all possible configurations, these are the typical problems: * kernel build fails when a kernel feature is disabled * build fails at a non-default optimization level So one option would be to add a CI/Travis job to build * OS with all optional features disabled for at least one arch * OS with all different optimization levels (0, 1, 2, 3, s) for at least one arch" Jiri Svoboda 770 GRUB Legacy support broken helenos/unspecified mainline defect new 2018-11-16T15:49:04+01:00 2018-12-14T09:31:16+01:00 "As of 64f85f54a27d11f2ce4cf0aef2e2fb35918fe5cd, booting HelenOS using GRUB Legacy (a.k.a. GRUB 1) does not work. GRUB 0.97 from Fedora 12 reports ""Error 13: Invalid or unsupported executable format"" for the amd64 ELF kernel binary and ""Error 7: Loading below 1MB is not supported"" for the ia32 ELF kernel binary. Manually converting the ELF kernel binary to a raw binary using `objcopy` solves the booting issue, but the VESA graphics mode is not initialized. AFAIK, GRUB Legacy actually never implemented the VESA mode setting (despite the specification) and that was the reason for the real-mode VESA code within SPARTAN that has been removed in e3fa1720e83c1029187354ec92323608505ed7e3." Martin Decky 773 Ancient coastline GCC won't build for MIPS coastline mainline defect new 2018-11-21T08:08:39+01:00 2019-01-09T18:44:41+01:00 "The mips build of gcc errs with the following error: {{{ mips-helenos-cc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o xgcc gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o ggc-none.o \ gccspec.o intl.o prefix.o version.o ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a /usr/local/cross/lib/gcc/mips-helenos/8.2.0/../../../../mips-helenos/bin/ld: gcc.o:(.data.rel.ro+0x74): undefined reference to `host_detect_local_cpu' }}} [https://github.com/HelenOS/gcc/blob/304fe7e2c5d69342d094c7f50b14da030d56777b/gcc/config/mips/driver-native.c#L27 This] comment here suggests that gcc thinks it is building natively on a mips system. Also see [https://github.com/HelenOS/gcc/blob/304fe7e2c5d69342d094c7f50b14da030d56777b/gcc/config/mips/helenos.h#L96 helenos.h]." Jakub Jermář 778 Support for Intel Corporation Ethernet Connection (3) I218-LM [8086:15a2] helenos/unspecified mainline enhancement new 2018-12-04T16:19:08+01:00 2018-12-04T16:22:57+01:00 My Lenovo X250 has this E1000 variant. This is an ICH8 chipset. Add support for this network adapter (a.k.a. there's always hope ^_^) Jiri Svoboda 781 PS/2 mouse on HW can break due to early activity helenos/unspecified mainline defect Jiri Svoboda accepted 2018-12-14T21:32:09+01:00 2019-01-06T10:33:20+01:00 If I move the mouse cursor while the OS is booting on Lenovo X250 leads to the mouse not working - the ps2mouse driver reports failure to initialize mouse reporting (the answer is not 0xfa). Jiri Svoboda 787 Taskdump needs to undertand shared objects helenos/unspecified mainline enhancement new 2019-01-09T13:54:06+01:00 2019-01-09T13:54:06+01:00 "Taskdump cannot correctly translate an address of a symbol residing in a shared object (loaded into a task's address space) to a name. To be able to do this, taskdump would need a way to determine where the shared object(s) are located in the task's address space. While this could theoretically be determined by examining the RTLD's data structures in the task being examined, this would not be very reliable. Preferably this information would be kept by a task loading/lifecycle service." Jiri Svoboda 788 Ns should track tasks through their entire life cycle helenos/unspecified mainline enhancement new 2019-01-09T14:03:10+01:00 2019-01-09T14:03:10+01:00 "Ns currently acts partially as the restarter for tasks, but it forgets about them once they return an exit code. It should track the tasks until they actually terminate. This would allow it to be the source for debugging information on the tasks, such as: * list of binaries/shared objects, where they are mapped in the address space * command line arguments Separating this service into a separate task/server presents some additional challenges and is out of scope of this ticket." Jiri Svoboda 789 Loading as a service helenos/unspecified mainline enhancement new 2019-01-09T14:18:26+01:00 2019-01-09T14:18:26+01:00 "Currently binaries are loaded by spawning a new instance of the loader task. The loader task reads the binary (plus shared objects) into its own address space and then transfers control to the loaded executable. This leads to every task containing a copy of the loader (wasting/polluting the virtual address spaces) and to the need for the somewhat delicate handover procedure between the two instances of C runtime in the same address space. An alternate approach is to have a task loading service that creates an empty task and then loads the binary and shared objects into it remotely. This requires extending the current remote task manipulation framework (Udebug). For dynamically linked executables, there is the additional need to '''remotely''' relocate at least some of the dynamic modules before starting the task (since HelenOS RTLD cannot bootstrap itself). This new loading service would be provided by the task restarter. This would allow the task restarter to keep the information about mapping of shared objects into the task's address space." Jiri Svoboda 790 sun4v freezes randomly in Qemu helenos/kernel/sparc64 mainline defect Jakub Jermář assigned 2019-01-14T17:33:07+01:00 2019-02-20T21:07:17+01:00 "As of current HelenOS master, running in Qemu 2.12.0, HelenOS freezes either during boot (just before printing command prompt) or soon after (e.g. if I type 'ls' a few times, during one of the runs). The behavior seems to be random, but very frequent (more often than not it happens). " Jiri Svoboda 791 dlsym/dl_get_public_fib_var test fails on ppc32 helenos/unspecified mainline defect new 2019-01-21T22:57:48+01:00 2019-01-21T22:57:48+01:00 "On ppc32 with optimization -O2/-O3 and a static thread-local variable, the compiler/linker generates code that subtracts 32 K bias from address returned from function {{{__tls_get_addr}}}. This seems to be consistent with the PowerPC SysV ABI. However, for non-static thread-local variable, the bias is not subtracted. This leads to dltest failing or crashing in the public fibril var test(s). Also for -O0 there is no bias subtracted. I can reproduce this with a simple code snippet compiled by hand with trivial compiler arguments and either using ppc-helenos or ppc-linux-gnu (from upstream gcc-8.2.0) cross-compiler. I believe this is a bug in GCC. I filed GCC bug 88962. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962 This ticket is for tracking purposes." Jiri Svoboda 792 Clang checker broken helenos/unspecified mainline defect new 2019-01-29T14:07:59+01:00 2019-01-29T23:49:37+01:00 "Running clang checker will fail. There are two problems that need to be fixed to make it work again * {{{-checker-cfref}}} argument seems no longer recognized * the {{{-DCOPYRIGHT}}} compiler option has multi-word argument and loses quotation when being passed to the analyzer The first one can be fixed by removing the argument (don't know what it did, though). The second can be worked around by changing the copyright to contain a single word. For a fix I'm not sure. Maybe we should opt to not pass the copyright via an argument and pass it via a file instead." Jiri Svoboda 793 Clang build broken helenos/unspecified mainline defect new 2019-01-30T15:55:06+01:00 2019-01-30T16:08:03+01:00 "As of current master Clang build fails. It is due to {{{-Werror}}} and warnings are generated about macros being re-defined. This happens because of the following reason. We switched from providing our own freestanding environment headers to using the ones provided by the compiler. With Clang compiling with {{{-cstd=gnuxx}}} and {-freestanding}}} standard freestanding headers such as {{{stddef.h}}} will expose UNIX extensions such as SSIZE_MAX macro. Those will collide with our own definitions of those macros. Un-defining the macros first as a work around does not help because sometimes our header is included before Clang's header and Clang does not undefine the macros first. Not sure if this is a bug in Clang or in HelenOS. Should Clang not expose these macros in freestanding mode? Or is this something something the compiler simply does not have an interface for asking us to do (compile with GNU extensions such as assembler, but without defining GNU macros?) Do we need to file a bug with Clang or do something else, perhaps go back to defining our own freestanding environment? " Jiri Svoboda 798 Definitions in abi/include/abi/elf.h are non-conformant helenos/unspecified mainline defect assigned 2019-07-15T15:40:14+02:00 2019-07-16T21:28:17+02:00 "The definitions in abi/include/abi/elf.h are meant to correspond to definitions as specified by SysV ABI. This commit: {{{ commit ca0e838006b1e44ee4570c6851ffbd7a5a132165 Author: Jiří Zárevúcky Date: Mon Feb 11 16:28:25 2019 +0100 Convert preprocessor macros in abi/ to C constructs Preprocessor macros are an obsolete concept and they complicate things. They are also completely unnecessary in most circumstances. This commit changes untyped numeric constants into anonymous enums, typed constants into static const variables, and function-like macros into functions. }}} changed macros to enums (which is less harmful) and introduced enum names (also not very harmful) and changed the case of ELF_ST_BIND, ELF_ST_TYPE, ELF_ST_INFO to lowercase (harmful). Our elf-related headers should be SysV compatible to prevent confusion and compatibility problems. I suggest keeping them as close as to the spec as possible (keep constants as symbolic constants, keep macros as macros), keep identifiers as they should be." Jiri Svoboda 799 Remove need for -mno-red-zone by better stack handling on amd64 helenos/kernel/amd64 mainline enhancement new 2019-08-17T12:55:17+02:00 2019-08-17T12:55:17+02:00 "The need for `-mno-red-zone` arises because interrupts can land on the currently active kernel stack, which clobbers stack beyond current `sp`, which holds the amd64 ABI ""red zone"". This is fine for the most part, but creates an additional difference between kernel and non-kernel code. Additionally clang doesn't have this flag, so one cannot build kernel and uspace with the same compiler target using clang. However, amd64 also possesses the ability to use a different stack for different interrupts via IST, the interrupt stack table. Making sure that no interrupt can ever land on an active stack would not only remove the need for disabling red zone, but would also make it easier to ensure that kernel stacks can't overflow in any circumstance. " Jiří Zárevúcky 803 ninja doxygen fails helenos-build mainline defect new 2019-09-29T14:58:11+02:00 2019-09-29T14:58:11+02:00 "When trying to build the doxygen documentation, I get the following error: {{{ ~/s/H/build-amd64  ninja doxygen 234ms  Sun 29 Sep 2019 02:54:16 PM CEST [0/1] Running external command doxygen. warning: tag INPUT: input source `../README.md' does not exist warning: tag INPUT: input source `../abi' does not exist warning: tag INPUT: input source `../boot' does not exist warning: tag INPUT: input source `../kernel' does not exist warning: tag INPUT: input source `../uspace' does not exist Searching for include files... Searching for example files... Searching for images... Searching for dot files... Searching for msc files... Searching for dia files... Searching for files to exclude Searching INPUT for files to process... warning: source ../README.md is not a readable file or directory... skipping. warning: source ../abi is not a readable file or directory... skipping. warning: source ../boot is not a readable file or directory... skipping. warning: source ../kernel is not a readable file or directory... skipping. warning: source ../uspace is not a readable file or directory... skipping. Reading and parsing tag files Parsing files Building group list... Building directory list... Building namespace list... Building file list... Building class list... Associating documentation with classes... Computing nesting relations for classes... Building example list... Searching for enumerations... Searching for documented typedefs... Searching for members imported via using declarations... Searching for included using directives... Searching for documented variables... Building interface member list... Building member list... Searching for friends... Searching for documented defines... Computing class inheritance relations... Computing class usage relations... Flushing cached template relations that have become invalid... Computing class relations... Add enum values to enums... Searching for member function documentation... Creating members for template instances... Building page list... Search for main page... Computing page relations... Determining the scope of groups... Sorting lists... Freeing entry tree Determining which enums are documented Computing member relations... Building full member lists recursively... Adding members to member groups. Computing member references... Inheriting documentation... Generating disk names... Adding source references... Adding xrefitems... Sorting member lists... Computing dependencies between directories... Generating citations page... Counting data structures... Resolving user defined references... Finding anchors and sections in the documentation... Transferring function references... Combining using relations... Adding members to index pages... Generating style sheet... Generating search indices... Generating example documentation... Generating file sources... Generating file documentation... Generating page documentation... Generating group documentation... Generating class documentation... Generating namespace index... Generating graph info page... Generating directory documentation... Generating index page... Generating page index... Generating module index... Generating namespace index... Generating namespace member index... Generating annotated compound index... Generating alphabetical compound index... Generating hierarchical class index... Generating member index... Generating file index... Generating file member index... Generating example index... finalizing index lists... writing tag file... lookup cache used 0/65536 hits=0 misses=0 finished... }}} Note that my build directory is a sibling of the source directory. However, I get the same error even if the build directory is a son of the source directory." Jakub Jermář 805 Debug session not cleaned up if debugger gets killed helenos/unspecified mainline defect new 2019-10-02T15:36:39+02:00 2019-10-02T18:09:37+02:00 "Any number of tasks might have a phone Pn open to a target task T's kbox. At most one of them has an open debugging session (the debugger D). If a Pn is hung up, we call kbox_proc_phone_hungup(), which detects using call->sender == TASK->udebug.debugger that the sending task is D and it cleans up the debug session, unfreezing T. Now if we kill D in the middle of a debugging session, ipc_cleanup() -> phone_cap_cleanup_cb -> ipc_phone_hangup which sends hangup_call which has ->sender initialized to NULL. This causes a problem since kbox_proc_phone_hungup() will see call->sender (NULL) != TASK->udebug.debugger and will not clean up the debugging session, leaving the task frozen." Jiri Svoboda 806 Trace/command freezes for some commands helenos/app/trace mainline defect new 2019-10-02T16:21:11+02:00 2019-10-02T16:28:20+02:00 "When I run {{{trace +s }}} for some commands like {{{/app/pkg}}} or {{{/app/tester}}}, it will produce a certain amount of output and then the command appears hung, not reacting to Ctrl-Q. Killing either trace or the target task has no effect, but here there might be interaction with #805. For some other commands, like the GUI ones ({{{/app/vdemo comp:0/winreg}}}, {{{/app/vlaunch comp:0/winreg}}}) the trace runs to completion and terminates fine. Also, attaching to a running task and then quitting with Ctrl-Q works fine." Jiri Svoboda 810 Run all unit tests as part of CI ci mainline enhancement new 2019-10-05T14:59:52+02:00 2019-10-05T14:59:52+02:00 "We have a slowly, but steadily growing collection of PCUT-based unit tests, that sometimes fail (#801, #802, #807) (i.e. the tests actually seem to be doing useful work). However, failures are only found incidentally if somebody happens to run the tests by hand. We should run these tests as part of CI (e.g. ci.helenos.org) to detect failures as soon as possible." Jiri Svoboda 811 "PCUT should not prefix test case identifiers with ""test_""" helenos/lib/other mainline defect new 2019-11-09T23:01:54+01:00 2022-01-31T17:05:29+01:00 "Declaring something like {{{ int test_foo; PCUT_TEST(foo) { ... } }}} fails to compile because {{{foo}}} is mangled to {{{test_foo}}}. Perhaps test case identifiers should be mangled to something that the programmer is less likely to use accidentally, such as {{{_test_}}} or {{{_pcut_}}}, for example." Jiri Svoboda 820 Changing ninja config from CONFIG_SMP to !CONFIG_SMP and vice versa breaks the build helenos-build mainline 0.14.2 defect new 2020-09-25T21:25:51+02:00 2024-03-19T08:39:26+01:00 "On HelenOS master, running ninja config in a configured build directory and toggling CONFIG_SMP (Support for SMP), results in build errors: When switching from !CONFIG_SMP to CONFIG_SMP: {{{ 5/1645] Linking target kernel/kernel.1.elf FAILED: kernel/kernel.1.elf /usr/local/cross/bin/amd64-helenos-gcc -o kernel/kernel.1.elf kernel/kernel.1.elf.p/meson-generated_.._empty_map.S.o -Wl,--as-needed -Wl,--no-undefined -Wl,--whole-archive -Wl,--start-group kernel/libinstrumentables.a kernel/libnoninstrumentables.a -Wl,--end-group -Wl,--no-whole-archive -Wl,--gc-sections -Wl,--warn-common -Wl,--fatal-warnings -O3 -fexec-charset=UTF-8 -finput-charset=UTF-8 -Wa,--fatal-warnings -Wall -Wextra -Werror-implicit-function-declaration -Wwrite-strings -Wunknown-pragmas -Wno-unused-parameter -pipe -ffunction-sections -fno-common -fdebug-prefix-map=/home/jermar/software/HelenOS/helenos=. -Wsystem-headers -fvar-tracking-assignments -Werror -Wmissing-prototypes -Wno-missing-braces -Wno-missing-field-initializers -Wno-unused-parameter -Wno-clobbered -Wno-nonnull-compare -fno-builtin-strftime -D__LE__ -fno-omit-frame-pointer -mno-sse -mno-sse2 -mcmodel=kernel -mno-red-zone -fno-unwind-tables -march=opteron -imacros /home/jermar/software/HelenOS/build-up-amd64/config.h -D_HELENOS_SOURCE -DKERNEL -DHELENOS_RELEASE=0.9.1 '-DHELENOS_COPYRIGHT=Copyright (c) 2001-2019 HelenOS project' -DHELENOS_CODENAME=Armonia -D__64_BITS__ -ffreestanding -Wno-cast-function-type -Wl,-z,max-page-size=0x1000 -nostdlib -Wl,--no-gc-sections -Wl,--nmagic -T /home/jermar/software/HelenOS/build-up-amd64/kernel/_link.ld -Wl,-Map,/home/jermar/software/HelenOS/build-up-amd64/kernel/kernel.1.elf.map /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: kernel/libnoninstrumentables.a(arch_amd64_src_smp_ap.S.o): in function `unmapped_ap_boot': (K_TEXT_START+0x9): undefined reference to `ap_gdtr' /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: kernel/libnoninstrumentables.a(arch_amd64_src_smp_apic.c.o): in function `l_apic_send_init_ipi': apic.c:(.text.l_apic_send_init_ipi+0xf5): undefined reference to `ap_boot' /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: kernel/libnoninstrumentables.a(arch_amd64_src_smp_smp.c.o): in function `kmp': smp.c:(.text.kmp+0x7b): undefined reference to `ap_boot' /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: smp.c:(.text.kmp+0x1ad): undefined reference to `protected_ap_gdtr' /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: smp.c:(.text.kmp+0x1bc): undefined reference to `protected_ap_gdtr' collect2: error: ld returned 1 exit status [14/1645] Compiling C object uspace/lib/libc.so.0.0.p/c_generic_strtol.c.o ninja: build stopped: subcommand failed. }}} And when switching from CONFIG_SMP to !CONFIG_SMP: {{{ [2/1735] Linking target kernel/kernel.1.elf FAILED: kernel/kernel.1.elf /usr/local/cross/bin/amd64-helenos-gcc -o kernel/kernel.1.elf kernel/kernel.1.elf.p/meson-generated_.._empty_map.S.o -Wl,--as-needed -Wl,--no-undefined -Wl,--whole-archive -Wl,--start-group kernel/libinstrumentables.a kernel/libnoninstrumentables.a -Wl,--end-group -Wl,--no-whole-archive -Wl,--gc-sections -Wl,--warn-common -Wl,--fatal-warnings -O3 -fexec-charset=UTF-8 -finput-charset=UTF-8 -Wa,--fatal-warnings -Wall -Wextra -Werror-implicit-function-declaration -Wwrite-strings -Wunknown-pragmas -Wno-unused-parameter -pipe -ffunction-sections -fno-common -fdebug-prefix-map=/home/jermar/software/HelenOS/helenos=. -Wsystem-headers -fvar-tracking-assignments -Werror -Wmissing-prototypes -Wno-missing-braces -Wno-missing-field-initializers -Wno-unused-parameter -Wno-clobbered -Wno-nonnull-compare -fno-builtin-strftime -D__LE__ -fno-omit-frame-pointer -mno-sse -mno-sse2 -mcmodel=kernel -mno-red-zone -fno-unwind-tables -march=opteron -imacros /home/jermar/software/HelenOS/build-amd64/config.h -D_HELENOS_SOURCE -DKERNEL -DHELENOS_RELEASE=0.9.1 '-DHELENOS_COPYRIGHT=Copyright (c) 2001-2019 HelenOS project' -DHELENOS_CODENAME=Armonia -D__64_BITS__ -ffreestanding -Wno-cast-function-type -Wl,-z,max-page-size=0x1000 -nostdlib -Wl,--no-gc-sections -Wl,--nmagic -T /home/jermar/software/HelenOS/build-amd64/kernel/_link.ld -Wl,-Map,/home/jermar/software/HelenOS/build-amd64/kernel/kernel.1.elf.map /usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld:/home/jermar/software/HelenOS/build-amd64/kernel/_link.ld:27: undefined symbol `unmapped_ap_boot' referenced in expression collect2: error: ld returned 1 exit status [11/1735] Compiling C object uspace/lib/libc.so.0.0.p/c_generic_elf_elf_mod.c.o ninja: build stopped: subcommand failed. }}}" Jakub Jermář 835 New, non UNIX-like shell helenos/unspecified mainline enhancement Jiri Svoboda assigned 2021-08-10T18:35:34+02:00 2021-08-10T18:58:14+02:00 "HelenOS getting a UNIX-like shell was kind of a historical accident (and I had planned for a non-UNIX shell from the beginning). It gives off the wrong first impression and generally sends people down the wrong route - trying to copy more and more UNIX features. Bdsh was, from the start, written as a dual Linux/HelenOS shell. We need a new shell that is clearly non-UNIX, follows human-centric design principles (such as printing numbers in human-readable numbers by default, requiring confirmation of destructive actions by default, etc.) I plan to make this change once a file manager is available and the shell is not the first interface of choice for the first time user. In an OS that provides 'better' user interfaces in the form of a graphical and text-based file manager, what is the role of an (interactive) command line interface? To please the traditionalist mind/power user? To function on a dumb terminal/teletype(sic! [https://en.wikipedia.org/wiki/Teleprinter]) where pseudo-graphics is unavailable/impractical? To lend itself to scripting as well?" Jiri Svoboda 836 File Manager helenos/unspecified mainline enhancement Jiri Svoboda assigned 2021-08-10T18:56:47+02:00 2021-12-20T22:04:26+01:00 Create an interactive, panel-based file manager for HelenOS. It will use libui to draw its user interface and initially it will run in text mode. Jiri Svoboda 842 Support PCnet-FAST III (Am79c973) network adapter helenos/unspecified mainline enhancement new 2021-11-08T21:24:16+01:00 2021-11-10T20:03:26+01:00 "In !VirtualBox, when you create a new VM with OS set to Other - !Other/Unknown (64-bit), the default network adapter being emulate is PCnet-FAST III (PCI ID 1022:2000). Supporting this adapter in HelenOS would simplify getting networking running in !VirtualBox and increase the chance that a random person will get it to work. (Not to mention the possibility to use the actual HW)." Jiri Svoboda 843 s3c24xx_ts driver should not be used on other platforms than GTA02 helenos/unspecified mainline 0.14.2 defect new 2021-11-10T10:12:15+01:00 2024-03-19T08:40:18+01:00 s3c24xx_ts is a non-DDI driver (i.e. a regular server in srv/hid/s3c24xx_ts) that drives the GTA02's touch screen controller. Currently it is built, delivered to ramdisk and executed on PC (ia32/amd64), ski and probably many other platforms. This does not make sense. Jiri Svoboda 845 sparc64/ultra should support keyboard in Qemu helenos/unspecified mainline enhancement new 2021-11-11T12:21:19+01:00 2021-12-30T00:05:04+01:00 sparc64/ultra supports graphical output + keyboard on some real Ultra models, but not on the model emulated by Qemu. Regardless whether the model emulated by Qemu is a real one or not, we should support it for better user experience in this emulator. Jiri Svoboda 855 System sometimes does not boot fully up to GUI helenos/unspecified mainline 0.14.2 defect new 2023-01-08T19:25:07+01:00 2024-03-19T08:42:36+01:00 "Sometimes the system does not boot fully up (amd64 build, Qemu). We can see kernel log messages on the screen (from ps2mouse, usbhub, devman, usbhid, dhcp, vbd, ata_bd, volsrv), but the desktop does not appear. When I try to press some keys, nothing happens. This means the kernel console is no longer active (TODO detailed analysis). This happens sometimes/randomly without altering or rebuilding the code. I don't have any way of reproducing it and it happens pretty rarely. I've been observing this occasionally over the course of at least months (if not a couple of years). " Jiri Svoboda 856 XHCI driver does not start reliably on amd64 helenos/drv/other mainline 0.14.2 defect new 2023-02-02T15:35:34+01:00 2024-03-19T08:42:15+01:00 "When starting the XHCI driver, there appears to be a race condition that prevents it from starting in some cases. Steps to reproduce: Configure HelenOS for amd64 with UEFI and SMP. Launch QEMU with UEFI firmware (EDK2): qemu-system-x86_64 -enable-kvm --bios OVMF.fd -drive file=hdisk.img,index=0,media=disk,format=raw -device e1000 -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd -device intel-hda -device hda-duplex -serial mon:stdio -boot d -cdrom image.iso OVMF.fd is the firmware description from EDK2 build. The symptom will be that although you can use the mouse (it falls back to PS2 mouse), the usb-kbd will be inoperable and you can't type. You will see xhci does not register the devices, but does not report an error either. The issue is sensitive to timing or sequencing, and does not happen in all cases. To try to trigger it, it helps to add ""fibril_usleep(10000);"" to line 357 (at the bottom of xhci_event_ring_init, before ""fibril_mutex_initialize(&ring->guard);"") of trb_ring.c in the xhci driver code. I use values around 10000 or so and it usually causes the issue but you might need to try 50000, 100000, etc, although if you set it too long it might start working again. Note that changing the log warning level to get debug information will also alter timing, so it is challenging to investigate. This problem can also be triggered on Mac Mini hardware, although in that case there is no PS2 fallback. " Colin Parker 857 /app/cpptest killed due to an exception at program counter 0x0000000000000000. helenos/app/other mainline 0.14.2 defect new 2023-02-05T11:26:08+01:00 2024-03-19T08:43:24+01:00 "cpptest result in a ""crash"": [/app/launcher(59)] launcher: Spawning /app/terminal /app/terminal -d disp@?idev=58 Task /app/cpptest (80) killed due to an exception at program counter 0x0000000000000000. cs =0x0000000000000023 rip=0x0000000000000000 rfl=0x0000000000210246 err=0x0000000000000014 ss =0x000000000000001b rax=0x0000000000402250 rbx=0x000000000040c490 rcx=0x000000000040c000 rdx=0x000000000040c490 rsi=0x0000000000000001 rdi=0x0000000000403fb0 rbp=0x0000000070142db0 rsp=0x0000000070142d58 r8 =0x0000000000000101 r9 =0x0000000000000060 r10=0x0000000000000101 r11=0xfffffffffffffff0 r12=0x0000000000000000 r13=0x0000000000000000 r14=0x0000000000403fb0 r15=0x000000000040c490 0x0000000070142db0: 0x0000000000000000() 0x0000000070142df0: 0x000000007015509b() 0x0000000070142e10: 0x0000000000400f83() 0x0000000070142e20: 0x0000000000400ee9() Kill message: Page fault: 0x0000000000000000. [/srv/taskmon(16)] taskmon: Task 80 fault in thread 0xffffffff85e677a0. [/srv/taskmon(16)] taskmon: Executing /app/taskdump -t 80 [/app/taskdump(81)] Task Dump Utility [/app/taskdump(81)] Dumping task '/app/cpptest' (task ID 80). [/app/taskdump(81)] Loaded symbol table from /app/cpptest [/app/taskdump(81)] Threads: [/app/taskdump(81)] [1] hash: 0xffffffff85e677a0 [/app/taskdump(81)] Thread 0xffffffff85e677a0: PC = 0x0000000000000000 (putchar+0). FP = 0x0000000070142db0 [/app/taskdump(81)] 0x0000000070142db0: 0x0000000000000000 (putchar+0) [/app/taskdump(81)] 0x0000000070142df0: 0x000000007015509b (_end+1876241075) [/app/taskdump(81)] 0x0000000070142e10: 0x0000000000400f83 (__c_start+147) [/app/taskdump(81)] 0x0000000070142e20: 0x0000000000400ee9 (_start+12) [/app/taskdump(81)] Address space areas: [/app/taskdump(81)] [1] flags: R-XC base: 0x0000000000400000 size: 8192 [/app/taskdump(81)] [2] flags: RW-C base: 0x0000000000402000 size: 4096 [/app/taskdump(81)] [3] flags: RW-C base: 0x0000000000403000 size: 4096 [/app/taskdump(81)] [4] flags: RW-C base: 0x0000000000405000 size: 4096 [/app/taskdump(81)] [5] flags: RW-C base: 0x0000000000407000 size: 4096 [/app/taskdump(81)] [6] flags: RW-C base: 0x0000000000409000 size: 4096 [/app/taskdump(81)] [7] flags: R--C base: 0x000000000040b000 size: 4096 [/app/taskdump(81)] [8] flags: RW-C base: 0x000000000040c000 size: 4096 [/app/taskdump(81)] [9] flags: R-XC base: 0x0000000070000000 size: 98304 [/app/taskdump(81)] [10] flags: RW-C base: 0x0000000070018000 size: 126976 [/app/taskdump(81)] [11] flags: RW-C base: 0x0000000070037000 size: 4096 [/app/taskdump(81)] [12] flags: RW-C base: 0x0000000070038000 size: 4096 [/app/taskdump(81)] [13] flags: RW-C base: 0x000000007003a000 size: 4096 [/app/taskdump(81)] [14] flags: RW-C base: 0x000000007003c000 size: 4096 [/app/taskdump(81)] [15] flags: RW-C base: 0x000000007003e000 size: 4096 [/app/taskdump(81)] [16] flags: R--C base: 0x0000000070040000 size: 4096 [/app/taskdump(81)] [17] flags: RW-C base: 0x0000000070041000 size: 4096 [/app/taskdump(81)] [18] flags: RW-C base: 0x0000000070043000 size: 1048576 [/app/taskdump(81)] [19] flags: R-XC base: 0x0000000070144000 size: 323584 [/app/taskdump(81)] [20] flags: RW-C base: 0x0000000070193000 size: 131072 [/app/taskdump(81)] [21] flags: R-XC base: 0x00000000701b3000 size: 479232 [/app/taskdump(81)] [22] flags: RW-C base: 0x0000000070228000 size: 16384 [/app/taskdump(81)] [23] flags: RW-C base: 0x00007ffffff00000 size: 1048576 [/app/taskdump(81)] Failed dumping fibrils. [paul@fedora amd64]$ commit c1b073b79d93be484c1277800ebe22a898153e70 (HEAD -> master, origin/master, origin/HEAD) Author: Jiří Zárevúcky Date: Sat Feb 4 18:20:04 2023 +0100 Remove some unnecessary #ifdefs I have the feeling (unsure) it was working 2 days ago. Built with toolchain.sh." Paul Dufresne 858 i8042 driver loads the processor when HW not present helenos/drv/other mainline 0.14.2 defect new 2023-02-08T03:13:58+01:00 2024-03-19T08:38:58+01:00 "Not all amd64-based PCs have functional i8042 HW (e.g. Apple products). Because the i8042 driver repeatedly polls the ""ready"" status, this results in severe performance reduction on these systems, as the device is never ready and 100% of available CPU cycles are used checking this over and over. I have a proposed remedy, which times out and aborts the driver after 100 ms (attached i8042.c): https://github.com/cvparker/helenos/commit/2ef2f0ed5278613e58d96e85f1bec6d8070856ae" Colin Parker 859 Build with Detailed kernel logging enabled fails helenos/unspecified mainline 0.14.2 defect Jiří Zárevúcky assigned 2023-05-30T14:55:55+02:00 2024-03-19T08:44:33+01:00 "When I try to build the OS with Detailed kernel logging build option enabled, the build fails with: {{{ In file included from ../kernel/generic/src/main/main.c:50: ../kernel/generic/src/main/main.c: In function 'main_bsp_separated_stack': ../kernel/generic/src/main/main.c:198:21: error: 'config_t' {aka 'struct '} has no member named 'stack_base' (void *) config.stack_base, config.stack_size); ^ ../kernel/generic/include/debug.h:57:9: note: in definition of macro 'LOG' ##__VA_ARGS__); \ ^~~~~~~~~~~ ../kernel/generic/src/main/main.c:198:40: error: 'config_t' {aka 'struct '} has no member named 'stack_size' (void *) config.stack_base, config.stack_size); ^ ../kernel/generic/include/debug.h:57:9: note: in definition of macro 'LOG' ##__VA_ARGS__); \ ^~~~~~~~~~~ [10/1716] Compiling C object kernel/li...mentables.a.p/generic_src_mm_frame.c.o ninja: build stopped: subcommand failed. }}} Presumably this problem was introduced with this commit: {{{ commit 65f3117b0c526538a5c5e972042a0bf4f1a325e1 Author: Jiří Zárevúcky Date: Tue Feb 14 14:38:14 2023 +0100 Make bootstrap stack statically, rather than dynamically allocated With aligment requirements being part of the language now, it is simple to allocate the extra stack area in kernel data, and we don't need to go to so much trouble with manual allocation. It also makes it slightly more straightforward to use the stack from assembly, without having to dig through a saved context structure. }}}" Jiri Svoboda 863 tester malloc3 causes kernel panic on QEMU 7.2/8.0 (amd64) helenos/unspecified mainline defect new 2023-10-19T21:11:59+02:00 2023-10-19T21:54:15+02:00 "This happens at least with QEMU 7.2 and QEMU 8.0, as of commit d4643dba... and also going several years back, so it's not a recent regression, but seems to be some kind of interaction with newer QEMU versions, as QEMU 6.2.0 built from source does not trigger this. Should be worth investigating. {{{ Thread 75 waiting for 1 frames 3145847 available. ######> Kernel panic on cpu0 due to a bad memory access while storing to address 0x0000000000000008. <###### CURRENT=0xffffffff81fd4000: pe=0 thread=0xffffffff81efc510 task=0xffffffff81efb4a0 cpu=0xffffffff8188c810 as=0xffffffff8173f8f0 magic=0xfacefeed thread=""uinit"" task=""/srv/klog"" cs =0x0000000000000008 rip=0xffffffff80143bbb rfl=0x0000000000210286 err=0x0000000000000002 rax=0x0000000000000010 rbx=0x0000000000001000 rcx=0xffffffff8188c810 rdx=0x0000000000000000 rsi=0x0000000000000001 rdi=0xffffffff801605c0 rbp=0xffffffff81fd4e50 rsp=0xffffffff81fd4e10 r8 =0xffffffff80174080 r9 =0x00000000000019fd r10=0x0000000000000001 r11=0xffffffff8173c10f r12=0x000000000000000b r13=0x0000000000000000 r14=0x000000000050dee8 r15=0x0000000000000000 0xffffffff81fd4bd0: kernel/libnoninstrumentables.a.p/generic_src_debug_stacktrace.c()+0x0000000000000119 0xffffffff81fd4c70: kernel/libnoninstrumentables.a.p/generic_src_debug_panic.c.o:.t()+0x00000000000001ae 0xffffffff81fd4cf0: kernel/libinstrumentables.a.p/generic_src_mm_as.c.o:.text()+0x0000000000002869 0xffffffff81fd4d50: kernel/libinstrumentables.a.p/generic_src_interrupt_interrupt.c()+0x0000000000000406 0xffffffff81fd4de0: kernel/libnoninstrumentables.a.p/arch_amd64_src_asm.S.o:int_14()+0x00000000000000b2 0xffffffff81fd4e50: kernel/libnoninstrumentables.a.p/generic_src_mm_malloc.c.o:.tex()+0x0000000000000310 0xffffffff81fd4eb0: kernel/libnoninstrumentables.a.p/generic_src_log_log.c.o:.text()+0x0000000000000866 0xffffffff81fd4f30: kernel/libnoninstrumentables.a.p/generic_src_syscall_syscall.c.()+0x00000000000000bd 0xffffffff81fd4fc0: kernel/libnoninstrumentables.a.p/arch_amd64_src_asm.S.o:syscall()+0x00000000000000bc cpu0: halted }}}" Jiří Zárevúcky 865 TCP is much slower than expected helenos/unspecified mainline defect new 2024-01-09T15:25:12+01:00 2024-01-09T15:25:12+01:00 "TCP transfer rate is *very* low, much lower than expected (more than 16-times). In a nutshell, I would expect up to ~3 MB/s on my machine, but I get ~200 kB/s. Note that this enigmatic problem exists since the beginning of the TCP implementation. Internal TCP transfer rate between two HelenOS tasks is almost exactly twice as slow as rate of transferring TCP out from HelenOS or into HelenOS from outside. This suggests that it's HelenOS TCP that incurs the penalty. I also seem to remember that if we transfer 2x larger TCP PDUs, we get 2x the transfer rate. I tried disabling retransmission timers to see if they had an effect. This improved the transfer rate slightly, but not significantly. The fact that the network stack transfers data using IPC writes incurs an upper limit on the transfer rate, but it is significantly larger. See below for detailed measurements of rate of transferring out of HelenOS, into HelenOS, between two tasks in HelenOS, plus IPC baseline transfer rate measurement. === Upload to host rate === method: {{{ # mkfile -p -s 16m /data/web/test # websrv $ wget http://127.0.0.1/test [read kB/s from wget] }}} ns_ping gives 46000 ops/s 4 hops: websrv->tcp, tcp->ip, ip->ethip, ethip->e1k data is sent in 1024B segments (based on BUFFER_SIZE in websrv) baseline: 210 kB/s no FS: 261 kB/s no FS + no RT: 280-300 kB/S === Download from host rate === method: {{{ $ cd /tmp $ dd if=/dev/zero of=test bs=1024k count=16 $ cat >lighttpd.conf server.document-root = ""/tmp"" server.port = 3000 $ lighttpd -D -f lighttpd.conf # cd /tmp # download -o test http://:3000/test [measure number of seconds taken and compute transfer rate] }}} no FS + no RT: 290 kB/S === Internal OS transfer rate === method: {{{ # mkfile -p -s 8m /data/web/test # websrv # download -o /tmp/test http://127.0.0.1:8080/test [measure time taken in seconds, compute transfer rate] }}} baseline: 145 kB/s [note: one half upload/download, exactly to measuring precision!] === IPC 1kB block transfer rate === hbench write1k: 13.5 MiB / s method: {{{ # /srv/test/ipc-test # hbench write1k }}} nic->ethip->ip->tcp->app = 4 hops 4 hop transfer rate estimate: 13.5 MiB / s / 4 = 3.375 MiB / s 3.375 / 0.21 = 16.875 So we are at least 16 times slower than what is the limit based on the method used to transfer data via IPC. " Jiri Svoboda 866 console input freezes on ia64/ski after GCC upgrade helenos/kernel/ia64 mainline 0.14.2 defect new 2024-01-22T17:35:40+01:00 2024-03-27T13:35:57+01:00 It seems that after we upgraded GCC to version 13.2, console input in the IA-64 ski emulator always freezes a couple of seconds after boot. With old GCC 8.2.0, this doesn't happen as far as I can tell. Jiří Zárevúcky 867 486 build fails helenos/kernel/ia32 mainline 0.14.2 defect new 2024-02-08T11:14:30+01:00 2024-03-19T08:41:21+01:00 "In file included from ../kernel/arch/ia32/src/ia32.c:63: ../kernel/arch/ia32/include/arch/mm/pat.h: In function 'pat_set_mapping': ../kernel/arch/ia32/include/arch/mm/pat.h:62:22: error: implicit declaration of function 'read_msr' [-Werror=implicit-function-declaration] 62 | uint64_t r = read_msr(MSR_IA32_PAT); | ^~~~~~~~ ../kernel/arch/ia32/include/arch/mm/pat.h:65:9: error: implicit declaration of function 'write_msr'; did you mean 'write_dr7'? [-Werror=implicit-function-declaration] 65 | write_msr(MSR_IA32_PAT, r); | ^~~~~~~~~ | write_dr7 cc1: all warnings being treated as errors [17/2132] Compiling C object kernel/li...entables.a.p/genarch_src_acpi_acpi.c.o ninja: build stopped: subcommand failed. [jirka@omelette build-486]$ " Jiri Svoboda 868 Block cache and page out helenos/unspecified mainline enhancement new 2024-02-16T08:55:00+01:00 2024-03-19T08:40:46+01:00 "Design and implement architecture for managing block cache and paging out in microkernel environment. All pages except those allocated to kernel structures are available either to user pages or block cache. Recently unused user pages can be paged out in favor of recently accessed blocks and vice versa. Benefits: * should help improve filesystem performace * allow more functionality in an environment where primary memory is limited This would be an ideal topic for a master thesis." Jiri Svoboda 869 Global chroot helenos/srv/vfs mainline enhancement new 2024-03-06T12:40:36+01:00 2024-03-06T12:40:36+01:00 "Add VFS method to simultaneously switch the global root of the OS into a subdirectory. This currently appears the most simple and straightforward mechanism for 'hiding' a two-stage boot." Jiri Svoboda