klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<qookie> well i was just porting it to aarch64 so the code to do that was already there :^)
gxt has quit [Ping timeout: 258 seconds]
FreeFull has quit []
gxt has joined #osdev
<geist> for zircon we basically have a mechanism whereby early code can keep a list of reserved regions of physical memory, some of which comes from the bootloader in whatever mechanism it is, and some of it from the early boot code (page tables, etc). when the VM comes up, which is pretty early as the PMM arenas come online those pages get instantly knocked out and marked as wired so they're un allocatable
<geist> so that by the time the VM is up and taken over memory allocations, there's no chance of accidentally allocating something with something important in it
<heat> you know, i wonder how bootloaders are coping with the new accepted and unaccepted efi memory types
<heat> i guess they'll just assume unaccepted = unusable
solenya has joined #osdev
<heat> seems... sane
<clever> heat: i think the osdev wiki says that efi applications can make up their own memory types, but some firmware wont allow it
<heat> no, this is a new efi thing for TDX and SEV
<heat> memory needs to be accepted before it's usable
<heat> you accept it through $tdx_or_sev_mechanism
<heat> so what happens is that you get a bunch of memory regions with an unaccepted memory type
<heat> linux (or your favourite TDX/SEV aware kernel) will then accept them
<heat> supposedly as needed
frkzoid has quit [Ping timeout: 244 seconds]
opal has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
opal has joined #osdev
gxt has joined #osdev
matt__ has joined #osdev
netbsduser has quit [Remote host closed the connection]
SpikeHeron has quit [Quit: WeeChat 3.6]
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
SpikeHeron has joined #osdev
MiningMarsh has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
Lumia has joined #osdev
matt__ has quit [Ping timeout: 244 seconds]
Lumia has quit [Client Quit]
lentement has joined #osdev
smach has quit [Ping timeout: 244 seconds]
frkzoid has joined #osdev
smach has joined #osdev
lentement has quit [Ping timeout: 244 seconds]
lentement has joined #osdev
foudfou has joined #osdev
foudfou_ has quit [Ping timeout: 258 seconds]
smach has quit [Ping timeout: 244 seconds]
<kazinsal> > DIAGNOSTICS: 'Ouch.' for input out of range or for garbage input.
<kazinsal> I love these old Unix manuals :)
<epony> they are not old
<kazinsal> I'm reading the Fourth Edition manual, which turns 50 next year
<epony> you're just too small to ride that bike
<epony> but why precisely 4th edition Research Unix?
carbonfiber has quit [Quit: Connection closed for inactivity]
<epony> at least "upgrade" to the 80ies https://en.wikipedia.org/wiki/Research_Unix#Versions
<bslsk05> ​en.wikipedia.org: Research Unix - Wikipedia
<bslsk05> ​en.wikipedia.org: A Commentary on the UNIX Operating System - Wikipedia
<kazinsal> Fourth Edition because it's the edition that was written in C, and because I'm poking at reimplementing it for IBM PC and XT class machines
<epony> yeah, but why do you think it is a realistic objective for the XT
<kazinsal> Because it's fun?
<epony> no MMU
<epony> how fun could it be
<kazinsal> Neither did early PDP-11s that Unix could run on.
<epony> something was missing, to have to use CP/M those days.. what could it be?
<kazinsal> It's fun because it's a charming retro development challenge -- implement a vintage operating system on a vintage machine of known, relatively fixed, simple specifications.
<epony> no disk?
<epony> no protected mode?
<kazinsal> First-generation XTs came with a 10 meg hard disk and 64-256K on the mainboard
<epony> and in emulator everything can be a bit spruced up ;-)
<kazinsal> Could, but that's not the point of the challenge
<epony> well, let's find out the real limitation then
<kazinsal> I think there will be a limitation when it comes to how sufficiently multi-user the system can be, but since my preferred cycle-accurate vintage PC emulator doesn't (yet) have support for attaching serial ports to other serial-equipped applications over eg. named pipes or TCP sockets, I'm not considering that a priority-1 issue at this time
<dh`> shouldn't be a problem as long as the users aren't hostile
<epony> a serial port data exchange is the first and only thing I would do there
<epony> it's not even an 80286
<kazinsal> I'm not concerned about lack of memory protection as that's also something we can consider a historical quirk of early Unix -- before memory protection was standard on PDP-11s for Unix installations, it was customary to inform people that you were about to load a new a.out you had just produced so they could save their work in case the machine dumped core
<epony> and the other thing you would not have is multiple physical storage devices, serial ports and system console
<kazinsal> You'd be surprised how many bizarre ISA cards were built...
<epony> it's a severely limited machine, unlike the PDPs
<dh`> erm
<kazinsal> It may not have a front-panel to toggle bootstraps into but I am pretty sure you couldn't order an XT from IBM without at least one display adapter
<dh`> the mainboard architecture gives you four serial ports and most machines came with two
<dh`> and multiple disks were definitely a thing
<bslsk05> ​en.wikipedia.org: Intel 80286 - Wikipedia
<kazinsal> I think you are under the severe misunderstanding of the difference between multitasking and memory protection.
<epony> the misunderstanding is somewhere else
<dh`> 64K is extremely tight for writing it in C rather than assembler, but 256K shouldn't be a problem
<kazinsal> There were multiple commercial operating systems in the early 1980s released for 5150/5160s, so this is not some magical new impossible feat I am attempting
<dh`> amigaos fit in 256K (though not that well) but it was far more substantial than v4
<epony> you have the system books for the PC?
<kazinsal> Of course
<epony> I mean the hardcopies from that epoch.
<kazinsal> I'd like to get my hands on hard copies but unfortunately I haven't managed to yet
<dh`> I am pretty sure all the ones I might have had got thrown away
<epony> I have them here, and have read them at the time when the XT was modern..
<dh`> I have some stuff from that period (e.g. turbo pascal manuals) but I think I decided that 16-bit x86 was best burned
<kazinsal> Quick perusal of PC Magazine from August 1982 -- a Unix-like system from Quantum Software Systems was available in a four simultaneous user configuration requiring 128K of RAM and a 5 meg Winchester disk
<epony> that would be CP/M
<dh`> multiuser cp/m?
<kazinsal> QUNIX
<epony> it needed the Z80 then on both 6502 and 8086
<dh`> er wut
<kazinsal> Pardon
<dh`> ITYM "it only ran on Z80 then, not 6502 or 8086"
<epony> it was also barely multi(two) process not multiuser
<kazinsal> Ha! Okay, looks like Quantum QUNIX was renamed in 1984 to avoid being sued by Western Electric... to QNX
<dh`> oh heh
<bslsk05> ​en.wikipedia.org: CP/M - Wikipedia
<dh`> how did v4 fork?
<dh`> relatedly, are you planning to allow > 64K of either code or data in one process?
<kazinsal> Pretty standard naive fork implementation based on the description in the manual. Unfortunately as far as I know complete source for v4 is lost
<kazinsal> Not sure, but I'd likely need to adapt a.out for the DOS compact memory model, which could profe interesting
<kazinsal> 64K of code ought to be enough for anybody ;)
<epony> segmentation and paging lived on for a while
<dh`> the reason I bring this up is that forking without VM either requires that the two copies live at the same addresses (in which case you have to swap one out to run the other) or copying both code and data and applying relocations (a mess meaning you have to keep them somewhere), or a pic model that you aren't going to get in 16-bit x86
<dh`> sticking to <= 64K will give you a pic model
<kazinsal> Yeah, that's part of the trickiness of it all
<dh`> also at this point it's difficult to get a toolchain suitable for this environment
solenya has quit [Ping timeout: 252 seconds]
<kazinsal> That was definitely one of the hard parts of starting this up, yes. It took a while for me to figure out the quirks of Open Watcom's linker
<dh`> can you get hold of a copy of Turbo C?
<epony> one thing is certain, even if you did not achieve anything, you will definitely find out why the coprocessor was needed
<dh`> huh?
<kazinsal> Also Open Watcom has like, four different front-end drivers for the actual compiler, each of which has a different and incompatible syntax and feature set
[itchyjunk] has quit [Remote host closed the connection]
<dh`> charming
solenya has joined #osdev
<kazinsal> Weird things, too, like the front-end that's vaguely compatible with gcc invocation syntax specifically not being able to target the tiny memory model, but the front-end that's vaguely compatible with cl.exe's invocation syntax can
solenya has quit [Ping timeout: 260 seconds]
solenya has joined #osdev
skipwich has quit [Quit: DISCONNECT]
<dh`> strange
<dh`> I suppose it's the result of having different versions sold to different audiences that all got rolled into the free version
skipwich has joined #osdev
<dh`> and never seriously maintained since I guess
lentement has quit [Remote host closed the connection]
<epony> think of its "importance" and 'significance' accordingly
<bslsk05> ​en.wikipedia.org: History of compiler construction - Wikipedia
zaquest has quit [Ping timeout: 248 seconds]
rpnx has quit [Ping timeout: 252 seconds]
eroux_ has quit [Ping timeout: 260 seconds]
rpnx has joined #osdev
cowboy8625 has joined #osdev
eroux has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
solenya has quit [Quit: WeeChat 3.6]
<cowboy8625> is there a way to work on a part of the os with out having all the inisual bootloader and jazz?
<geist> yeah, this is where i recommend using qemu and -kernel option, which skips most of that jazz
<geist> but also depends a bit on which arch you're interested in
<geist> though in general -kernel on most arches qemu just gets ya going and skips the jazz part
dasabhi has joined #osdev
<dasabhi> hellooo
<dasabhi> missed you guys
<geist> 'lo
<dasabhi> have any of you guys built some type of edac system in your kernels
zaquest has joined #osdev
<geist> what is edac?
<dasabhi> error detection and correction
<epony> the real question to be concerned with is, why in kernel space and not on HW
<dasabhi> linux has a fany edac subsystem
<dasabhi> well its for reporting
<dasabhi> memory controllers implement the actual EDAC
<epony> of the HW SECDED?
<geist> that's not necessarily edac as much as a driver for the existing hardware
<epony> now, make a parallel now with FS variants of that..
<dasabhi> but kernel space actually gets the error info on the memory module
<dasabhi> yes a driver, has any one needed to build such a system
<epony> the FS ECC is in kernel space
<klange> I don't think I've even had the opportunity to _see_ ECC RAM.
<epony> I have ECC RAM in my desktop..
<epony> there are rare versions of laptops with it too, but it makes no sense there
<epony> desktop as in "tower" in the WS class
<moon-child> isn't qemu -kernel just multiboot?
<dasabhi> yeah that makes sense, most desktop machines dont have ecc memory
<moon-child> doesn't seem like you get to skip very much vs just using grub. A bit of disc setup ceremony, and that's it
<epony> AMD CPUs support that on the dual core and later gen consumer CPUs
<epony> Intel only on the Xeon lines
<moon-child> klange: it just looks like ram :P
<dasabhi> either ways, just wondering when writting a device driver, should the probe functions we register be written in some type of loop?
<dasabhi> first time modifying a device driver for myself
wxwisiasdf has joined #osdev
<wxwisiasdf> Hello people
<dasabhi> and the sample device drivers i read up on in linux land, did a few setups and ended their probe commands
<klange> moon-child: x86 -kernel is multiboot, but missing some modesetting functionality that I keep thinking I could add and the QEMU dev people have said would be accepted if someone bothered to write it, but...
<cowboy8625> thanks @geist
<klange> It's good for not having to set up a GRUB disk, which has historically been at least somewhat annoying (and still kind of is grub still gets packaged in a way that makes the tools awkwardly dependent on the host system's own grub configuration)
<epony> in you're not working on crytpography research, do not run long running important programs like emulators and virtual machines, or language and application servers, or shared resource servers, and if you reboot or otherwise interrupt your workload frequently, you have no use of ECC RAM in particular in HW, and can deal with "application" level validation of data paths and files out-of-order
<klange> what are we calling "long running"
<epony> open for individual selection probably (arbitrary by importance or consumers)
<epony> ot
<epony> it's olways good to have but it's a bit slower
<epony> there are multiple variants of the HW implementation and memory module types that support that feature "set"
<epony> exist and are in use since at least mid-90ies
<epony> operating systems and applications that do excessive or critical evaluation of memory regions and usage will be benefitting from this moreso, than naive implementations that do not move data in memory much, or not check its validity, and that is significant improvement in reliability there, despite being a combined "slower" end result
xenos1984 has quit [Quit: Leaving.]
lentement has joined #osdev
<mxshift> dasabhi: yes, I've worked on multiple systems. Linux edac, Google's mcelog, illumos FMA, and various RTOS implementations
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
<geist> klange: agreed. ocne you figure grub out it's not too bad, but it requires fiddling with more than one host os specific tools, etc and then that can turn into it's own set of dependencies that's hard to support
<dasabhi> mxshift: googles mcelog? i thought mcelog was just used in bsd
<dasabhi> mxshift: wouldnt google use linxu edac
<dasabhi> mxshift: have you ever written custom edacs?
<dasabhi> mxshift: for a specific memory controler ?
<mxshift> No. Google data center servers primarily do error detection in user space. mcelog was written specifically to allow recording of ECC events so they could be decoded later
<mxshift> Yes. Working with folks on EPYC 3rd gen for illumos FMA currently
lentement has quit [Remote host closed the connection]
<dasabhi> mxshift: illumos, does any one actually use that?
<epony> joyent
<mxshift> My employer, Oxide
<bslsk05> ​en.wikipedia.org: Joyent - Wikipedia
lentement has joined #osdev
<dasabhi> mxshift: company has a really nice website
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
lentement has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #osdev
dasabhi has quit [Ping timeout: 252 seconds]
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
lentement has joined #osdev
vdamewood has joined #osdev
the_lanetly_052_ has joined #osdev
xenos1984 has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Killed (iridium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
lentement has quit []
lentement has joined #osdev
<heat> klange, isn't x86 -kernel an amalgamated set of various boot protocols?
<heat> i can think of multiboot, multiboot 2, linux x86 boot protocol, maybe xen
<heat> (actually, do they support mb2?)
<zid> no mb2 I don't think
<heat> zid, i think your mobo is super fucked
<heat> multiboot and multiboot2 are kinda trash aren't they
<zid> It can do 0x53726448, and multiboot 1
<heat> i bet most users of multiboot {1, 2} really are hobby OSes lol
<heat> and g n u h u r d, but who uses that
lentement has quit [Client Quit]
<zid> * Check if the file is an uncompressed kernel file (ELF) and load it,
<zid> * saving the PVH entry point used by the x86/HVM direct boot ABI.
<zid> aka 'only give this as the error message, as multiboot fails silently'
heat has quit [Ping timeout: 260 seconds]
wxwisiasdf has quit [Quit: Lost terminal]
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
the_lanetly_052_ has quit [Ping timeout: 244 seconds]
potash has quit [Read error: Connection reset by peer]
potash has joined #osdev
sikkiladho has joined #osdev
leah_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
leah_ has joined #osdev
leah_ has quit [Client Quit]
thatcher has joined #osdev
thatcher is now known as leah_
leah_ is now known as thatcher
bauen1 has joined #osdev
air has quit [Read error: Connection reset by peer]
gog has quit [Ping timeout: 240 seconds]
GeDaMo has joined #osdev
foudfou_ has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
dude12312414 has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
[itchyjunk] has joined #osdev
potash has quit [Remote host closed the connection]
tarel2 has joined #osdev
potash has joined #osdev
davros1 has joined #osdev
<davros1> Regarding the effort to reverse engineer apple's M1 GPU (for linux support) - could that yield a 3rd party native Vulcan/OpenGL driver for M1/Mac OSX, or does the mechanism for triggering GPU work require official OS support
<davros1> in modern graphics APIs you build command lists in user program space, right?
<epony> oh look at that ;-)
<davros1> lo
<davros1> lol
<j`ey> davros1: the GPU side has been tested by running opengl on macos
<davros1> Ok thats encouraging
<davros1> Either goal is of interest to me. One of my reservations about Apple is that they deprecated OpenGL and dont support Vulkan (and doing vulkantranslated to metal seems awkward to me)
<davros1> Similarly I just prefer linux as a programming environment
<davros1> But the M1 hardware is so appealing to me
<vdamewood> It's so shiny
<davros1> I miss having a computer where I dont think the ISA is disgusting
<vdamewood> davros1: Been stuck on x86?
<davros1> I have ARM toys and x86 main machines. I bought an M1 mini to debug something, intending to leave it in the corner . Then this UK energy crisis hit and I thought "hang on, 7w idle makes it a perfect daily driver"
<davros1> Now my predicament is that I regret not getting the Mac studio and am still considering upgrading
<davros1> But for reasons expressed I have reservations about apple. Either linux/m1 or OpenGL+Vulkan /macOSX fixes them
<j`ey> davros1: get the studio, try out linux on the mini until it works well enough for you, then switc on the studio ;)
<davros1> Yeah thats exactly one scenario I am considering
<davros1> I would not install linux on "My only Mac"
<vdamewood> I'm happy with macOS myself, but I'd love to run Linux in a few virtual machines.
<j`ey> davros1: I mean it dual boots by default anyway
<vdamewood> In fact, that's what I have no, but i'm on an Intel Mac.
<vdamewood> have now*
<davros1> Yeah I'm still just nervous installing something
<davros1> But with a spare I could be more adventurous
<tarel2> as Linux user Vdamewood what do you like about mac?
<vdamewood> tarel2: Originally, the fact that I had a Shiny GUI with a nice, FreeBSD-based Unix system in the terminal.
<davros1> Heh. I like the fact everything is top-menu by default
lukflug has joined #osdev
<vdamewood> davros1: Infinite edge UI design?
<vdamewood> tarel2: These days, I also like the fact that my computer integrates with my TV and my Phone.
<davros1> Fitts law
<vdamewood> Same thing. The edge is infinitely large.
<tarel2> I can did that  vdam
<tarel2> dig my bad
<tarel2> my os works with my phone too , both are Linux
<davros1> Synergy of fitts law and keeping the menu out of each window where it wastes space and is often truncated anyway
<davros1> Yeah just checking thats what you meant by infinite edge
<GeDaMo> What are the five points easiest to click with the mouse? :P
<vdamewood> davros1: One of the things I like abut macOS is how much more intuitive the equivalent of MDI is on macOS. Instead of having a Window within a Window, the containing Window is the desktop itself, so your windows are just windows.
<vdamewood> GeDaMo: Where the mouse is, and each of the corners.
<vdamewood> screen corners
* GeDaMo gives vdamewood a coconut
<vdamewood> Yay!
* vdamewood drills open the coconut and drunks the milk.
<vdamewood> drinks*
<davros1> Gnome shell has utterly retarded waste of top screenspace
sikkiladho has quit [Quit: Connection closed for inactivity]
<davros1> When the linux world tries it usually gets UI wrong
<davros1> But 2nd best use of the fits law space is putting the dock there, which plenty of linux DE's can do. But the best use is the application menu.
<tarel2> gnome is one I had because it was just there at the time ,but when I do pick I like KDE
<vdamewood> At least KDE still has the Application menu in a corner.
<vdamewood> GNOME 2 was so much better, especially since in a lot of wasy their take on UI design was 'copy Apple'
<davros1> Corners can be lost in a multi monitor setup , but top menu still works with monitors side by side
<tarel2> Xfce , is what i have on the pi
<davros1> Yeah xfce is my favourite linux de
<tarel2> it does not take much right?
<tarel2> I guess I like xfce for the  simple reason , its easy to understand.  so if need gui I don't need something big like KDE or gnome
<davros1> Yeah its just right, its not super minimal like the tilers , but doesn't try to do too much, which linux DE's always get wrong
<davros1> So what's the deal with opensoruce OpenGL on the M1 .. how does a GPU command list get executed
<davros1> In a past life I did console dev where we had documented registers for that sort of thing
<davros1> "Build command lists in memory and point hardware at it, write here and it goes"
<bslsk05> ​gitlab.freedesktop.org: src/asahi/lib/agx_device.c · main · Mesa / mesa · GitLab
<j`ey> the registers/hardware part is the kernel drivers job
<davros1> So they're reliant on the OS to have exposed a service to do that, which I'm guessing metal uses under the hood
<davros1> So from the OS's perspective, it needn't know if the calls its getting were from metal or anything else, so long as the format is right
frkzoid has quit [Ping timeout: 244 seconds]
<davros1> I see some allocators aswell, I'm guessing you have to ask the kernel for pages that are GPU approved
netbsduser has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
davros1 has quit [Quit: This computer has gone to sleep]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
matthews2 is now known as matthews
Alexthek1d has joined #osdev
mykernel has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
nyah has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
thatcher_ has joined #osdev
thatcher_ has quit [Client Quit]
tarel2 has quit [Quit: Client closed]
tarel2 has joined #osdev
thatcher_ has joined #osdev
gog has joined #osdev
tarel2 has quit [Ping timeout: 252 seconds]
gog has quit [Quit: byee]
carbonfiber has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
archenoth has joined #osdev
Piraty_ has quit [Quit: -]
Piraty has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
smach has joined #osdev
mykernel has quit [Quit: leaving]
hl has quit [Quit: ZNC - https://znc.in]
lkurusa has joined #osdev
hl has joined #osdev
zaquest has quit [Ping timeout: 252 seconds]
zaquest has joined #osdev
demindiro has joined #osdev
<demindiro> virtio-gpu & it's "hardware" cursor confuses me, it appears it moves the cursor relative to my monitor instead of the QEMU window.
<demindiro> Moving it also causes the PS/2 mouse to generate an event so the cursor gets stuck in a corner
dude12312414 has joined #osdev
Piraty has quit [Quit: -]
dude12312414 has quit [Remote host closed the connection]
<demindiro> It appears Linux does something special with the PS/2 mouse, which is why it works
xenos1984 has quit [Quit: Leaving.]
bauen1 has quit [Ping timeout: 268 seconds]
Piraty has joined #osdev
Alexthek1d has quit [Quit: Leaving]
smach has quit [Quit: No Ping reply in 180 seconds.]
smach has joined #osdev
matt__ has joined #osdev
oldtopman has joined #osdev
<demindiro> So it appears the mouse pretends to be PS/2 but it's actually a vmmouse that works with hypercall magic
<demindiro> Fun
isaacwoods has joined #osdev
demindiro has quit [Quit: Client closed]
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 268 seconds]
demindiro has joined #osdev
demindiro has quit [Client Quit]
elastic_dog has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
foudfou has quit [Quit: Bye]
dude12312414 has joined #osdev
foudfou has joined #osdev
dude12312414 has quit [Client Quit]
wxwisiasdf has joined #osdev
<wxwisiasdf> Hi, good morning people on developable systems that could be operated in systems developable irc chat
lukflug has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Ping timeout: 268 seconds]
foudfou has quit [Ping timeout: 258 seconds]
foudfou_ has joined #osdev
wxwisiasdf has quit [Ping timeout: 244 seconds]
bauen1 has joined #osdev
xenos1984 has joined #osdev
FreeFull has joined #osdev
<sham1> Hello verbose person
<geist> Hoy
gog has joined #osdev
lukflug has joined #osdev
diamondbond has joined #osdev
epony has quit [Quit: QUIT]
matt__ is now known as freakazoid333
diamondbond has quit [Quit: Leaving]
epony has joined #osdev
terminalpusher has joined #osdev
<kazinsal> dammit. finally out of the good coffee... now I need someone local to me to take a vacation to maui and bring me back a few more pounds of it
wxwisiasdf has joined #osdev
frkzoid has joined #osdev
freakazoid333 has quit [Ping timeout: 248 seconds]
<wxwisiasdf> what if long mode was cheese mode
GeDaMo has quit [Ping timeout: 252 seconds]
GeDaMo has joined #osdev
<gog> it is
<gog> it's delicious
isaacwoods has quit [Quit: WeeChat 3.6]
opal has quit [Remote host closed the connection]
opal has joined #osdev
heat has joined #osdev
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
<mrvn> kazinsal: don't you mean "dammit. Already out of the good cofee..."?
<kazinsal> it lasted longer than I thought it would, but unfortunately, the bag of beans was not bottomless
cowboy8625 has quit [Quit: WeeChat 3.5]
air has joined #osdev
thatcher_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
thatcher_ has joined #osdev
Burgundy has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gog has quit [Read error: Connection reset by peer]
gog` has joined #osdev
gog` is now known as gog
foudfou_ has quit [Ping timeout: 258 seconds]
foudfou has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
justache is now known as justache_test
justache_test is now known as justache
<froggey> I’m getting an exception when writing to the cntp_tval_el0 register, but I can’t tell why
carbonfiber has quit [Quit: Connection closed for inactivity]
<froggey> Happens when running in qemu with hvf enabled on an m1 Mac, but not txt
<froggey> But not under tcg
<froggey> The exception reason is all zeros, not very helpful and the two possible reasons for a fault in the manual don’t seem to apply
<froggey> Anyone run into anything like this?
<froggey> Architectures is arm64
lukflug has quit [Quit: Leaving]
foudfou_ has joined #osdev
foudfou has quit [Ping timeout: 258 seconds]
gxt has quit [Ping timeout: 258 seconds]
<qookie> ESR.EC=0 means more or less illegal operation (write to RO reg, read from WO reg, undefined/unimplemented opcode etc)
<qookie> are you sure that the hypervisor doesn't prohibit you from writing to it?
gxt has joined #osdev
<wxwisiasdf> is there -fexec-charset= for clang?
<heat> what's that
<wxwisiasdf> change encoding of stuffs
<heat> so the encoding of strings?
<wxwisiasdf> yes
<heat> no
<bslsk05> ​reviews.llvm.org: ⚙ D93031 Enable fexec-charset option
<wxwisiasdf> sad :/
<heat> never passed
<heat> why do you need that?
<heat> if you tell me "UCS-2 strings" I will fucking flip
<heat> I will find you, and I will kill you
<wxwisiasdf> ucs2 strings
<heat> ahhhhhhhhhhhhhhhhhhhhhhhhhhhh
<heat> are you macroing all your function calls with *A and *W variants too
<wxwisiasdf> no
<wxwisiasdf> we use constexpr for that
<heat> cringe
<heat> use LPCTSTR
<heat> the long pointer *matters*
<wxwisiasdf> but, but we are not windows
kklimonda has joined #osdev
<heat> yes we are
<heat> that is exactly what we are
<heat> what else would we be
<wxwisiasdf> :(
<heat> uefi? even uefi doesn't have all these shenanigans
<wxwisiasdf> no
<wxwisiasdf> bios, grub2, protected mode
<heat> in fact your EFI firmware has both ANSI strings and UCS-2 strings
<heat> consistency is overrated
<heat> but srsly though why do you need ucs2 strings and why can't you just use L
<wxwisiasdf> okey i don't seriously use UCS2
<wxwisiasdf> i only go as far w EBCDIC 1047
<heat> you can ebc my dic any time
<wxwisiasdf> hehe
<gog> -fshort-wchar you rubes
<wxwisiasdf> & wouldn't use UCS2 anyways since character constants are supposed to be character wide
<wxwisiasdf> and some C standard violations would occour, and then the entire shit becomes ub
<heat> no
<wxwisiasdf> or were they int wide?
<gog> nah UCS2 is 16 bits
<gog> fixed
<heat> fshort-wchar + L will give you a short-sized wchar_t
<wxwisiasdf> hmm
<heat> but that has nothing to do with normal chars
<heat> it will not affect them in any way, as is sane
<wxwisiasdf> well
<wxwisiasdf> -fexec-charset=UCS2 makes character constants become multibyte
<gog> yes that's what i'm saying
<heat> that seems incompatible with real life
<heat> your char cant both be 1-sized and short-sized
<heat> (in normal platforms)
<wxwisiasdf> gcc allows it, hence my previous "i wouldn't use it" statment
<wxwisiasdf> it also allows UTF32
<heat> it does????
<wxwisiasdf> yes
<heat> wtf happens to sizeof()?
<wxwisiasdf> goes wild
<wxwisiasdf> entire shit goes UB
<gog> fucking
<gog> this is language abuse
nyah has quit [Ping timeout: 268 seconds]
<heat> lets delete gcc and use msvc
<heat> sounds good yes??
<wxwisiasdf> PE kernel time
<gog> PE is easier to reloc anyway
<wxwisiasdf> really?
<heat> you're joking but PE kernel sounds easy
<heat> you just need to objcopy it to something saner
<heat> wxwisiasdf, no
<wxwisiasdf> lol
<wxwisiasdf> ah okay
<heat> PE is batshit crazy
<gog> :P
selene_ has joined #osdev
<wxwisiasdf> why does windows always have the crazy formats
<heat> uefi's PE loader is super unmaintainable and horrible and fugly and buggy and exploitable
<gog> backwards compatibility
<heat> thank fuck you didn't go forwards with the gsoc
selene_ has quit [Client Quit]
<gog> yeah i'd probably be a wreck rn trying to finish it :P
<heat> tbf it would be crazy useful
<heat> but probably not in the state PE support is in right now
<gog> yeh but i made way more money being a phone bitch
<heat> but fun :(
<froggey> qookie: maybe... yeah. hmm, I'm using the physical timer registers, maybe I should be using the virtual ones
<gog> anyhow though, PE is just an extended COFF with a dos MZ stub saying "you can't use this .exe in DOS"
<wxwisiasdf> hehe
<heat> because dos is relevant
<gog> that's why it's crazy
<gog> that's also why DLL's are prelinked
<gog> "dynamic" linking
<heat> are they?
<heat> what happens if two dlls conflict?
<gog> relocations
<heat> oh ok
<heat> that doesn't seem horrible then
<gog> it's got benefits and drawbacks
<heat> prelinking to save up on startup time isn't horrible
<kazinsal> yeah they're still relocatable, they just all get pre-linked to a "preferred" address
<gog> yeah
<heat> although aslr
<kazinsal> in some big fancy applications this is REALLY cool because you can predefine your preferred addresses and just touch your modules without needing to ask Windows to get you a handle to one of your modules
<kazinsal> we used this to great advantage in the Freelancer modding community because all the various DLLs making up the game engine always loaded at the same preferred addresses
<froggey> oh, that seems to work
gxt has quit [Read error: Connection reset by peer]
<wxwisiasdf> does the kernel itself load the DLLs? or is it like linux where an ld.so takes care of the dynamicity?
gxt has joined #osdev
<kazinsal> it's handled by kernel32.dll which is the user-mode interface to the kernel
<kazinsal> so it maaay make native kernel API calls but it may also do it in userspace wherever possible
<wxwisiasdf> hmm
<kazinsal> just grabbed my copy of windows internals, the image loader is in userspace
<heat> kazinsal, how is kernel32.dll loaded?
<kazinsal> kernel32 is just the implementation of win32 interfaces to system calls
<heat> it's like microkernels' program loader problem, but everything is confusing and 10x more complicated
<kazinsal> ntdll is the user mode native API to system calls
<heat> yes but who loads that if the loader is in userspace
<gog> who loads the loader
<kazinsal> there's an initial loader that basically brings up the windows equivalent of init
<kazinsal> and that's load-time dynamically linked against ntdll
<kazinsal> so ntdll is always present
<kazinsal> when it does its own first CreateProcess call the ntdll loader is used and basically references itself for the new process's load-time dynamic linking to ntdll
<kazinsal> it's fucking wacky and wonderful
<gog> i love microkernels
<kazinsal> like if every process got a free reference to ld.so just for existing
<gog> wouldnð
<gog> wouldn't that make it like a vdso
<kazinsal> kinda yeah
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
<kazinsal> if you have the money (or the expense account) I recommend picking up hard copies of Windows Internals 7th Edition
<netbsduser> i've read excerpts of the older edition (the one covering Win2k)
<netbsduser> very useful
<kazinsal> I think they're on sale right now because back to school
<kazinsal> totally worth owning so you can walk over to your bookshelf during a meeting where some contractor is arguing about shit he doesn't really know about and drop down 2500 pages of paperback and go "NOW LISTEN HERE YOU LITTLE SHIT"
terminalpusher has quit [Remote host closed the connection]
<moon-child> soo
<moon-child> did we ever get an answer on 'why ucs2'?
<moon-child> because ... ...
<gog> why not
<gog> ¯\_(ツ)_/¯
<kazinsal> because NT develpoment started in 1989 and UTF-16 was defined in 1996
<moon-child> I mean, why wxwisiasdf wants it when they are presumably not developing windows nt
<klange> There's only three reasons to intentionally choose to use UCS-2: Laziness, a mistaken belief that the only things beyond the BMP are emoji and hating emoji, and racism.
<wxwisiasdf> wha
<zid> ucs2 is the ebcdic of 2020
<zid> something you have to write programs around its existance but really don't wanna actually use for anything
carbonfiber has joined #osdev