Recent searches
Search options
Administered by:
Polished up my GHurdFileMonitor implementation for glib some more & made a draft MR out of it
And then, I went and finally pushed my epoll reworking over the finish line — there was not that much work left, but it had to be done. Once it was, everything fell into place, and now long polls work, short polls work, polls with no interests (basically using epoll as a sleep) work, signals work (including pwait and pwait2 atomically changing the signal mask), and everything seems to just work.
Also apparently my epoll is going into the Hurd upstream soon? Exciting! 
Next, I took my "portable" Wayland patchset and rebased it onto latest upstream main. It's both better and worse; the upstream have done some BSD portability work, so equivalents of some of my changes have effectively been upstreamed, but also they added eventfd usage, so, yay, more things to patch out.
Anyway, so I got Wayland building on the Hurd once again. The tests don't yet pass, I'll need to look into that tomorrow.
After that: Owl, and gtk with its Wayland backend.
There we go! 
This is Weston's demo clients again — being built with a lot less hacks this time.
@bugaevc congrats. Wayland doesn't depend on linux DRM
@gfleury I mean, I've already done this years ago; I'm now only refreshing / rebasing that work, and making sure it still works with the reworked epoll.
@bugaevc I know you work on that in the past. But I want to know if Wayland can work without DRM support
@gfleury it can! But Wayland is just a protocol, you also need clients & a compositor, and those are likely to want DRM. Owl doesn't, but more advanced ones like Weston and Mutter will. Which is why we probably want DRM on the Hurd, if we can port it.
@bugaevc watching the Hurd become more functional is nice
@bugaevc I would help but I have my own wild OS projects
@bugaevc if I knew more about LLVM internals I might attempt to do Rust to it but that sounds scary tbh
@alilly hm, but Rust has already been ported as this year's GSoC project?
Also this has nothing to do with LLVM internals (LLVM/Clang has already been ported too), and everything with the libc crate & kernel-specific parts of std. Like, you have to mirror 'struct stat' layout, which differs between systems, and so on.
@bugaevc oh fun
see, I'm not really up to date on any of this stuff so
my main reason not to fiddle with Hurd was that I'm not very comfortable with C, if Rust is a working option I may take a look at how translators work and do something silly like sqlitefs
@bugaevc I have some concepts for a desktop environment that might play well with Hurd, though I'd need to go learn what a file is first.
@alilly to manage expectations, it's said to be working somewhat for someone, but it's not like you can 'curl rustup | bash` and have it just work yet.
That being said: it would be *super* interesting to explore what building translators would look like in Rust. I don't think bindings to the existing C translator frameworks would work well, since it's the typical C-ish sea of pointers. We should probably go for a new Rust-native framework, perhaps based on async/await.
@alilly if this sounds exciting and you'd like to join in, I could help you figure out what a file is or whatever
@bugaevc I mostly just need to be pointed to a current programmer's manual, assuming it exists and is decent.
@alilly there is https://www.gnu.org/software/hurd/hurd/reference_manual.html, but I wouldn't say it's clear, unless you already know what it's talking about.
@alilly Here's a simple hello world translator: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/trans/hello.c
This is what it looks like:
sergey@teleri:~$ settrans --active --create /tmp/hello /hurd/hello
sergey@teleri:~$ cat /tmp/hello
Hello, world!
sergey@teleri:~$ fsysopts /tmp/hello --contents $'Hello, Athena!\n'
sergey@teleri:~$ cat /tmp/hello
Hello, Athena!
sergey@teleri:~$
Here's /hurd/null that powers /dev/null: https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/trans/null.c
@bugaevc I get the /basic/ concept of translators; they're programs that attach to a namespace and provide a file interface, similar to filesystem mounts in Unix but userspace and they can be single files instead of directories. What I don't understand is how complex the interface can be; if I want to write, say, a mailto translator, would I be able to use xattrs or ioctls or a file that has both children and content or RPCs or whatever to accept a subject line or attachments, etc.
@alilly xattrs no, ioctls yes (but that won't be very shell-friendly). It can both contain content and have subnodes at the same time, though that's unusual, but it makes sense for e.g. httpfs (also actually that's how all directories are on ext2fs, you can cat /some/dir, and it will give you something resembling how dirents are stored on-disk, but nothing uses this).
@bugaevc Well that build of the manual appears to be from 2007; which repository has the texinfo source?
@bugaevc alright, I had to clone the entire repository and create an empty doc/version.texi but now I have a current HTML manual
@bugaevc Yeah I mean building usable libraries is the second phase of doing Rust to it.
@bugaevc Porting the Rust toolchain is down the list, self-hosting is not essential to achieve early.
