IRC channel logs


back to list of logs

<youpi>biblio: thanks for your merge requests! I have uploaded the corresponding packages to unreleased, to be available within 6h at most
<biblio>youpi: welcome :) glad to hear.
<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: thank you.
<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
<biblio>damo22: yes.
<damo22>after i rework the routing table, i can finish the acpi translator
<biblio>damo22: it would be great.
<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: ok sure.
<biblio>damo22: which gcc parameter I need to pass to compile it ?
<damo22>the net/route.h header is in my commit message here:
<damo22>shouldnt need too many flags ;)
<biblio>damo22: I need to build hurd with these patches to test it right ?
<damo22>you need to build pfinet yes
<biblio>damo22: do you have any readme or note - that I can apply this patch and build pfinet ?
<damo22>but the code is already in hurd
<damo22>you dont need to apply any patch, its merged
<biblio>damo22: I got error
<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
<biblio>youpi: ok sure.
<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"
<biblio>damo22: ok trying
<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>ok so it expects two parameters
<damo22>address and mask
<damo22>read the source!
<biblio>damo22: ok
<biblio>damo22: BAD 1! errno=1073741849
<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>biblio: source
<damo22>biblio: git clone
<biblio>damo22: ok
<biblio>damo22: which branch ?
<damo22>wait there is v0.9.git20220830
<damo22>you should be able to just install from repo
<damo22>a new hurd package
<damo22>what version are you on
<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.
<biblio>damo22: gtg late here.
<damo22>ok there is a one liner patch you need to apply to hurd and build pfinet
<damo22>another time perhaps
<biblio>damo22: ok sure
<damo22>youpi: do you think one day we can use savannah's repo directly for debian hurd?
<youpi>that wouldn't be wise
<damo22>i mean, a mirror
<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>as in upstream all the patches
<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
<damo22>i see
<youpi>so that all the debian tools can run CI, automate corrections, etc.
<damo22>no no, i didnt mean that
<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>throw patches at me
<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>ok thats good at least
<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
<youpi>but that's seldom
<youpi>and it burns
<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
<damo22>ext2 timestamps?
<youpi>time in general
<youpi>also, >32bit i/o
<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>filesystem, as well
<youpi>so far ext2 is still working but linuxish features tend to push us
<youpi>and journalling would be very welcome
<youpi>also... rust
<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
<damo22>isnt gcc writing a rust port
<youpi>a rust language port yes
<youpi>but that's not the problem
<youpi>the std lib is
<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>which is really crazy
<youpi>they have never automatized fetching that from headers
<youpi>they have some tools
<youpi>but nothing integrated
<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
<damo22>using that tool you suggested
<youpi>yes, it'll provide you with bits and bits
<youpi>that you'll have to collapse together
<damo22>i got pretty stuck though
<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"
<youpi>quoted from memory
<damo22>how complete is the gcc rust language port?
<youpi>no idea
<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>the gcc rust port is pretty good
<Zopolis4>its probably going to get merged into gcc13
<Zopolis4>but it dosent compile the stdlib
<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 or whatever so users can fetch the rust with rustup?
<damo22>how would we bootstrap the toolchain?
<youpi>rust supports cross-bootstrapping
<damo22>oh i see
<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
<youpi>and just gave up
<damo22>because it has the ABI for every OS built in, it can retarget the toolchain ?
<youpi>that's their point
<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
<damo22>array[56] of char?
<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
<damo22>so an array of structs
<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?
<damo22>i am looking
<damo22> out data: data_t, dealloc[];
<youpi>right :)
<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>I guess no one
<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: another question for mig - should I use "--host=i686-unknown-linux-gnu" as mentioned
<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