OSDev.org

Hello everyone,

Today, I'm pleased to announce the release of FiwixOS 3.3.

The major highlights in this release are:

• Fiwix kernel version 1.5.0 (see detailed changes below).
  FiwixOS has now its own repository which includes the scripts to generate the installation media.
  Added DMA support and 32bit I/O data transfers in the ATA driver.
  Overall improvements in the disk access (specially under QEMU).
  Improvements and bug fixes in the buffer cache and memory management.
  Most kernel structures are now dynamically allocated which reduces the kernel memory footprint.
  Added the file /proc/buddyinfo to keep track the new kernel memory allocator.
  New kernel process called kbdflushd that flushes dirty buffers periodically.
  Added support for the Bochs Graphics Adapter with the new kernel parameter bga=.
  Added support for multiple RAMdisk drives.
  Added kexec implementation.
  Added microsecond resolution to sys_gettimeofday.
  Added the magic SysRq key Alt+SysRq+m to show current memory information.
  Added the /proc/<PID>/fd subdirectory containing symbolic links named by its file descriptor.
  Added support for 64bit offsets which helps to have filesystems bigger than 4GiB.
  Added support for the virtual memory split 2GiB(user)/2GiB(kernel).
  Added support for large initrd images.
  Added the following new system calls: sys_lchown, sys_readv, sys_writev and sys_mmap2.
  The kernel now mounts the root filesystem in read-only mode by default.
  The Minix filesystem is now optional when building the kernel.
  The installation process includes a minimal install for very reduced disk sizes (~200MiB).
  FiwixOS can be installed on a specific partition.
  GRUB installation is now optional.
  Several segmentation faults specially during package building will no longer appear as a result of adding the Bash configuration option --without-bash-malloc. This turns off the use of Bash's memory allocation (malloc) function which is known to cause segmentation faults.
  Massive kernel bug fixing.
  Improvements and bug fixes in the system environment.

Check the release notes: https://www.fiwix.org/news/20231115.html

As always, I'll appreciate any feedback if you install FiwixOS 3.3.
Thanks!

Are you on a yearly release cycle? FiwixOS 3.2 was announced on the same day last year

Just had a play in QEMU, and as before, looks great. Been a while since I've fired up DOOM.

thewrongchristian wrote:Are you on a yearly release cycle? FiwixOS 3.2 was announced on the same day last year

Yes!, I found it fun to release it exactly one year later. I'll continue doing it as long as time permits.

thewrongchristian wrote:Just had a play in QEMU, and as before, looks great. Been a while since I've fired up DOOM.

DOOM performs very well and its fully playable. The only downside is the lack of sound.
Thanks for your feedback!

I've found what looks like might be a memory leak.

If I run:
Repeatedly running this, the figures stay pretty static.

But if I run
The 256 pool figure increases monotonically each page. If I run two of the above in their own virtual terminal, it increases by 2.

If I run:
Then the 256 figure also goes up, so I suspect the issue is in your pipe implementation.

Yes, it might look like a memory leak but is not. It's just that every time you use a pipe, the pipefs requests a new inode.
Depending on the system memory, the kernel will have a small or a big inode table to hold n inodes, which will be available for all the sub-systems in the kernel.
Eventually the kernel will start reusing inodes as soon as the inode table is full.

Mikaku wrote:Eventually the kernel will start reusing inodes as soon as the inode table is full.

Is there a reason you don't just reuse inodes as soon as free ones are available? Unlike with PIDs, I know of few issues in reusing inodes.

nullplan wrote:Is there a reason you don't just reuse inodes as soon as free ones are available? Unlike with PIDs, I know of few issues in reusing inodes.

PIDs or buffers must be treated differently. For instance, PIDs are not cached, and buffers (which are indeed cacheable) need to know the block before returning a buffer. So the buffer cache mechanism can reuse a previous buffer if it already exists in the cache.

When a subsystem requires an inode, it doesn't know which inode number will eventually have because of the different levels involved. So, reusing inodes prematurely could kill the cache effect.

Of course, all this might sound inefficient and could be improved.

OSDEV admins: I'm having big problems to keep my session alive for more than a simple minute in this forum. This makes almost impossible to reply someone's message without losing the session and having to start over again and again.

Mikaku wrote:Of course, all this might sound inefficient and could be improved.

No worries, I was just asking. At first glance it does seem inefficient to fill all of memory up with old inodes and free them only once other stuff is needed. On the other hand, I know that free memory is wasted memory, so buffer away.

Mikaku wrote:OSDEV admins: I'm having big problems to keep my session alive for more than a simple minute in this forum. This makes almost impossible to reply someone's message without losing the session and having to start over again and again.

Try clicking the "keep me logged in" checkbox on login. Apparently, the other day the server had some issues with MySQL ("too many instances"), and I guess it was rebooted, cause I was suddenly logged out after the speed problem was fixed. But if you forget the "keep me logged in" checkbox then, you get logged out constantly. A minute does seem shorter than what I get even without this checkbox, so you may have a problem retaining the osdev cookie that keeps you logged in. So do check your browser settings. Oh, and there is only one admin here; his name is chase and he only comes out of hibernation when there are serious issues that the mods can't solve.

nullplan wrote:No worries, I was just asking. At first glance it does seem inefficient to fill all of memory up with old inodes and free them only once other stuff is needed. On the other hand, I know that free memory is wasted memory, so buffer away.

Well, I've been thinking about it during my Sunday's morning hiking and I think I could add an exception to avoid caching inodes from pseudo-filesystems like pipefs, procfs, sockfs, etc. I'll think more about it.

nullplan wrote:Try clicking the "keep me logged in" checkbox on login. Apparently, the other day the server had some issues with MySQL ("too many instances"), and I guess it was rebooted, cause I was suddenly logged out after the speed problem was fixed. But if you forget the "keep me logged in" checkbox then, you get logged out constantly. A minute does seem shorter than what I get even without this checkbox, so you may have a problem retaining the osdev cookie that keeps you logged in. So do check your browser settings. Oh, and there is only one admin here; his name is chase and he only comes out of hibernation when there are serious issues that the mods can't solve.

The only checkbox options I see when I log in are:

[ ] Log me on automatically each visit
[ ] Hide my online status this session

I don't think there is a problem with my Firefox settings (they are the default mostly). I don't have any problems with other forums and I remember didn't have any problems here. Looks like a new behaviour. Perhaps the software that runs this Forum is getting old.

Mikaku wrote:The only checkbox options I see when I log in are:

[ ] Log me on automatically each visit
[ ] Hide my online status this session

I meant the upper one of these two. It has the effect of not letting the session cookie expire.

Mikaku wrote:Perhaps the software that runs this Forum is getting old.

Yeah, but it should still work as well as it ever did. Software has no parts that wear out, after all.

nullplan wrote:I meant the upper one of these two. It has the effect of not letting the session cookie expire.

I'm sorry, I don't see any other checkbox or link related to avoid cookie expiration.
Thanks anyway.

Try deleting all cookies related to this site. That often solves odd problems.

I think nullplan is referring to the “Log me on automatically each visit” one.

iansjack wrote:Try deleting all cookies related to this site. That often solves odd problems.

I'll do it. Thanks!

iansjack wrote:I think nullplan is referring to the “Log me on automatically each visit” one.

Ah!, sorry. I misunderstood that statement.
Thanks both for your assistance.