HelenOS: Ticket Queryhttp://www.helenos.org/query?status=closed&component=helenos%2Funspecified&milestone=0.7.2&group=resolution&order=id
HelenOS Operating Systemen-USHelenOShttp://www.helenos.org/chrome/site/helenos_banner.gifhttp://www.helenos.org/query?status=closed&component=helenos%2Funspecified&milestone=0.7.2&group=resolution&order=id
Trac 1.2.2http://www.helenos.org/ticket/568
http://www.helenos.org/ticket/568#568: Errno error codes should not be negativeTue, 12 Nov 2013 16:09:27 GMTJiri Svoboda<p>
In HelenOS errno.h (both kernel and user-space) defines error codes as negative (and EOK as zero). This conflicts with C standard errno.h that defines (many of the same) error codes as positive.
</p>
<p>
Since the goal is to try to align HelenOS kernel environment with C standard freestanding env. and userspace with C standard hosted env, this should be fixed.
</p>
Resultshttp://www.helenos.org/ticket/568#changeloghttp://www.helenos.org/ticket/654
http://www.helenos.org/ticket/654#654: C++ supportThu, 18 Feb 2016 18:31:24 GMTVojtech Horky<p>
Implement support for C++ in HelenOS to allow compilation and execution of C++ programs.
</p>
<dl class="wiki"><dt>Details</dt><dd>
Currently the only language that is fully supported for development of applications for HelenOS is plain C. While C is a good choice for kernel and low-level services, for more complex applications C++ might be a better choice. The goal of this ticket is to bring support for C++ to HelenOS, from toolchain installation to run-time support in HelenOS.
<br /><br />
HelenOS toolchain script already installs a C++ compiler (<code>g++</code>). Still some minor changes might be needed (probably in the form of <code>configure</code> options).
<br /><br />
Since all HelenOS components (kernel, userspace servers and utilities) are currently written in C, the build process compiles all source files with a C compiler. It would be necessary to add support for compilation of C++ programs, e.g. by automatic detection of <code>.cpp</code> files among the sources or by a manually specified flag.
<br /><br />
Next step is adding the run-time support for C++. The C++ compiler expects that a system library implementats functions needed for the support of exceptions (namely support for stack unwinding) and run-time type identification. There are two options: port the GCC-provided libraries or write implementation from scratch. The first option would probably require extensive patching as HelenOS is a non-POSIX environment but it would bring a full-fledged support. On the other hand, rudimentary support can be written from scratch and extra functionality might be added later, in an on-demand manner.
<br /><br />
Last step towards full C++ support is STL with <code>std::string</code>, containers and streams. Again, it is possible to write the library from scratch or port an existing solution.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
The obvious benefit when this task is completed is the ability to execute C++ programs inside HelenOS. That would give HelenOS developers more flexibility in development of new utilities and servers as another language would be supported. By adding the C++ support it would also be possible to upgrade the GCC version we currently use inside HelenOS (i.e. not the cross-compiler but the native compiler available through Coastline), bringing HelenOS one-more step closer to being self-hosted.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
medium to high
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C and C++ languages and the ability to survive in a non-standard non-POSIX application environment. Understanding of compiler internals would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs">DeveloperDocs</a>
</li><li><a class="ext-link" href="http://wiki.osdev.org/C%2B%2B"><span class="icon">​</span>On C++ run-time support (OSDev wiki)</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/PortingSoftware">Porting software to HelenOS</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Vojtech Horky
</dd></dl>
Resultshttp://www.helenos.org/ticket/654#changeloghttp://www.helenos.org/ticket/696
http://www.helenos.org/ticket/696#696: Three character device interfaces is a crowdFri, 06 Oct 2017 20:03:40 GMTJiri Svoboda<p>
Currently there are three different character device interfaces in use by different drivers:
</p>
<ul><li>uspace/lib/c/include/ipc/char.h (s3c24xx_uart)
</li><li>uspace/lib/c/include/ipc/chardev.h (pl050, i8042)
</li><li>uspace/lib/drv/include/ops/char_dev.h (ns8250, test1)
</li></ul><p>
Each interface has different pros and cons (both in terms of API and implementation).
</p>
<ul><li>char.h is can only transfer one byte at a time, but has asynchronous reception
</li><li>chardev.h has full client/server library wrappers (chardev_srv.c/chardev.c), it can only transfer a few bytes at a time
</li><li>char_dev.h can transfer up to 256 bytes using internal buffers whose size cannot be configured; it requires devman method dispatcher
</li></ul><p>
Ultimately we should have a single interface, hopefully better than each of those we currently have.
</p>
Resultshttp://www.helenos.org/ticket/696#changeloghttp://www.helenos.org/ticket/699
http://www.helenos.org/ticket/699#699: Serial console scrolling is slowSat, 21 Oct 2017 12:23:59 GMTJiri Svoboda<p>
As of <a class="missing changeset" title="No default repository defined">mainline,2820</a> if you build sparc64/ultra and run it in Qemu, we get to the text console. Scrolling in the console is slow. Instead of using the serial terminal's native scrolling capability, the screen seems to be manually redrawn (i.e. retransmitted). This looks like a regression.
</p>
Resultshttp://www.helenos.org/ticket/699#changeloghttp://www.helenos.org/ticket/706
http://www.helenos.org/ticket/706#706: async_usleep vs fibril_usleep vs thread_usleepWed, 08 Nov 2017 15:11:10 GMTJiri Svoboda<p>
async_usleep() and fibril_usleep() seem to be doing the same thing (differently). Some code uses one and other code uses the other. We should unify both. Some code even uses thread_usleep() which is wrong.
</p>
Resultshttp://www.helenos.org/ticket/706#changeloghttp://www.helenos.org/ticket/709
http://www.helenos.org/ticket/709#709: Enable toolchain.sh to cope with missing libraries automaticallyMon, 13 Nov 2017 21:16:34 GMTJiří Zárevúcky<p>
See also closed ticket <a class="closed ticket" href="http://www.helenos.org/ticket/705" title="#705: defect: Building toolchain fails on gcc after successfully building prerequsites (closed: worksforme)">#705</a>.
This already works for isl, and should be just as easy for the other libraries. It would be very convenient for the case when the developer doesn't have the ability to install packages on the machine they are building on.
</p>
Resultshttp://www.helenos.org/ticket/709#changeloghttp://www.helenos.org/ticket/713
http://www.helenos.org/ticket/713#713: Pcut test binaries don't summarize the resultsThu, 23 Nov 2017 09:10:50 GMTJiri Svoboda<p>
When you run a PCUT test binary, such as test-libc, it will run all the test suites. It will print the number of failed test cases for each of them. If there is a lot of tests, these will scroll away. At the end the only way to find out if there has been an error is to redirect the output to a file and then walk through it line-by-line checking for failure reports.
</p>
<p>
At the end the test binary should report an overall summary. Also in case of any errors the task should return non-zero exit code.
</p>
Resultshttp://www.helenos.org/ticket/713#changeloghttp://www.helenos.org/ticket/714
http://www.helenos.org/ticket/714#714: Pcut results reporting sets of mental alarmsThu, 23 Nov 2017 09:14:16 GMTJiri Svoboda<p>
Pcut reports the results of each test suite as (N of M failed). The sole appearance of the word 'failed' sets of mental alarms when one is quickly glancing through the results trying to look for failure.
</p>
<p>
If nothing failed there should be no words like failed or error.
</p>
<p>
E.g.:
all pass
</p>
<p>
or
</p>
<p>
N of M pass
N of M pass, Y failed (when Y &gt; 0)
</p>
<p>
or
</p>
<p>
total: N, passed: M
total: N, passed: M, failed: Y (when Y &gt; 0)
</p>
Resultshttp://www.helenos.org/ticket/714#changeloghttp://www.helenos.org/ticket/721
http://www.helenos.org/ticket/721#721: tools/ew.py: integratorcp broken by xhci additionTue, 06 Mar 2018 18:36:01 GMTJiří Zárevúcky<pre class="wiki">[jzr@blackbox helenos]$ python2 tools/ew.py
qemu-system-arm -M integratorcp -drive file=hdisk.img,index=0,media=disk,format=raw -usb -device nec-usb-xhci,id=xhci -device usb-tablet -kernel image.boot
qemu-system-arm: -device nec-usb-xhci,id=xhci: No 'PCI' bus found for device 'nec-usb-xhci'
</pre>Resultshttp://www.helenos.org/ticket/721#changeloghttp://www.helenos.org/ticket/731
http://www.helenos.org/ticket/731#731: tmpfs trips and kernel panicsFri, 08 Jun 2018 13:02:53 GMTJiri Svoboda<p>
To reproduce:
</p>
<pre class="wiki">1. $ make PROFILE=amd64
2. $ tools/ew.py
3. # cd /tmp
4. # cp /demo.txt .
5. # edit demo.txt
6. Ctrl-S (saving the file fails)
7. Ctrl-Q
8. # edit demo.txt (file appears empty)
9. Ctrl-S (saving the file succeeds)
10. Ctrl-Q
11. # ls (kernel panic)
</pre><p>
This problem does not occur on / (ext4fs).
</p>
Resultshttp://www.helenos.org/ticket/731#changeloghttp://www.helenos.org/ticket/727
http://www.helenos.org/ticket/727#727: pt_mapping_remove needs TLB shootdown before freeing framesFri, 23 Mar 2018 13:14:22 GMTJiří Zárevúcky<p>
<code>pt_mapping_remove</code> frees page table frames without any synchronization. This is incorrect on SMP systems. On some platfroms, intermediate page table addresses may be cached in TLB. On all platforms, a concurrent page table walk on another CPU could access page table contents after the frame has been recycled.
</p>
<p>
To solve this issue, the function needs to perform TLB shootdown after the empty page table is removed from the tree, but before it is freed.
</p>
Resultshttp://www.helenos.org/ticket/727#changeloghttp://www.helenos.org/ticket/705
http://www.helenos.org/ticket/705#705: Building toolchain fails on gcc after successfully building prerequsitesTue, 07 Nov 2017 12:05:45 GMTThomas<p>
Build env:
</p>
<ul><li>CentOS 7.4 x86_64, i686
</li><li>gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
</li><li>GNU Make 3.82
</li></ul><p>
Toolchain building fails with:
checking for objdir&hellip; .libs
checking for the correct version of gmp.h&hellip; yes
checking for the correct version of mpfr.h&hellip; yes
checking for the correct version of mpc.h&hellip; yes
checking for the correct version of the gmp/mpfr/mpc libraries&hellip; no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the &mdash;with-gmp, &mdash;with-mpfr and/or &mdash;with-mpc options to specify
their locations. Source code for these libraries can be found at
their respective hosting sites as well as at
<a class="ext-link" href="ftp://gcc.gnu.org/pub/gcc/infrastructure/"><span class="icon">​</span>ftp://gcc.gnu.org/pub/gcc/infrastructure/</a>. See also
<a class="ext-link" href="http://gcc.gnu.org/install/prerequisites.html"><span class="icon">​</span>http://gcc.gnu.org/install/prerequisites.html</a> for additional info. If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files. They may be located in separate packages.
</p>
Resultshttp://www.helenos.org/ticket/705#changelog