IRC channel logs

<almuhs>searching docs about translators, I've found this rumpaudio translator.

<almuhs> https://github.com/dm0-/hurd-rump-audio/tree/master

<almuhs>why this translator was not added to the hurd?

<youpi>because it was very experimental?

<almuhs>but, now, once we have a stable rumpkernel's port, can be possible continues this work

<damo22>i wanted to reuse ALSA drivers in a new framework

<damo22>because there are many more supported

<almuhs>ok, i understand

<damo22>also, to add it as a jack backend

<almuhs>but currently there are not any audio driver working, i think

<damo22>yeah we have a unique opportunity to get audio right

<almuhs>how?

<damo22>by not exposing a push model for audio

<damo22>instead, make the driver provide a jack api

<almuhs>good idea

<damo22>in video, nobody writes applications with open() read() write() and ioctl() directly to draw to the screen

<almuhs>true

<damo22>this is because there are realtime timing requirements of when to flip the screen pages

<almuhs>yes

<damo22>same with audio

<almuhs>pulseaudio is ported, so we need the backend

<damo22>no i would ignore pulse completely

<almuhs>oh

<damo22>just provide jack, and users who want pulse can use pipewire using the jack interface

<almuhs>it's good

<almuhs>pipewire allows manage video too

<damo22>id rather have a solid driver with jack api, the rest of the stack is irrelevant

<almuhs>yes

<damo22>linux does this with ALSA instead but its a little suboptimal

<almuhs>ALSA is very limited: can't reproduce audio from two sources at same time

<almuhs>**it can't

<damo22>ALSA isnt really a sound server its just a low level driver

<damo22>and it provides both push and/or pull model to access it

<almuhs>yes, although some distros offers it as sound server too

<almuhs>but with pulseaudio and pipewire, it's not necessary connect directly to ALSA

<damo22>yes it is. they both use ALSA as their driver

<damo22>but only one can use it

<almuhs>yes, by this reason it's not able playing audio from two apps at same time, if you use ALSA only

<almuhs>**it's not possible

<damo22>i want to create a jack backend using one of the ALSA driver low level struct of functions

<damo22>once i port this as an audio streamer, i can add more card support

<damo22>since all the ALSA drivers are in the same format

<almuhs>yes, it's fine

<damo22>i made a start but got stuck, its a lot of work

<damo22>ideally i can write glue code so i can just recompile some of the ALSA code as is

<damo22>the card specific hardware structs

<almuhs>yes, it's not the best, but a good start

<damo22>the problem is, linux models audio cards as a "struct device"

<damo22>which has a lot of extra stuff we dont need

<almuhs>yes, linux code is very messy

<damo22>its too abstracte

<damo22>d

<almuhs>you can write a draft with the steps to write the audio support, and publish as TODO meanwhile

<damo22>i could yes

<almuhs>in the hurd wiki

<almuhs>i am busy, learning to write translators in Rust. This week I got to port the "yes", "one" and "caesar", using bindings to call to trivfs. It's very dirty, but it works, so it's a good start

<almuhs>this is my PhD, so I need to continue working in it

<almuhs>the next step would be create a Rust's port of trivfs. Mostly native (only remaining the mach calls and some other necessary), and more idiomatic than the original libtrivfs.

<almuhs>But it will be difficult

<almuhs>i wanted continues my work in SMP, but the PhD topic requires innovation, and the SMP implementation it's not

<almuhs>Rust is trending now, as a language which helps to write safe software, avoiding memory leaks and other memory-related problems. So our idea is create a new library to creates translators in Rust, as a safer library than the original trivfs

<almuhs>But, once I get the new library in Rust, I want to create a more useful translator than the "toy" which i've just port

<almuhs>To show more innovation, and expose the translator's power

<almuhs>Here is my current work. You can read the docs, it's very funny https://gitlab.com/AlmuHS/hurd-translator-in-rust

<azert>sneek: later tell almuhs do you really want to rewrite libtrivfs rather than first attempting at creating a Rust “native-feeling” bindings to it?

<sneek>Okay.

<azert>sneek: later tell almuhs I mean, if it’s for research, why not. Maybe the rewrite ends up being very useful for you

<sneek>Will do.

<almuhs>hi

<sneek>Welcome back almuhs, you have 2 messages!

<sneek>almuhs, azert says: do you really want to rewrite libtrivfs rather than first attempting at creating a Rust “native-feeling” bindings to it?

<sneek>almuhs, azert says: I mean, if it’s for research, why not. Maybe the rewrite ends up being very useful for you

<nikolar>ugh rust

<almuhs>azert: it's not bad idea as next step. Currently i apply binding to trivfs, but it's not a new library based in this binding

<almuhs>my objective is improve the safety. trivfs, due to C limitations, abuse of pointers: passing parameters by pointers, using pointers to functions, using void* to allow any type...

<nikolar>have there been any safety issues there

<almuhs>My main language is C++, and Rust includes similar features, like references, templates, class... maybe virtual methods...

<almuhs>So I want to make use of these features to reduce the pointers using to only the mandatory

<nikolar>so that's a no?

<almuhs>create a layer to trivfs it's a good next step, but ideally it's not the final objective

<almuhs>rewriting all trivfs in Rust could be a titanic effort, but it's possible to reimplement the main functions, grouping in classes

<nikolar>i say it's wasted effort but sure

<almuhs>maybe it could be possible create a new library with a different architecture and coding style, but it's even more difficult, I think

<almuhs>with a different API, i say

<azert>almuhs: I don’t think that reimplementing trivfs is a titanic effort

<azert>I think it’s doable

<nikolar>nor is it worth it

<azert>im worried about the functionality duplication instead

<azert>nice bindings would allow you to write translators in rust and get the improvement in libtrivfs automatically

<azert>what you really want is that people can write translators in rust, right?

<azert>If now it’s ugly with function pointer etc it maybe needs a wrapper of sort

<almuhs>yes, and that these translators doesn't crash as easy than in C

<azert>virtual methods, btw, are de facto function pointers

<nikolar>it's trivial to crash in rust too, just use !

<almuhs>yes, but the dev doesn't need to manage the pointer manually

<nikolar>which everyone does

<azert>exactly, you could implement an rusty object oriented wrapping of trivfs

<azert>that does the pointer stuff for you

<almuhs>yes, i've had many crashes in Rust, but most due to pointers errors

<azert>that way people will have fun writing rust translators

<almuhs>yes, it's a good idea

<almuhs>my idea is, by example, if the original function receive a pointer only for keep the change made in the function, replacing it with a pass by reference

<almuhs>some global variables can be attributes of a class

<azert>Yep

<almuhs>the void* can be replaced by templates

<azert>Also consider that rust can return multiple returns values so often those pass by reference can be replaced by this

<almuhs>yeah

<almuhs>some extern can be virtual, or simply optional attributes of a class

<almuhs>optional, it means that could keep a default value if these are not initialized

<azert>Also core::result and similar types are an intersting concept

<almuhs>yes. I'm learning Rust meanwhile i work in this, so I'm taking notes about the language features

<azert>what book are you using?

<almuhs>the Rust wiki, with the helpful of some Rust developers

<azert>The Rust Programming Language book is nice

<almuhs>i have some friends who programming in Rust since many years ago, and they advice me

<azert>the Rust Linux kernel docs are probably relevant to your experiment

<azert>Great

<almuhs>i take note about this books

<almuhs>i usually program in C++, so the first features which I've learned there are the similar to it

IRC channel logs

2025-09-05.log