IRC channel logs


back to list of 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
<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>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>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>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
<VedantT>I think the crate is either here:
<damo22>VedantT: i think it can use the unix family
<damo22>see this patch that i wrote in 2021:
<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>-- 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
<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 $ ./ 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/
<damo22>+ } else if #[cfg(target_os = "hurd")] {
<damo22>+ mod hurd;
<damo22>+ pub use self::hurd::*;
<damo22>and then generate src/unix/hurd/
<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
<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
<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/
<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
<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 >
<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 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,
<damo22>i think i did
<VedantT>I see so the changes were on a local branch
<VedantT>this is the version I should be comparing too for libc?
<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 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
<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
<youpi>so you can use -Pnoudeb,pkg.hurd.noprof
<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>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;
<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
<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
<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
<damo22> <--- 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
<damo22>it still includes a bunch of standard unix stuff