IRC channel logs
2025-04-18.log
back to list of logs
<sneek>ZhaoM, gnucode says: that gplv3+ is probably the more preferable license. <ZhaoM>damo22: asking me or gnucode? :) <damo22>i mean, one of the reasons we have gplv2+ is because there is some existing gplv2-only code linked, so might be preferable to stick with 2+ <ZhaoM>yeah that's why I ask if gplv2+ is preferable <ZhaoM>I realized the gplv2-only code <damo22>but still preferable for which repo? <ZhaoM>because I'm trying to implement rumpfs <damo22>check the existing licence version and use that <ZhaoM>which one is 'the existing license version' <damo22>it should be in the COPYING file <ZhaoM>I haven't done much there is only a prototype :) <damo22>github is not ideal for sharing free software but its better than nothing <ZhaoM>any alternatives recommendations? <damo22>eg self hosted git, or something like codeberg? <damo22>hmm do you really need all those stubs? <damo22>i think rumpfs would implement almost everything for the filesystem itself? <damo22>there should be an example of how to use rumpfs in rumpkernel/ <damo22>its been ages, but i think i remember seeing something in there <ZhaoM>those stubs are needed to use libdiskfs <ZhaoM>I have't go more in depth in rump <damo22>try to find out what the api is for using rumpfs <ZhaoM>I tried to follow the 'Get Started' on Github but I always had some compilation issues :| <ZhaoM>so I have just implemented a prototype to make sure rumpfs can compile first <damo22>we dont use rumpkernel from github <ZhaoM>thanks for pointing it out :) <damo22>we use the one on salsa.debian.org <damo22>but you dont need to compile rump <ZhaoM>I used the one from github as it's the first one given by search engines :/ <damo22>we already have the libraries installed <damo22>the source tree is good to help you know how to use rump <damo22>but you shouldnt need to compile anything there unless something is missing <damo22>you can write a test program with int main() { rump_init(); return 0; } <damo22>i think your approach is the wrong way around, you need to start by seeing what api to use to attach to a filesystem from rump, with a simple program that opens a block device <damo22>you may find you dont need anything else <damo22>just a little bit of glue code to make it into a translator <damo22>eg, check the source code for netbsd's "mount" command there will be an option to use rump <azert>On netbsd pooka implemented libp2k as a shim from rump to puffs <azert>I’m sure Hurd would need something similar <azert>I’d start with tmpfs as a stub on the Hurd side <azert>Since the hard part is caching I guess that’s an option to get decent performances <azert>Otherwise, the good part is that rump is currently used on netbsd for unsafe things like external drives <ZhaoM>sneek later tell azert It seems to me our fs.defs is something like puffs <azert>ZhaoM: then why not just porting puffs to the Hurd? <sneek>azert, ZhaoM says: It seems to me our fs.defs is something like puffs <azert>If it’s really the same, then it would be better to act at that layer since it will provide the most code reuse <ZhaoM>I mean from the perspective of the functionality <ZhaoM>I haven't read the source code <azert>Ok, but I think you need to chose which layer to port <azert>And puffs seems like a good candidate to me <azert>performancewise, a tmpfs using a rump kernel as a back storage might be more promising <azert>Although one have to think about data loss risks <azert>Implementing puffs will gives us fuse for free <ZhaoM>sneek later tell azert I see. If we can port puffs, we can directly have libp2k and use rumpfs <ZhaoM>Of course it will need to be in userspace instead of as a kernel component, we are microkernel system <ZhaoM>them it seems what I have done is indeed wrong <damo22>ZhaoM: i dont know if you need puffs just look into the source of mount on netbsd and check what is needed to mount a filesystem with rump <ZhaoM>so this command will run ``rump_<fstype>'' <damo22>yeah but check the source what that actually does <damo22>it may be easier with ctags and vim <damo22>it should be trivial then to port that to hurd if instead of taking parameters you make it run on a translator node <damo22>but first you can try using the main() examples as is <gnucode>well, I still can't seem to get the hurd-console to start <gnucode>I updated my T43 hurd machine today. <gnucode>sudo console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d generic_speaker -c /dev/vcs <gnucode>console: Starting driver vga failed: Invalid argument <gnucode>That must mean that I put in the command incorrectly somehow... <gnucode>but that seems like the right command...