IRC channel logs
2025-06-29.log
back to list of logs
<youpi>sneek: later tell azert not directly, you'll really need to translate RPCs to rump calls <damo22>i thought i could create a trivfs and just implement trivfs_S_io_read etc <damo22>but i cant seem to get a mach port to the rumpfs <damo22>what is the mach port an instance of? <damo22>ie what do i actually need to implement? <damo22>cant i just implement a filesystem node somehow <damo22>could i implement it as a netfs with one node? <damo22>can i store the rump fd in cred->hook and then read from that <damo22>or hardcode the filename to /dev/ugen and lookup dotdot -> ugen <damo22>null translator does not define getroot <damo22>but still implements reading and writing <damo22>i think i need to implement a new RPC on top of a trivfs that allows calling rump_sys_ioctl() on a server side fd <damo22>ugenhc has a rumpcomp_ugenhc_ioctl hook <damo22>so, in theory the stack is separable <youpi>damo22: you can store whatever you want in hook, yes, so the rump fd for instance yes <youpi>so in open_hook you can rump_open, and store the fd <youpi>and on io_read, get the fd and call rump_read <damo22>unfortunately, rump ugen requires ioctl <youpi>damo22: various trivfs translators do support ioctls <youpi>you just need to run an ioctl server <damo22>but i dont want to define them all, just pass to rump_sys_ioctl <damo22>i have a patch for rump to enable ugen, just testing now <damo22>somehow they overlooked enabling the /dev/ugen node <damo22>they were probably not expecting someone to use rump to provide host usb and then pass it through in userspace as well <damo22>/usr/bin/ld: /usr/lib/gcc/i686-gnu/14/../../../librumpdev_usb_pic.a(ugen.pico):(.text+0xb81): undefined reference to `rumpns_ndflush' `rumpns_clfree' `rumpns_clalloc' `rumpns_clfree' `rumpns_b_to_q' `rumpns_q_to_b' <azert>those functions are defined in tty.h <sneek>Welcome back azert, you have 1 message! <sneek>azert, youpi says: not directly, you'll really need to translate RPCs to rump calls <azert>ugen uses the associated data structure <azert>youpi: i was just wondering if all of that could be abstracted away by a library so that the code could be reused <youpi>azert: as a translator, yes. As a library, no, not directly <damo22>azert: first i need /dev/ugen to exist in rump, then i need to pass it through as a translated node <youpi>If you want read(rump_fd) to just work, you'd have to redirect the read() call <youpi>that's essentially what a translator is <azert>ok, but since the rump api is fixed, and you’ll often just want to translate a rump fd, maybe there could be a library that can help you write such a translator <azert>damo22: I think it also needs bulk reads and write <youpi>azert: I believe you'd end up with just one translator that you'd just always use <youpi>i.e. the library idea that you have, spans the whole translator <youpi>just like the node translator, for mach devices <damo22>azert: are you sure the data goes via /dev/ugen? <azert>damo22: check for bulk transfer mode in the netbsd ugen manoage <damo22>trivfs can do everything we need except ioctl <damo22>so i need to introduce an ioctl server on top of the trivfs? <damo22>azert: ugen.c should include tty.h then <azert>damo22: also the implementation in tty_subr.c <azert>not important, but I find it weird that those generic data structures shared with ugen are in tty <gnucode>sneek later tell mghackerlady You had mentioned on the #hurd channel that you felt like you should stay silent a bit more, because you do not know the Hurd that well. Don't feel like you don't know enough to hang in #hurd. I say silly things all the time that don't make sense. :) <sneek>Welcome back mghackerlady, you have 1 message! <sneek>mghackerlady, gnucode says: You had mentioned on the #hurd channel that you felt like you should stay silent a bit more, because you do not know the Hurd that well. Don't feel like you don't know enough to hang in #hurd. I say silly things all the time that don't make sense. :) <azert>mghackerlady: people have attempted to port Hurd to other Mach in the past <azert>I don’t know at which point GNUmach diverged from the original Mach such that the Hurd cannot just be recompiled <azert>But i would assume that also Darwin Mach diverged from the original Mach even more <azert>For instance, at some point they disabled task_create <azert>since creating a new BSD process calls task_create internally and they don’t want tasks without processes <mghackerlady>Kinda what I thought. I wonder if trying to port the hurd to darwin would help modernize the hurd or at least help move along ports to PPC and arm <p4r4D0xum>mghackerlady: ppc support was removed from xnu since 10.5 <sneek>p4r4D0xum, you have 1 message! <azert>one could just port the Hurd to run on Linux.. <mghackerlady>p4r4D0xum: Yeah, I know. I'm just thinking that if the inner workings of XNU haven't changed all that much, it would only involve porting over the stuff that doesn't run on PPC <p4r4D0xum>not an expert, but hurd doesn't use mach-o anymore so there is that as well <mghackerlady>would porting it to Linux be a good idea? Sice the mach is a microkernel I thought it would work better on another microkernel. Would there be any benefits aside from hardware compatibility? <azert>I mean, we have a microkernel, gnumach <azert>If you want to port it to something relevant, that would be linux <mghackerlady>right, but I thought the hurd was developed to use a microkernel for their unique abilities compared to monolithic kernels <azert>How is Darwin a micro kernel at all? <mghackerlady>wouldn't using Linux just be an admission of defeat? (somthing the hurd project notoriously refuses to do) <mghackerlady>You're right, darwin is an operating system. I was confusing it with its kernel, XNU, which is a hybrid kernel <azert>XNU doesn’t offer any advantage over Linux. Literally none <azeem>I thought the question was whether it offered a lot of advantages over GNU Mach, assuming the Hurd is much easier ported to it than to Linux <azert>It’s a fact that Darwin has been discontinued <azeem>how about porting the Hurd to Zircon <azert>azeem: wrong assumption, of course <azert>azeem : will Google pay for that? <azert>still I think it’s easier to port the Hurd to Linux then to Darwin <almuhs>in microkernel, currently the most advanced is Genode OS. But it's difficult to use, because use a new paradigm to execute programs and manage resources <almuhs>the advantage of GNU Mach + Hurd is that it's that the user environment is similar enough to GNU/Linux to ease the learning of the usage <almuhs>by example, Debian GNU/Hurd includes all typical commands of Debian, including apt as package manager. So, the only that you have to learn is the "settrans" command to manage some drivers and resources