IRC channel logs

<gnu_srs1>Yay! hurd-cross.img boots fine. And even nano works. Time to fix copyright/licenses to all files, commit to git and create a tarfile for upload.

<p2plife>is gnu hurd expexcted to work "normally" on bare metal in current year?

<youpi>depends which hardware you have

<youpi>cpu shouldn't be a problem

<youpi>disk neither, provided you have it in ahci mode

<youpi>or ide mode

<youpi>network, however, is still using old linux drivers

<youpi>see the faq entry about it

<p2plife>and graphical mode?

<youpi>it's simply Xorg

<damo22>vesa driver is supported

<p2plife>and the drivers to intel, nvidia, radeon/amd cards?

<p2plife>linux supports most card not by vesa, but by... DRM?

<p2plife>(except propertiarly blobs drivers)

<youpi>drm is inside linux :)

<p2plife>so that code that handle a gfx in DRM is in linux, and it shoul be ported to totally new API (microkernel), but that work is not done (yet)?

<youpi>yes

<p2plife>is that usually rewritting driver from scratch, just reusing the known details of hardware api (port numbers or whatever)?

<youpi>usually we just pick up drivers

<p2plife>or more like just wrap the code into the new HURD api to like, allocate memory, pass data to IO ports?

<damo22>i fear rump is going to end up a dead end because both its author and netbsd are not maintaining it

<youpi>:/

<p2plife>who's rump?

<youpi>well at least the netbsd codebase is simpler to manage than the linux codebase that was used in dde

<p2plife>rump, as the one of 1000 solutions to the audio subsystems in unixes?

<p2plife>The NetBSD rump kernel is the first implementation of the "anykernel" concept where drivers either can be compiled into or run in the monolithic kernel or in user space on top of a light-weight kernel.[1][2][3][4] The NetBSD drivers can be used on top of the rump kernel on a wide range of POSIX operating systems, such as the Hurd,[5] Linux, NetBSD, DragonFly BSD, Solaris kernels and even Cygwin

<p2plife>that's pretty cool I guess

<damo22>there was a recent project (not dde) that implemented a userspace target for linux

<damo22>drivers*

<youpi>linux is too fast-moving of a codebase to consider long-term maintenance, I believe

<p2plife>damo22, so what that means?

<damo22>yeah, but if we freeze the drivers at something like linux version 6.0 that would still be pretty nice

<youpi>and we'd be stuck there

<youpi>just like we have been with 2.0, then 2.4 drivers

<damo22>i see, but netbsd doesnt have many drivers

<youpi>but there are people writing some

<youpi>that's still better than being stuck

<youpi>of course we can try to leverage both

<damo22>for example, ALSA has a lot of free drivers for sound cards that no one will be able to implement fast enough in bsd

<damo22>even though ALSA has flaws, the low level support is there

<damo22>a lot of the modules are written quite well, as structs of function pointers

<damo22>i am tempted to write a microalsa for hurd

<youpi>but is it a moving kernel API ? netdev, notably, is a very moving API

<damo22>expose a JACK server api instead

<damo22>ALSA api has too much cruft like both pull/push models

<p2plife>maybe at least hurd can have a recommended hardware or few models, and make sure these work?

<p2plife>in general, for the problem of getting dirvers into hurd and updating them

<damo22>p2plife: currently there is an opportunity to introduce audio subsystem from nothing, for example, i want to do it better than linux not just copy them

<damo22>linux has to be backward compatible with everything

<damo22>even OSSv32

<damo22>v3*

<p2plife>damo22, I guess cool idea. but isn't that tons of work to rewrite drivers for hurd, do you have the time?

<damo22>the drivers themselves are already written in structs of function pointers, i think we just need to implement a ringbuffer of some kind that allows user to write and read to it

<damo22>it would be a gplv2-only translator to provide an ALSA-based audio subsystem

<damo22>since some code would be copied from ALSA

<damo22>but the api exposed to userspace could be simplified

<p2plife>how userspace (programs) use it? would someone need to patch things like SDL, X, etc to use that API? what is programs that now call ALSA, or PA directly, I think firefox, audacity etc?

<damo22>users could open the JACK server with desired latency and get a callback to implement the processing for samples,

<damo22>it would be a JACK compatible api

<youpi>also write a pipewire backend, and that'll do for most applications

<damo22>ok

<damo22>yeah it could be pipewire instead

<damo22>since that provides JACK

<p2plife>so audacity uses PulseAudio hardware, it talks to pipewire daemon that exposes PA api, then pipewire talks to JACK api of your new sound daemon and it talks to hardware by wrapping various drivers imports from linux and such?

<p2plife>*so audacity uses PulseAudio API

<damo22>no, audacity could use jack backend, talks to pipewire and direct to hw

<damo22>ACTION wonders if pipewire can be a jack client?

<gnu_srs1>damo22: Are you finished with rump disk drivers and SMP yet?

<damo22>no i got stuck with SMP last November.

<damo22>rump needs bsd people to be involved i think to fix DMA and makefiles

<youpi>rumpdisk seems to be working quite nicely on my box, now that wiring is fixed

<gnu_srs1>damo22: Maybe it would be wise to concentrate on rump, SMP (you) and 64bit (flavio) for now?

<gnu_srs1>And leave ALSa for later.

<damo22>we're all doing what we can

<gnu_srs1>Anybody interested? (00:15:33) gnu_srs1: Yay! hurd-cross.img boots fine. And even nano works. Time to fix copyright/licenses to all files, commit to git and create a tarfile for upload.

<damo22>youpi: "wiring" ?

<gnu_srs1>Yes, I know flavio has cross-hurd, but hurd-cross can be a complement.

<gnu_srs1>When I'm happy enough with hurd-cross (hurdX) I'll continue with cross-compiling libphobos and libasan.

<damo22>gnu_srs1: why dont you try your hand at SMP?

<damo22>i got burnt out

<gnu_srs1>damo22: SMP seems to be a little over my head, unfortunately.

<damo22>i didnt know what i was doing much either until i read the source and some x86 manual pages

<p2plife>threading sure is hard

<youpi>damo22: yes, prevent swapping the pages of rumpdisk

<damo22>ah ok

<damo22>p2plife: threading isnt really the issue, its configuring/setting up all the processors to start up

<Guest7551>damo22: do you know what happened of Antti?

IRC channel logs

2023-01-04.log