#Maestro - Linux-compatible-ish OS in Rust
1 messages · Page 7 of 1
Implementation of the epoll API
while working on epoll, I am also fixing my poll and select system calls that are broken
I tried running Xorg with epoll, and now it seems to want sockets (good)
chop chop
chop chop
chop chop
spent the last few hours debugging shitty concurrency issues in the scheduler™
I don't usually make prs for my own projects
I jump between working on different stuff too much
not sure how that prevents making prs tbh
i have prs with hundred commits sometimes
they dont have to all match a specific topic
do several PRs and rebase when needed
Currently implementing unix domain sockets for xorg (and later wayland I guess. I think it also uses those?)
(does not work because rename* is broken, I have a stale PR for fixing that)
[2979566.935] _XSERVTransSocketCreateListener: failed to bind listener
[2979566.935] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[2979567.935] _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
[2979567.935] _XSERVTransSocketCreateListener: failed to bind listener
[2979567.935] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[2979567.935] _XSERVTransMakeAllCOTSServerListeners: failed to create listener for unix
[2979567.935] (EE)
Fatal server error:
[2979567.935] (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
[2979568.935] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[2979568.935] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[2979568.935] (EE)
[2979568.935] (EE) Server terminated with error (1). Closing log file.
now let's fix bind
It seems I need connect now
it wants connect because it tries to connect to a font server, because it cannot find fonts, because I did not package them
alright, currently packaging fonts
it seems to want connect anyways so I am currently implementing connect for unix sockets
should my socket structure in the kernel (in case this is a listening socket) have a list of all client sockets currently connected to it? or should I do that another way?
and like, on connect, I insert the client socket in the list (which will require the struct to be shared in between the listening socket's list, and the open file structure)
Not really, that is not how sockets work in the unix world
When a client connect()s you add it to a backlog and when the server accept()s you create a new socket object that pairs with it
You dont need to keep a list of everything connected
thanks!
progress
can't find modules because it happens a / after file paths for some reason, prolly a getdents64 issue
okay that's actually an issue of driver not installed
#ui message
@shell tusk claude is telling me xf86-input-evdev needs udev too, is it lying?
not really-ish
I use evdev without udev
but I needed to patch in a backend for proper autodetection
you could theoretically get away with just adding a config file with the devices for initial testing and then when evdev is known working just ctrl+C ctrl+V ing my patch lol
omw to steal ur patch ❤️
okay, now I have xf86-video-fbdev. It opens /dev/fb0, and now it seems to want /sys/class/graphics/fb0/device/subsystem (not implemented yet)
once I get xorg working, maybe I'll try getting into writing a wayland compositor. Idk if I'll do it by hand or use a lib like https://github.com/Smithay/smithay
if you do write one, make it based and not hard depending on linux apis
keep in mind that it wants a pci device
make sure to use every kind of special fd imaginable :^)
don't forget procfs, sysfs, cgroups, namespaces, etc
(it depends on rust)
preferrable over having to support epsteinfd or some bullshit
okay, I have the sysfs and the FBIOGET_VSCREENINFO/FBIOGET_FSCREENINFO ioctls.
Now I need to be able to map the framebuffer in Xorg's memory with mmap
where did you put fbdev attributes in sysfs?
what does the structure look like
a symlink pointing to an empty directory
framebuffer stuff seems to have been fixed? (still ain't displaying anything though). right now it's need xkeyboard-config and xkbcomp so I am packaging those
and xorg accepts that?
it shouldn't need keyboard to at least display xeyes
epstein file
they done implemented epsteinfd 😭
checkmate liberal
you were talking about epoll or eventfd stuff or some other stuff?
I am implementing epoll right now because xorg wants it
but maybe that comes from the way I built it
you have to patch it if you don't want it using epoll
but then, why are you exposing a header for something you don't implement lol
cause i enable the mlibc linux option for some reason
i think some stuff was being annoying and i just did that
and then patched xorg-server
diff --git xorg-server-clean/include/meson.build xorg-server-workdir/include/meson.build
index bda84bd..1f63b00 100644
--- xorg-server-clean/include/meson.build
+++ xorg-server-workdir/include/meson.build
@@ -143,7 +143,7 @@ conf_data.set('HAVE_UNISTD_H', cc.has_header('unistd.h') ? '1' : false)
conf_data.set('HAVE_ARC4RANDOM_BUF', cc.has_function('arc4random_buf', dependencies: libbsd_dep) ? '1' : false)
conf_data.set('HAVE_BACKTRACE', cc.has_function('backtrace') ? '1' : false)
conf_data.set('HAVE_CBRT', cc.has_function('cbrt') ? '1' : false)
-conf_data.set('HAVE_EPOLL_CREATE1', cc.has_function('epoll_create1') ? '1' : false)
+conf_data.set('HAVE_EPOLL_CREATE1', false)
conf_data.set('HAVE_GETUID', cc.has_function('getuid') ? '1' : false)
conf_data.set('HAVE_GETEUID', cc.has_function('geteuid') ? '1' : false)
conf_data.set('HAVE_ISASTREAM', cc.has_function('isastream') ? '1' : false)
not the greatest way to do it
but it does the job
wha
oh interesting
that's how i ported weston
i am not linux abi/api compatible
but i do expose epoll, just like solaris
ah
or bsd via kqueue shim
maybe I should do that instead
larp
everything is a subset of linux if you squeeze your eyes
I get a black screen. come on. I'm almost there
letting claude package twm because I don't like packaging
have you tried running anything on xorg yet
I wanted to run xeyes and then I realized I am missing approximately 834279832748932794 dependencies, so claude is packaging those rn instead of twm
That is a good sign (unless you are passing like -retro or something)
nah, just running Xorg with no args
Yeah it does that
if you just run X you will get a black screen
if you add -retro you will get the classic root weave
(if its working)
so it does not work
my OS is slooooooow as fuck, I really need to optimize this
like, I have to wait a few minutes to attempt to launch Xorg
it actually works apparently (I am printing syscalls so it's messed up)
It still hasn't any ways to read the keyboard, and I don't even have a mouse driver yet
currently packaging shit to get xeyes running
kinda want to start my wayland compositor, I wanna make something pretty
running startx /usr/bin/xeyes shows a black screen. I guess imma continue another day, time to sleep
weren't you writing a custom X implementation for maestro?
is that plan abandoned?
also foe wayland are you going to implement what is necessary for an existing wayland compositor library or from-scratch?
try xinit /usr/bin/xeyes -- :0
Will do
Yeah imma do Wayland instead of X. Also idk yet if I'll use a lib or do from scratch
ahhh
fair
using wlroots might be good since you're aiming for linux compat methinks
unsure though
:P
Maybe I'll do that
dead project
(I'm currently running this, it takes forever to start because my OS is slow as fuck)
are you running with tcg?
xeyes wants setitimer which I didn't implement
uuuuh, maybe
try kvm
yeah
that's a lot better. but still slow. even with tcg it should start instantaneously, right?
on my kernel it takes about 3-4 seconds to start xorg and a window manager on tcg and -smp 1
do you compile your kernel with optimizations enabled because they help a ton
no
yeah absolutely do that then
but even then, I am pretty sure it is not supposed to take several minutes
my kernel takes 2-3 seconds with tcg
yeah there's definitely an issue
what do you use for disk access
nvme
weird then
When I was building my Rust kernel using the dev profile it would take several seconds (half a minute maybe) to map Higher Half
In release mode that's instantaneous
It's so unbelievably slow im not even sure how that's useful for debugging
erm actually theres approximately 238423895902367589247598273485768923754892347982243 dependencies, not 834279832748932794. (xorg moment)
pretty sure you underestimated the dependencies (jk)
implementing that rn
xeyes can work without setitimer perfectly
So maybe it's xinit who wants it?
maybe some random thing idk
did u tried to build kernel with optimizations and disabled serial output
actually it seems like smithay supports almost all the base protocols, most of the wlroots ones, and I think some of the KDE ones?
- that's rust also so natural fit
the only problem I can see is that it doesn't support vulkan yet/right now/at all it seems
idk why i am saying this as if this is something you wouldn't know already, soz 😭
well I didn't know that 
ah
fair
I like wayland it's very funny
it has done horrid things to computing (not allowing funny cat to chase my cursor) but it's funny regardless
wayland kicked my dog and fucked my wife
kinky
was dog and wife pregnant ?
no. only linux apis kick pregnant dogs
real
hello, I am returning to this project rn
I haven't worked on it for 1 week and a half and it feels like I haven't touched it in 6 months
I am merging the stuff I started on Xorg and putting it aside for now. I have a much more urgent matter to address: the kernel is slow as hell
It's such fucking unbearable to debug