IRC channel logs

<damo22>youpi: why doesnt netdde release the irq when ifdown is called?

<damo22>it seems to stay open

<damo22>ddekit_irq_detach does not get called it seems

<damo22>hmm yes it does

<damo22>ddekit_interrupt_detach does not seem to release the irq

<damo22>what is the correct way to unregister a user interrupt handler?

<youpi>closing the port should be enough

<youpi>so that if the process gets killed, the unregister does happen

<damo22>mach_port_deallocate?

<youpi>or destroy

<damo22>hmm ok

<damo22>im also setting it to MACH_PORT_NULL after

<youpi>the kernel won't care about that :)

<damo22>whats the difference between mach_port_deallocate and mach_port_destroy?

<damo22>libdde-linux26 saves a lot of headers btw

<damo22>s/saves/installs

<damo22>maybe we can flush them out eventually

<damo22>does netdde need to support more than one interrupt handler?

<damo22>ive naively stored the irqhelp pointer as a single global

<youpi>see the documentation: deallocation just drops a ref and destroys if there are not refs left, while destroy just destroys immediately

<youpi>deallocate is usually prefered

<youpi>netdde may have to drive several network boards

<damo22>ok

<damo22>i need to get it working with one first

<damo22>im getting closer

<damo22>is there any way to suppress the -prof packages of debian hurd?

<damo22>it takes a long time to build the entire package set

<damo22>i keep the tree around and use -nc

<damo22>we really need SMP

<damo22>youpi1: the only identifier that is passed into ddekit_interrupt_attach is the IRQ number, how do you release the correct device if more than one is sharing that IRQ?

<VedantT>To the rust repo do we add a new rustc target for hurd i686 and x86_64?

<damo22>VedantT: hi! i believe that is the easy part, we need to port the stdlib crate

<VedantT>where would I find the stdlib crate? the libc crate has it's specific port but I cannot find one for libstd (is it why it is was redirected to the alloc)?

<damo22>ahh i cant recall the exact name of the crate

<damo22>possibly its called libstd

<VedantT>is there a specific repo I should navigate to?

<VedantT>I just wanted to confirm the hurd target should be added here?

<VedantT> https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec

<damo22> https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#stages-and-std

<VedantT>Wouldn't the specific target need to be added to the rust source code to specify hurd? Since we cannot assume unknown targets?

<damo22>VedantT: i think you can cross compile from linux to hurd if the libstd crate is ported to hurd

<damo22>a small definition would probably be required for the target yes

<damo22>i can share my work, i think i did the rust port for the rustc

<damo22>i tried to do rust-libc

<damo22>but failed

<damo22>i think its this https://github.com/rust-lang/libc.git

<VedantT>I think the crate is either here:

<VedantT> https://github.com/rust-lang/libc/tree/main/src

<VedantT>OR

<VedantT> https://github.com/rust-lang/rust/tree/master/library/std/src/os

<damo22>VedantT: i think it can use the unix family

<damo22>see this patch that i wrote in 2021:

<damo22>VedantT: https://paste.debian.net/plain/1285296

<damo22>then you need to configure the build to use a custom path to libc

<damo22>instead of pulling the libc crate, you want it to use your own source tre

<damo22>man that guy disappears fast

<VedantT>thank you

<damo22>(18:41:42) damo22: then you need to configure the build to use a custom path to libc

<damo22>(18:42:09) damo22: instead of pulling the libc crate, you want it to use your own source tre

<VedantT>Would it be possible to see the branch for lib c that you worked on?

<damo22>its ugly, i used a code generator

<damo22>i think you can try rust-bindgen on the hurd system headers

<damo22>thats all i did

<VedantT>So my local tree should contain:

<VedantT>modification of system call wrappers

<VedantT>adapting header files

<VedantT>adding and adjusting dependencies

<VedantT>adding OS specific functionality

<VedantT>Here is the directory tree for src in libc:

<VedantT>src

<VedantT>-- fuchsia

<VedantT>-- hermit

<VedantT>-- solid

<VedantT>-- unix

<VedantT>-- vxworks

<VedantT>-- windows

<VedantT>I was wondering if all the subdirectories should be modifed accordingly. Then I can modify the build.rs

<damo22>VedantT: the hurd is a unix compatible os

<damo22>its posix

<VedantT>I see

<damo22>you dont need to touch files not in "unix" most likely

