IRC channel logs
2026-07-01.log
back to list of logs
<damo22>youpi: regarding the struct[2] of int64_t, i did check the CI passes on 32b. It must be working by chance currently without breaking 32b <damo22>there must be no padding and the total size is the same <damo22>the two struct members are definitely 64 bit wide, so if mig is currently passing them as 4 int32s its a bug <damo22>the reason it doesnt throw an assert currently on pure 32b is because msg_usize is computed differently on USER32 vs pure 32b <jean-christophe>may be you need to use a define for nunber of bits a scale with processor use <damo22>jean-christophe: sorry i dont understand what you are asking. The topic has official links <jean-christophe>but you think about int64_t if it in define you can have an int128_t no ? <jean-christophe>jean-christophe@git.savannah.gnu.org: Permission denied (publickey). <jean-christophe>fatal: repository 'https.git.savannah.gnu.org/git/hurd/gnumach.git/' does not exist <damo22>it probably created a bogus symlink <damo22>read the source code, its much shorter than linux <jean-christophe>normaly it's easy to create with a cli tool from source, but i don't know this tool <jean-christophe>if you suggest tool... on approximate tool as modifier, to have an diagram of code... <jean-christophe>i'm visual, just read the the code don't give an idear how that was work <damo22>you cannot describe an entire kernel in one diagram <damo22>the devil is in the detail, its all in the sourc <damo22>for porting a new arch, you need a folder with the name of your architecture, with contents something like what is inside x86_64 <damo22>or have a look at aarch64 for arm port <damo22>in general, mach does very little, it provides virtual memory and IPC <jean-christophe>i think in 3D or 2D, in graphique, no only with just read a code a create diagram in my mind <damo22>but there are some arch specific code in gnumach to make it work on a new platform <damo22>i dont have any diagrams, you might find some on the wiki <azert>I don’t understand damo22 solution for the 4x32 vs 2x64 issue for user32. This should of course break i386 but he claim it doesn’t <solid_black>I think he's testing a completely rebuilt i386 system <solid_black>while Samuel is talking about the case where one of the kernel and userland is updated, but not the other one <azert>a good option is to obsolete that rpc and make a new onr <azert>hopefully it is just that one <azert>in retrospect we should have probably never accepted new-style structs, and we should probably slowly migrate to untyped ipc <solid_black>nor does it sound like something that could be done slowly <azert>untyped ipc because it’s more simple and doesn’t try to solve issues that doesn’t exist <azert>you could do slowly by supporting both for some time <solid_black>and trying to support both is sure to introduce a whole bunch of complexity <azert>I don’t mean that they should inter operate <azert>then move typed ipc to user space <azert>sure. If what you move is just serialized data in a blob, things like what happened now would never happen <solid_black>but it's not just a blob, you have to parse that blob somehow <azert>Well what you just sent is not amazing indeed <solid_black>to make an i386-task produced blob make sense to an x86_64 kernel, untyped MIG uses NDR <azert>ok I agree it is more or less the same we already have <azert>but can we really fix new-style structs? I don’t think so <azert>we probably can deprecate the feature <solid_black>it would make sense for new-style structs to produce an array of the largest field type (assuming fields are themselves integers or other structs) <azert>and in any case, why do we need them? <solid_black>we didn't strictly need them, and classic Mach didn't have them, it's our invention <azert>of course it would have been cool to have a C based idl <azert>It’s a recent introducing, most of it can be reverted preserving abi I’m confident about that <azert>eventually youpi will decide what to do <azert>I think that a possible solution is that Flavio fix new-style structs and then we just fix up and deprecate the few rpcs that break <azert>it’s kind of equivalent to just deprecate new style structs and then fix up and deprecate what breaks <solid_black>we should have two distinct access control modes in 9pfs <solid_black>one is doing access control locally, on the GNU/Hurd system / inside 9pfs, in this case we can just connect to the remote server as some fixed user name/uid, no matter which uid accesses us lcoally <solid_black>the other one is passing all user names / uids over to the remote server, so the server is expected to do access control <solid_black>the latter makes sense if you're in some set up where the users on the local gnu/hurd system correspond to those on the remote server <solid_black>like perhaps some corporate environment with single sign-on, or something <solid_black>but the former one also makes a lot of sense: for me use-case here, I don't want authenticating as root here on the hurd system to try to reattach as root to the server <solid_black>Linux v9fs has access=user (my latter variant) and access=any (my former variant) <solid_black>side note: we should have a version of dir_mkdir that returns a port to the new directory <azert>solid_black: i think nowadays corporate environments moved away from old Unix user sharing <azert>we should check what systemd is doing in that regards <azert>otherwise the former variant is the one that makes more sense <solid_black>when I was a student, the uni had a single fs server that everyone's home directory was located on, and then you could log into any terminal as your user, and get your home directory mounted over the network <azert>me too, we implemented an ldap database and shared homes over nfs <solid_black>I imagine you could set up such a system with terminals running GNU/Hurd with 9pfs, and a server running whatever <solid_black>the server could be somewhat dumb and really use remote user names / uids directly as-is, if the admins set it all up so that they always match <solid_black>or the server could do some smarter mapping on its side <azert>it probably already works on the Hurd through pam ? <solid_black>you'd use something like sssd to let you log in as a domain user, and it synthesizes a unix username/uid for you <solid_black>and there could be multiple users on the same machine accessing the same 9pfs mount (e.g. /home) at the same time <azert>I wonder how much of that already works on the hurd <solid_black>so again, for a setup like this you'd ask 9pfs to forward user info to the server and let the server deal with access control <jean-christophe>witch the best way to code for hurd ? as a fork on hurd in gitlab, or witch way ? <jean-christophe>i have git clone, but can't see the diagram of mach... may be in first write a python code for create an uml diagram from code... any suggestion ? libs ? <hwpplayer1>is there a book/article/ that tells microkernel architecture with gnu philosophy <sam_>get started on that first perhaps <azert>very surprised that git requires mmap <azert>didn’t Linus Torvalds write it? <azert>afaik not all fs support mmap even on Linux <gnucode>so, I am working on tidying up the qoth q2 for this year! <jean-christophe>stalmane was say contribute to the big project, is the best way to become an hacker <gnucode>jean-christophe: what's your gnumach wiki ? <azul_>jean-christophe, will you tend to follow exactly the gnumach x86 design or will you try to diverge and/or improve it? <azul_>and do you wrote the project timeline today <azert>sneek later tell solid_black I remember following Brent Baccala work on a libpager on steroids <gnucode>grrr, magit is still not working on the Hurd.