IRC channel logs
2026-06-29.log
back to list of logs
<sneek>I've been serving for 13 days <sneek>This system has been up 1 week, 6 days, 21 hours, 11 minutes <damo22>so i think the way the new style structs are handled, if this is called as follows: itStructDecl (min_type_size_in_bytes=16, required_alignment_in_bytes=4) with two int64_t, it resizes the elements to the alignment size so that there is no left over padding that is not a multiple of the alignment <damo22>but another way to do this is to still compute the final value of the struct size with alignment, but dont change the member widths? <damo22>it assumes all members are the same size <damo22>another way to fix this, is to leave mig alone and tweak the user32 code to compute the size of the struct the same way <damo22>how do you force gdb to load a i386 program as a i386:x86-64 arch? <damo22>warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 <damo22>}; ====> Type time_value64_t = struct [4] of (MACH_MSG_TYPE_INTEGER_32, 32) <damo22>type time_value64_2_t = struct[2] of int64_t; ====> Type time_value64_2_t = struct [2] of (MACH_MSG_TYPE_INTEGER_64, 64) <damo22>the new style structs are not working correctly on 32 bit mig <solid_black>to be honest, I do think this is a deficiency in how new-style structs are implemented <sneek>Welcome back solid_black, you have 2 messages! <sneek>solid_black, diegonc says: I can't setup 9pfs successfully. On the GNU/Hurd side I get: <sneek>solid_black, diegonc says: (term 1) demo@debian:~/dev$ 9pfs/9pfs -D -S host-hurd/ 172.19.75.100/hurd <solid_black>consider that Mach IPC can/could be used over the network <solid_black>while the specific C layout of PRC structs, including alsignment and padding between fields, is certainly arch-specific <solid_black>the actual contents of the message, like the list of the Mach IPC level items that it consists of, should be arch-independent <solid_black>so if the same MIG-level struct is represented differently depending on architecture, that sounds like a design deficiency <solid_black>okay, I think sneek didn't deliver all the messages from Diego, but i see the rest in the logs <solid_black>sneek: later tell diegonc: I think the way diod works, if you specify "/home/demo/hurd" as the exported path, you must also use the same path as 'aname' in the protocol, so on the client side, specify the same as well: 172.19.75.100/home/demo/hurd <azert>solid_black: looking at this the other way around, designing an IPC for kernel level and not allowing ways to specify alignment rules and translations between different alignment looks like a deficiency of the original design to me <azert>multi architecture support doesn’t seem to be a very useful feature for the Hurd so far <solid_black>azert: I don't see the deficiency of the orignal design? <solid_black>logically, a Mach message consists of the header, and then a sequence of items (I don't remember if there is a proper term for this) <solid_black>in-memory, the layout of such a message is architecture and ABI-specific <solid_black>to transmit such a message over network, you'd probably use yet another layout / serialization format <solid_black>but logically, it's a sequence of things, such as "MACH_MSG_TYPE_INTEGER_32 with value 1234, then MACH_MSG_TYPE_INTEGER_64 with value 5678, then an array of 256 MACH_MSG_TYPE_INTEGER_32's with values {0, 1, 2, 3, ..., 255}" <solid_black>same as a C struct with a given fields, the fields themselves (their types, order, names) are arch-independent, but who it gets actually laid out in memory is ABI-specific <solid_black>this is all about "typed IPC", there was a branch of Mach (to which XNU Mach belongs) that had "untyped IPC", which was indeed a blob of memory + inline description of the ABI used <azert>solid_black: does gnumach specify the endian-ness of said numbers? <azert>also think about the future. Mach ipc will be used only to setup communication and signaling. All data movement will happens in shared memory through command buffers. That’s out of control of the ipc system <azert>what I meant is that maybe gnumach ipc is trying to do too much <solid_black>no endianness; again the unit is "a 32-bit number", not how it's laid out in memory <solid_black>what is this future where Mach is only used to set up a shared memory area and communication happens there? <solid_black>such a design, in theory, is of course possible, but that's not how Mach systems were designed historically, nor how the Hurd is designed <azert>solid_black: that future is now, just not yet implemented. It’s not up to kernel people to decide these sort of stuff. Hardware manufacturers decide. If and when Hurd will implement graphics drivers it will have to do it that way <azert>multiarchitecture nowadays means cpu to AI accelerator interfaces <azert>most software nowadays work that wat <azert>the GPU ain’t receive Mach messages. <solid_black>we were talking about an issue with how new-style structs are implemented in GNU MIG, I don't see what that has to do with AI accelerators <solid_black>for talking to a GPU, the driver would certianly use a protocol/format specific to that GPU model <azert>because you said that the new style structs break the network transparency of Mach IPC and its multi architecture fancy <azert>that’s ‘80s bleeding edge tech <azert>solid_black: I’m sure the gpu/ai field will go through consolidation of the protocols involved <solid_black>they go against that design principle of Mach IPC at least <solid_black>GPU and AI drivers are expected to be run locally, not over the network <azert>in data centers crazy thing happens <azert>are you aware that part of the tech lead of nvidia is its integration with mellanox? <solid_black>they can't do x86 'in'/'out' IO over the network for staters <azert>gpu do rdma over network without the cpu even knowing thay <azert>it’s the fastest network interface manufacturer <azert>They do in/out of course they use specialized chips to do that <damo22>i assume struct padding matters in mach messages? <damo22>or can it send serialized version <damo22>ok sergeys email makes a bit more sense <damo22>if mig types for a struct are determined exactly by the size of struct members, why does mig change the size of struct members at all? <damo22>surely whatever padding is needed to convert the message back to the struct should be handled in the kernel or at the interface <damo22>it seems mig assumes all members of a struct have the same width and there are "number" of them <damo22>a struct in mig could be a C array of types right? <damo22>eg: struct { int64_t a; int32_t b; } could be modelled by ipc_type structure[2]; <sneek>diegonc, you have 1 message! <sneek>diegonc, solid_black says: I think the way diod works, if you specify "/home/demo/hurd" as the exported path, you must also use the same path as 'aname' in the protocol, so on the client side, specify the same as well: 172.19.75.100/home/demo/hurd <jab>I'm going to try to send in the Qoth for Q2 soon, but man my free time is just disappearing lately! <diegonc>sneek later tell solid_black specifying the full path worked. git doesn't like to run on the mounted fs :( <diegonc>sneek later tell solid_black fatal: unable to get current working directory: Operation not supported <Alicia>does pwd give the same error? that might be a simpler testcase <diegonc>hmm it goes into whatever directory you give it hehe <diegonc>demo@debian:~/dev/host-hurd/git$ cd non-existent <diegonc>demo@debian:~/dev/host-hurd/git/non-existent$ ls <diegonc>demo@debian:~/dev/host-hurd/git/non-existent$ ls .. <diegonc>ls works as if it were standing at git, but pwd includes the inexistant dir <diegonc>intresting, ls notices the directory doesn't exists <diegonc>demo@debian:~/dev/host-hurd/git$ ls libpciaccsss <diegonc>ls: cannot access 'libpciaccsss': No such file or directory <sneek>Welcome back solid_black, you have 3 messages! <sneek>solid_black, diegonc says: specifying the full path worked. git doesn't like to run on the mounted fs :( <sneek>solid_black, diegonc says: fatal: unable to get current working directory: Operation not supported <solid_black>it makes sense that getcwd doesn't work, that is indeed not yet implemented <solid_black>diegonc: could you look at what's actually going on there? <Gooberpatrol66>doesn't mach at the lowest level just send a buffer between processes (through mach_msg) <Gooberpatrol66>so mig isn't actually required, it's just a convention between servers, and servers could use it or not use it <solid_black>Gooberpatrol66: in variants of Mach that use untyped IPC, pretty much, yes <solid_black>in variants of Mach that use typed IPC, a message is not a blob of memory, it consists of elements <rrq>I understood mig to be a tool to implement the interprocss communications layer of your ptogram(s); i.e. not a runtime service (?) <solid_black>there are IPC mechanism level types, those are implemented/enforced by the kernel <solid_black>on top of that, MIG layers its own system of types, which notably has structs and typedefs <solid_black>in particular, please test various combinations of O_CREAT and O_EXCL, in various existing and non-existent directories <Gooberpatrol66>is there an explanation of the kernel level type system somewhere? <solid_black>in diod, use --debug=1 to make it dump 9P, its dumps are actually more readable than those of 9pfs, since it takes care to stringify things <solid_black>assuming various partial lookups now work properly and O_CREAT did not break, should I look into making getcwd work next? <diegonc>if you'd like. I'm running in circles here and can only provide some testing :( <diegonc>what does it mean to have O_CREAT in a dir-lookup? is it something like passing O_CREAT to open()? <diegonc>for now cd behaves correctly, that's good :) <solid_black>diegonc: it's exactly passing O_CREAT to open (or eqivalently calling creat(2)), yes <solid_black>i.e. what your Bash does when you do 'echo test > somefile.txt' <solid_black>please try with and without O_EXCL, also directly at the current directory (as above) and nested at one level (echo test > dir/file.txt) and more levels, with directories existing or not <solid_black>there are various code paths taken, and it all tries to behave in the expected way