<damo22>the libc crate supports all these os

<damo22>something like this almost works with my patch $ ./x.py build --target x86_64-unknown-linux-gnu --target i686-unknown-hurd-gnu

<damo22>i think it gets stuck on the libc crate

<damo22>VedantT: you need these three lines to add to src/unix/mod.rs:

<damo22>+ } else if #[cfg(target_os = "hurd")] {

<damo22>+ mod hurd;

<damo22>+ pub use self::hurd::*;

<damo22>and then generate src/unix/hurd/mod.rs

<damo22>the last part is the difficult bit

<damo22> Compiling libc v0.2.88 (/zam/damien/git/rust-libc)

<damo22>lol i dont remember this working before

<VedantT>which lines are these at exactly?

<damo22>my patch was applied at hash 25ea6be13e3

<damo22>for rustc

<VedantT>this is libc right?

<damo22>for libc it was fc51a0f32 (tag: 0.2.88

<VedantT>ok

<damo22>if you want to target a later version you will need to figure it out

<damo22>ok so i just finished compiling stage0 and its doing stage1 now

<damo22>Building stage1 std artifacts (x86_64-unknown-linux-gnu -> i686-unknown-hurd-gnu)

<damo22>it threw a lot of errors

<VedantT>nice

<damo22> Compiling std v0.0.0 (/zam/damien/git/rust/library/std)

<damo22> Compiling rustc-std-workspace-core v1.99.0 (/zam/damien/git/rust/library/rustc-std-workspace-core)

<damo22>error: unexpected closing delimiter: `]`

<damo22> --> /zam/damien/git/rust-libc/src/unix/hurd/mod.rs:8663:31

<damo22>its a huge file, autogenerated from bindgen and has syntax errors

<VedantT>are there any effective fixes? or is it a manual override

<damo22>it would be ideal if a tool like bindgen could generate the exact file we need, im not sure if that is possible

<damo22>i can share the command i used to generate the mod.rs

<damo22>maybe you can see which headers need to be included/excluded and try to generate your own

<damo22>bindgen input.h -- --sysroot=./hurd-headers -I./hurd-headers/include -I./hurd-headers/include/i386-gnu -target i386-gnu > mod.rs

<damo22>where input.h is a file containing #include <blah.h> all the system headers and hurd-headers is a folder containing src/include

<damo22>from all the actual headers of hurd

<damo22>im not sure if that is what youre supposed to do but you can compare to other mod.rs for other OS

<damo22>that should get you started

<VedantT>just one clarification we never really create a subdirectory for hurd within unix (such as for bsd) containing its own mod.rs, lib.rs?

<damo22>i think i did

<VedantT>I see so the changes were on a local branch

<damo22>yes

<VedantT>this is the version I should be comparing too for libc?

<VedantT> https://github.com/rust-lang/libc/tree/fc51a0f327ba148ffc1e6a11b7448f649b80608a

<damo22>no no, thats if you want to replicate what i did

<damo22>i mean, the first step is to get something like the patch i gave you working on latest release of rustc i imagine

<damo22>and set up your configuration so it points to something like ../rust-libc for libc

<damo22>to a local clone of the libc git repo

<damo22>then even without changes you can try compiling the toolchain and it will certainly fail on libc

<damo22>cross compiling to i686-unknown-hurd-gnu

<damo22>then you will be in a stage ready to experiment with the libc and figure out which headers need to be included and try converting them all to rust with bindgen

<VedantT>oh I see, although I noticed none of the targets specified for hurd, in the build were pushed to master are they existing on a local tree such as this?

<damo22>there is no hurd support at all

<damo22>the patch i posted makes x.py work

<damo22>but on an old rustc

<damo22>you need to use the ideas from my patch and port that to latest release of rustc

<VedantT>I am following the same steps above except bindgen might not autogenerate the exact file which is also an issue

<damo22>if it was that easy, we would have done it already :D

<damo22>but maybe you will get lucky with new headers

<damo22>and new bindgen

<VedantT>I see thanks for the clarification and help!

<damo22>feel free to ask lots of questions

<damo22>ive given you everything i have

<VedantT>Is UTC +10 14.30 to 18.30 a good time period to communicate?

<damo22>i am in Australia so yes

<VedantT>ok

<damo22>but i am not the official mentor for this project

<damo22>i am just helping

<damo22>i would love to have rust support

<damo22>youpi: i hope you dont mind me helping VedantT, i just want to see rust working :D

<youpi>you're welcome!

<youpi>damo22: concerning prof packages, you can pass -Ppkg.hurd.noprof to dpkg-buildpackage

<damo22>thanks!

<youpi>so you can use -Pnoudeb,pkg.hurd.noprof

<damo22>perfect

<youpi>« how do you release the correct device », you can have one port per irq notification request

<youpi>so you just release the port

<youpi>several drivers can have one port each, even if it's the same irq

<damo22>yes but that doesnt solve the problem of deciding which port to release, if you only know the irq

<damo22>since the same irq can be shared among multiple devices

<damo22>irq -> which mach port?

<youpi>the irq helper library should rather return a port

<youpi>and it'd be up to the user of the library to know the correspondance

<youpi>and use reference counting to determine when to actually release the port

<damo22>the irqhelp opaque pointer is unique, that could be used

<damo22>but the problem is still in the ddekit

<youpi>it looks like dde's release_irq already does the reference counting

<youpi>so in that case you can just use an array to store the ports for each irq that was set up

<youpi>since it won't call ddekit_interrupt_attach several times for the same irq

<damo22>i dont understand why reference counting helps, is it that you only kill the port when all devices sharing the same irq complete?

<youpi>in the end, yes

<youpi>see release_irq

<youpi>it calls detach only when there's no action any more

<damo22>but that makes no sense, different devices can get interrupts on the same irq

<youpi>so what?

<youpi>dde makes the various calls to the various drivers

<youpi>and registers the irq when there is at least one driver, simply

<damo22>so you would kill none of the handlers until they all stop using the irq?

<youpi>what do you mean by "handlers" here?

<youpi>you'd unregister from gnumach only when all drivers have unregistered their action

<youpi>the if (!irq->action) case in release_irq

<damo22>ok

<damo22>i see

<damo22>its per irq

<damo22>is MAX_IRQS 32 a good default?

<damo22>iirc an APIC has 24 so 32 should be enough

<damo22>are you sure, i think ddekit_interrupt_attach gets called every time a device registers an interrupt, regardless whether its an irq that was used before

<youpi>see claim_irq and its if (!rq)

<damo22>- /* We cannot attach the interrupt to the irq which has been used. */

<damo22>- if (ddekit_irq_ctrl[irq].irq_thread)

<damo22>- return NULL;

<youpi>+i

<damo22>thanks, i think i understand better

<damo22>irqhelp is working!

<damo22>i am rsyncing rust into the vm

<damo22>ifup and ifdown work pretty well

<youpi>\o/

<janneke>yay!

<damo22>i meant my rust source tree, not a working rust for hurd :|

<damo22>actually, how does VedantT work out which system headers are required?

<youpi>we'll see what libstd wants

<damo22>somehow i have a input.h file with a set of curated headers

<damo22>i cant remember where i got the list from

<youpi>also, I don't think we want to just take everything, b ut rather just copy/paste what's actually needed

<damo22>sent 10,932,485,258 bytes received 3,563,749 bytes 1,473,960.38 bytes/sec

<damo22>total size is 11,194,873,873 speedup is 1.02

<damo22>i will send patches for irqhelp

<damo22>and ddekit

<damo22>it would be nice if a tool like bindgen could take a set of headers and output exactly just what is needed

<damo22>i used it last time in 2021 and it generated 600kB of rust

<youpi>like perl has been doing for decades, yes...

<damo22>i think i may have fed too many headers in

<damo22> https://paste.debian.net/plain/1285314

<youpi>that's a lot indeed

<youpi>our first target is only to run rustc & cargo

<youpi>that probbaly needs way less than that

<youpi>and we can add whatever is needed for more crates later

<damo22>i cant remember how i got that list

<janneke>is there any reason to have/build netdde.static that you know?

<youpi>debugging from gnumach's kdb is easier

<youpi>also, booting off nfs

<janneke>thanks!

<damo22> https://docs.rs/bindgen/0.47.1/bindgen/struct.Builder.html <--- apparently you can write a rust program that runs bindgen on some headers and can filter for some things

<damo22>ie we may be able to automate the porting of the headers in rust

<damo22>so if we update hurd headers we can regen the libc

<damo22>i am trying without any headers

<damo22>just using an empty mod.rs

<damo22>it still includes a bunch of standard unix stuff

IRC channel logs

2023-07-08.log