<youpi>biblio: thanks for your merge requests! I have uploaded the corresponding packages to unreleased, to be available within 6h at most <biblio>youpi: someone suggested to use OS identified Hurd instead of GNU. So, I added another commit. <damo22>biblio: good to see you working on hurd! <biblio>damo22: i read more about OS dev recently. I will try to check 64 bit port issues soon. <damo22>i am very excited about luckyluke's work on 64 bit, i hope we can get all the moving parts together <damo22>the drivers will soon require acpi if we turn on APIC support <damo22>so its good to have that all ready <damo22>after i rework the routing table, i can finish the acpi translator <damo22>perhaps you can look into how to add the SIOCADDRT ioctl to add actual routes in some equivalent "route" command <damo22>i have a test program that now works <damo22>the only thing missing is the net/route.h header and the ability to print the routing table (WIP) <biblio>damo22: which gcc parameter I need to pass to compile it ? <biblio>damo22: I need to build hurd with these patches to test it right ? <biblio>damo22: do you have any readme or note - that I can apply this patch and build pfinet ? <damo22>you dont need to apply any patch, its merged <biblio>damo22: i think i need to update my packages <youpi>biblio: on a side channel, I have asked the kde debian packaging maintainer whether adding KF_IGNORE_PLATFORM_CHECK would be acceptable for them <damo22>biblio: you need to install the net/route.h header into /usr/include/net/route.h, or just modify the test program to include that one above <damo22>biblio: but you probably need the source to hurd and build pfinet on master <biblio>damo22: I updated but could not find your changes in my /usr/include/net/route.h yet <damo22>biblio: yes, the header is missing from glibc upstream so please use the one i provided above <damo22>you could save the file into "myroute.h" and #include "myroute.h" <damo22>it will compile, but it will fail with some error when you run it <biblio>damo22: now it is compiling. but "Segmentation fault (core dumped" <damo22> ENOTTY = 0x40000019, /* Inappropriate ioctl for device */ <damo22>this is expected because you have not compiled pfinet with the new ioctl <damo22>once you have compiled and installed master pfinet, this will succeed <biblio>damo22: how can I install master pfinet via apt or from source ? <damo22>you should be able to just install from repo <biblio>damo22: i am on v0.9.git20220830 but now dpkg-build package or ./configure ? <damo22>you shouldnt need to build anything <damo22>oh that bug that i fixed yesterday is not in your package <biblio>damo22: no prob. let me know when it is there i will test and let you know. <damo22>ok there is a one liner patch you need to apply to hurd and build pfinet <damo22>youpi: do you think one day we can use savannah's repo directly for debian hurd? <youpi>we'd miss all the automatic work done by bots etc. on salsa <youpi>we can have a mirror there, but for what use? <youpi>mirrors often bring confusion <damo22>why are the two repos different? <youpi>because the tools etC. are different <youpi>it's all the same with all debian packages <youpi>the debian packaging is maintained with debian tools <youpi>even for software that I develop, I put the debian packaging on sals <youpi>so that all the debian tools can run CI, automate corrections, etc. <damo22>i meant having to carry almost zero patches <youpi>that's supposed to be so already <youpi>the problem is that people are lazy <youpi>and don't actually take care of integrating them properly <youpi>see the missing comments in the debian patches <youpi>see e.g. crash-logging.patch <youpi>I have no idea what this is for exactly <youpi>most of the patches are just for debianism, and are not required for getting a hurd to actually work <damo22>but are we still using incubator to generate the upstream tarball? <youpi>since nobody took the time to integrate dde, yes <youpi>basically nobody wants to do the tedious work <youpi>I end up doing it when I have time <damo22>im doing things on hurd that i think are important but theyre all new things <damo22>what do you think is important at this point? <youpi>for me going 64bit is a priority <youpi>because 32bitness is deemed to be abandoned <youpi>and we have the y2k38 deadline <youpi>i.e. large offsets in general <youpi>again, moving properly to 64bit can allow us to just avoid the issue entirely <youpi>and then there are the disk, net, usb, sound, gfx drivers that people will find more important than then hurdish features <youpi>on that side we want to just leverage what's already there through rump & such, and not maintain drivers <youpi>so far ext2 is still working but linuxish features tend to push us <youpi>and journalling would be very welcome <youpi>without a rust port we're doomed to see basic libraries escape us <youpi>libxml2 for instance has not been replaced yet, but that's only to come at some point <youpi>rust as itself can build fine <youpi>the problem is adding to the std lib each and every bit of ABI of the hurd <youpi>they have never automatized fetching that from headers <youpi>i.e. nothing like perl has been doing for decades <damo22>so we need to port the stdlib crate <youpi>yes, a big pile of very tedious work <damo22>but have we completed the hurd ABI? <youpi>the posix ABI is defined, yes <damo22>i did start porting the stdlib crate at some point <youpi>only rust doesn't want to just automatically take it from the C headers <youpi>yes, it'll provide you with bits and bits <youpi>that you'll have to collapse together <youpi>reformat because the output is odd <youpi>check that it's actually correct <youpi>if only they had been automatizing from the start... <youpi>and now they refuse to do it because they say they don't have the manpower to do it <youpi>"and surely anybody who has a new platform to port rust to, have engineers available" <damo22>how complete is the gcc rust language port? <damo22>i dont want to have to curl someaddress | bash <youpi>possibly it'd help with bootstrapping rust/cargo, but I really wouldn't put my hand on fire for that <Zopolis4>its probably going to get merged into gcc13 <youpi>yes but supporting the language only won't give you cargo working <damo22>if someone ports the stdlib, would we upload a rust stage to rust.org or whatever so users can fetch the rust with rustup? <damo22>how would we bootstrap the toolchain? <youpi>rust supports cross-bootstrapping <youpi>it's a bit tedious but I could get that working at some point in not too much time <youpi>then I fell on the stdlib question <damo22>because it has the ABI for every OS built in, it can retarget the toolchain ? <youpi>but they're missing the point that perl has been doing that for decades in an automated way <youpi>by just storing the generated files in the source *youpi gotta sleep, start of uni year tomorrow <slex>hello guys, i experimented a bit with gnumach (mailing list too) <slex>i'd like to build a hobby os on top of gnumach using mlibc, because i think this is a nice and funny approach to learn something, but i'm confused about few things now <slex>When i wrote a server for the hurd that was starting at boot time, i remember i had no printf. can i know the reason? this confused me a bit, is it because the server providing write syscall was not still started? <youpi>the console translator would normally be started from /dev/console <youpi>it happens to be simply using device_open("console") on the master device port <youpi>and use device_write() to output text <youpi>alternatively, you can use the mach_print system call to print stuff <slex>so, however i should not have problem using libc in servers. they runs in user space <youpi>libc assumes that the hurd servers are there <slex>youpi: however thank you, i hope to start really soon, it will be a funny journy. i have a hurs installation running on vbox with both lxde and xfce in a good status. I think i will develop from there :) <damo22>youpi: do i need to define some kind of array type in pfinet.defs or can i use data_t <damo22>its a bit wierd because my struct contains 16 chars followed by 10 ints <damo22>so i dont know how to define the interface <youpi>damo22: you can use several parameters <youpi>just like you did for ADD/DELRT <damo22>so then if there are multiple, they all wrap around? <damo22>ie, each parameter becomes an array? <damo22>i want to have each route coming back as a struct <youpi>I don't remember how that can be set <youpi>or whether it can be set with different types <damo22>i can do it if i just use data_t and use casts <youpi>but probably just using chars will just work <youpi>but possibly you can find an RPC tha tdoes this kind of returning information? <Curiosa>on the topic of alternative OSs running on mach (or other microkernels), in Windows it is possible to create a process with no threads, is it possible to create a task with zero threads in gnumach? <Curiosa>I ask the question since I have the feelings that something went terribly wrong with the invention of preemptive scheduling, and I wonder if there wasn't a reason to make a microkernel based os that would get rid of it <Curiosa>I wonder if anyone share my feelings <Curiosa>AMD is selling a processor with 256 cores and 512 hardware threads. What is the role of preemptive multitasking in such a beast? Surely not the same role it plays on an uniprocessor <youpi>Curiosa: see the info documentation of mach, the task_create function <youpi>« The child task initially contains no threads. » <youpi>Curiosa: it's not clear you really need preemption there indeed <Curiosa>I would think that the best scheduling strategy would be to run the cpu on each thread for as long as they need until they wait for IO <youpi>that depends what your target metric is <Curiosa>What about clients and Hurd servers ? If they need to access lots of shared data it’s better they stay on their own core, if they need mostly to work on client data and the client call them often then being on the client core would be a win <Curiosa>Well, assuming the kernel doesn’t flush caches at each context switch, that would be disastrous probably <Curiosa>What I really had in mind is a really radical design: fixed number of threads, equal to the number of hardware threads. Most tasks don’t have a thread assigned, but thread can be gated from one task to the other passing by the kernel task <Curiosa>Once a thread reach IO it cooperatively goes zombie, and restart after an interrupt <Curiosa>If an interrupt arrives and there are no free cores to run it, then it stops a random one and computation take over in the new thread <Curiosa>Do you see any flags in this design? <Curiosa>I see a few of them, but i think it may work with some exceptions to the rules <luckyluke>Curiosa: what about running untrusted code in a thread? How would you prevent a thread to keep the cpu indefinitely? <biblio>luckyluke: I compiled your "prepare64_wip" but facing same issue. after grub it is rebooting. could you please provide any further info that will help me to test or fix the pending issues. <biblio>luckyluke: Now, I am getting some output after reducing ram to 1 GB. ***valeriusN is now known as valerius
***jpoiret7 is now known as jpoiret