IRC channel logs
2022-01-16.log
back to list of logs
<Gooberpatrol66>could netbsd's compat_linux be used in conjunction with rump to bring linux binary compatibility to hurd? <Curiosa>Gooberpatrol66: it would be more compatible and probably feasible to port the Linux Kernel to the Hurd as a single server running as a user process <Curiosa>Not very different from supporting it under qemu <Curiosa>But more similar perhaps to what windows does? Dunno the details of that <Curiosa>Well, better then qemu since Linux processes could map to Hurd processes and use that server for syscalls <yjftsjthsd3>User Mode Linux is a thing that already exists; AFAIK it only runs on Linux right now, but if you wanted to port Linux to HURD as a user process that's probably the easiest starting point <yjftsjthsd3>Alternatively, start from NetBSD's Linux compat and implement just enough to run UML for full compatibility:) (Or maybe that's harder; I'm not a kernel dev:D) <luckyluke>lkl (lkl.github.io) would be a better approach if it would progress, it could be used to provide directly the syscalls, e.g. to use the network stack, or write drivers <youpi>I'm not really surprised. There has been various projects on reusing the Linux kernel source, but since its internal API is very moving, it's hard to follow <youpi>targetting netbsd is much more sustainable <youpi>especially now that rump is upstreamed :) <luckyluke>sure, the only drawback I see is that netbsd has less drivers <luckyluke>I had LKL mostly running on GNU/Hurd a few years ago, but I remember I had issues with irqs <luckyluke>so I couldn't really reuse the driver I wanted <luckyluke>but for filesystems and "higher level" drivers it was working <luckyluke>I even created a .deb package at the time :) <Curiosa>Linux has already been ported to the Mach kernel, porting it to the Hurd should be probably similarly approachable but in many way more powerful/interesting <Curiosa>Of the paper I listed Fake interrupts might be interesting for Hurd itself since last time I checked posix signal handling had little issues <kilobug>Curiosa: it was a mix of an experiment and a way to boot Linux on some Mac hardware at a time, but yes it's not a project that has been maintained for "production use" <Curiosa>kilobug: I see, it’s that looking at the code it seems like a lot of work, but you’re also left wondering if that was even legal from a licensing viewpoint <Curiosa>They seem like mixing gpl2 code with source files whose license had clearly been removed along with documentation