IRC channel logs

<gnu_srs1>Pellescours: From youpi about porting valgrind to Hurd: It is indeed very far from a trivial task. I'd rather recommend to port

<gnu_srs1>gcc's lsan support, it will be most probably much easier to port. (see bug-hurd ML)

<damo22>youpi: did you receive my slides? just want to make sure you got my email, as i must upload the video by 15th Jan

<drakonis>hurd on fosdem?

<damo22>yeah

<Pellescours>gnu_srs1: thanks, yeah, I know that valgrind is not available yet nor easy task to do, that's why a was asking for gcc's san

<damo22>biblio: can you resend as a proper patch with your preferred name and email? You can configure git and then use git format-patch to generate it. What you gave me was just a diff, so i dont know how to commit that correctly

<biblio>damo22: ok sure.

<biblio>damo22: i will send as you suggested. note: we will need to implement "install interrupt handler for acpi".

<biblio>damo22: meanwhile you can test using $ git apply filename.patch

<youpi>damo22: yes I got them

<damo22> https://youtu.be/hIXhnWUmMvw shoshana zuboff is incredible, do any of you know of her?

<slex>yes but this assumes that i have ld.so, it's ok i understood another piece, but i have to go still back, i must be able to run the hello_custom, in a situation when i have the bootloader the kernel and the hello_custo just that

<slex>so is good that i understood how to use /lib/ld.s.1 and capable to run my server, Iḿ more near to the goal

<youpi>link your program statically

<youpi>with -static

<slex>yes

<youpi>just like ext2fs.static

<slex>i'm rebooting the vm

<slex>finally it works also if i run from grub only my server and not ext2fs or other modules yuppie!

<curiosa>slex: great news, congrats! What is it going to be your next step?

<slex>I need a nameserver that is able to register other servers, like ext2fs does, so i client can ask to the nameserver the ports and the righst and then be able to establish a communication channel with the server to send and receive messages

<curiosa>Sounds like a plan!

<slex>s/i/a

<slex>yes is a good plan to learn stuffs :)

<slex>the same i made with my kernel, i had no chance to understand gnumach kernel code if i would never wrote my little own kernel

<curiosa>Yep

<curiosa>Also, who knows: maybe if you succeed you’ll be the first one to run something on gnumach 64bit

<slex>however my little kernel is mono, but i'ma micro fanatic

<slex>actually gnumach can run 64bit

<curiosa>What is the name of your kernel?

<slex>not the mig, if u want useland processes running 64bit u have to send messages withiut using mig i think

<slex>uros

<slex>nothing of special there is also an initial gfat16 implementation

<slex>fat*

<slex>and vfs

<slex>but remember it is monolithic, i want micro, noway to write a new microkernel, gnumach exists and works

<slex>people will say that mach had bad performances

<curiosa>Well I think it’s hardly the case

<slex>it's true, bad actually there is no microkernels really suitable for general purpose usage

<curiosa>Depends what you use it for

<slex>(i spent ours on seL4)

<slex>on l4 micros u need to implement a pager per progess, that's annoying

<slex>process*

<curiosa>Mach is good enough for many things maybe the Hurd that uses it for file io is overkill, I don’t know

<slex>I'm not so skilled in the Hurd internals to say things

<curiosa>Me neither

<slex>If it does heacy usage of the filesystem, this means that A LOT of ipc must be sent to it

<slex>yes

<slex>heavy*

<slex>for example when u attach a translator to the filesystem a file is needed, but I don't really know how Hurd interacts with that file, the only thing I know is that if you want send a message to that translator, a call similar to hurd_filename_resolver(probably it doesn't have this name) is called to solve the path get the name of the file and that one is the name of the transaltor registered to the filesystem, from there you can get the

<slex>port and sending messages

<youpi>see the open path on the wiki

<youpi>or my video about it

<youpi>it's the open() function which ends up calling the lookup functions

<slex>but is that the concept?

<youpi>which just send a message to the filesystem server

<slex>ok

<slex>where at least i was near on how it works :P

<slex>well*

<slex>I think

<curiosa>You end up with a port right on the file system server

<curiosa>That is your file

<curiosa>Now read and write call are msg on that port

<slex>on hurd and gnumach all posix syscalls should be messages :)

<curiosa>That seem not that slow, at least for desktop kind of workloads

<curiosa>How often you really do file io?

<slex>the system can do it in background

<slex>and in a unix system where everything is a file...

<slex>however if i can say this with some more expert than me

<slex>mach could be not the faster microkernel

<curiosa>Yea I’m sure I’m not more expert then you

<slex>a lot of thhings can be imnproved both in mach and in hurd

<slex>also a new ipc could be impemented,beside the old one, then use the new, on new servers

<slex>but bedore that you should test on real hardware if the ipc is the real problem

<curiosa>Exactly: one need to really work on the bottlenecks

<slex>or if there are other areas that can be improved giving more than the ipc

<curiosa>I don’t know, but my intuition is that the way the filesystem server interacts with the hw might be more important than the way it interacts with users

<curiosa>Given that hw protocols evolve fast, I’m surprised that Hurd want to keep stable apis on that side dating from the early ‘90

<slex>well, in operating system course at university they teach you that, in all kernels and PCs, the disk is the bottleneck, becasue the mechanical one, is the slowest component on the machine

<curiosa>They also teach you that Linux does not have a stable internal api because it works better that way

<slex>well also ssd are slower than ram so...

<slex>i never looked at linux api, i just don't like monolithic kernel, itś like i totall yhave no interst but i MUST use them...

<slex>ubnfortunatly

<slex>with the last release apple will obbligqate third party driver developers to write drivers in userspace using mach ipc

<curiosa>That’s a funny thing XD

<curiosa>If you give a check at their Mach msg they extended the zoology quite a bit with many different trailers

<curiosa>I think that damo22 is working on user space drivers over here

<curiosa>And I’m sure he will come out with neater solutions

<slex>never looked at it. and I don't know it their mach ipc work like all the other Machs ipc

<slex>or if they totall ychanged it

<slex>(but knowing apple, is probably the smae)

<curiosa>Yep they didn’t change that much but extended quite a lot

<slex>ahah

<slex>however the test on the ipc performance on mach were made in early 90 on 50 Mhz CPUs, that's why it should be retested now

<slex>I like the blogs comparing mach ipc with l4 ipc...

<slex>nice idea taking 90's test compared with 2018 tests

<slex>but on totally differents kernels

<youpi>ipc microbenchmark is a thing, but one has to benchmark actual workloads

<youpi>and yes, the cost of ipcs have decreased a lot with newer processors

<slex>what could be a heavy workloads?

<youpi>linux has a *stable* api

<youpi>in terms of system call

<youpi>it's the internal api which isn't

<youpi>I don't think we really have "bottlenecks" left in GNU/Hurd

<youpi>what we miss, as documented on the wiki, is algorithmic optimization

<youpi>notably readahead

<youpi>workload: building a program, typically

<youpi>or installing packages

<youpi>etc.

<slex>ah ok

<youpi>as in: what actually costs us time when working with a computer

<youpi>that's what matters

<slex>running fibonacci of 100 and for ehach call it also writes to a file the result? can be?

<youpi>I don't care if my login prompt shows up in 10ms or in 10µs

<youpi>better just run an actual workload

<slex>i forgot to add 10k times fibonacci of 100 with the toer stuff, but ok

<slex>i understood

<slex>i like the hurd, there is only one thing that confuses me, but those are just thoughts of a noob

<biblio>damo22: I sent patch to you using git format-patch for testing libacpica PCI link impl.

IRC channel logs

2022-01-08.log