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
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 268 seconds]
cooligans has joined #osdev
cooligans has quit [Client Quit]
[itchyjunk] has joined #osdev
ZetItUp has joined #osdev
cooligans has joined #osdev
cooligans has quit [Quit: Lost terminal]
elderK has quit [Quit: Connection closed for inactivity]
elderK has joined #osdev
kajiryoji has quit [Quit: ZNC 1.8.2 - https://znc.in]
kajiryoji has joined #osdev
ElectronApps has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<vin> If there is a processor chip which supports no timmer interrupt but has 1000 cores per die (hypothetical) so appliiications can have dedicated cores specified to them rather than being time shared. A spin lock would do well becuase there will be no repeated cost of context switch or provides low latency response time. But why would a spin lock not do well on this hypothetical design?
<vin> /s/or/and/g
tacco has quit [Remote host closed the connection]
<MelMalik> A spin lock would create heat.
<MelMalik> You need a cold lock to sleep the core, and an interrupt to wake it up.
<MelMalik> Also, consumes power
<vin> So it's just heat and power?
<clever> in such a cpu design, upon failing a spinlock in userland, i would issue a futex syscall
<clever> which would put the thread to sleep, and wait for an IPI signaling release of the lock
<clever> that also relies on an atomic increment opcode, to let the other end know you want to be woken up
<clever> my understanding of that api, is that userland will try to get the lock with atomic ops, and use futex to block upon failure
<vin> So when would a spin lock fail? It keeps waiting on the resource until availaible right
<clever> well, it would be less of a spinlock then
<clever> more of a lock_try function
<clever> but i have seen spinlocks that include a try function, for when you dont want to spin
<vin> yea more like busy wait. So spin lock just tries a few iterations and sleeps if resource is not acquired?
<clever> yeah
<clever> arm and haskell also have a different approach to things
<clever> with arm, you get a token from the cpu core, that says you own a given addr
<vin> oh then power and temprature is not an issue with spin lock if it's only a few iterations
<clever> then you do load/compute against the value
<clever> then you do a "store only if i still own it" opcode
<clever> arm never actually stalls or says no when you fail the lock
<clever> it will instead say no, when you try to write the value back
ahlk has quit [Read error: Connection reset by peer]
<clever> so if your read/modify/write contested with another core, it becomes a read/modify/abort
<clever> and the routines around that, are responsible for trying again
ahlk has joined #osdev
<clever> haskell has a similar mechanism in STM, where you read a sequence-counter for every variable you read as you compute an arbitrarily complex operation
<clever> and every write, just stores them into a temp buffer
<clever> then during commit, you grab a global mutex, check the sequence counters, and maybe commit
<vin> So why would a failed spin lock do a syscall?
<clever> so you can have the scheduler yield control to another task, or drop into a low-power state
<clever> until somebody else releases the lock
<vin> but in this chip processors aren't time shared so does it make sense to yeild control to another task?
<vin> each thread had a dedicated processor
<clever> you can still drop into a low-power state
<clever> where you basically just shut off the clock for the core, and halt all state changes
<vin> So the kernel itself is running on a bunch of dedicated cores where the user app communicate to it via some call api.
<clever> in such a system, i would have the kernel and userland on the same core
<clever> when you issue a syscall, the core just changes into kernel mode
<clever> and while in kernel mode, it has the power to sleep until an irq happens
<vin> can't clever, they can't be time shared because there is no timmer interrupt
<clever> you dont need a timer interrupt to share it
<clever> windows 3.11 never used timer interrupts for time-sharing
<clever> it was 100% volentary
<vin> I see.
<clever> a thread only looses cpu when it chooses to give control back to the kernel
<clever> and the same can be said about any thread on a real-time scheduler
<vin> So one issue I can think of from our discussion is that a spin lock that can't be interrupted can end up being stuck on the core forever without making any progress and no way to recover it.
<clever> yeah, so you would want to avoid using such locks
<MelMalik> personally i would have interrupts on such a cpu
<vin> haha yes
srjek has quit [Ping timeout: 268 seconds]
<MelMalik> because not having interrupts means you can't reliably schedule more than, eh, 700 tasks at once
<vin> Yes, this was just me thinking about concepts in different settings, not practical in any sense.
[itchyjunk] has quit [Read error: Connection reset by peer]
<geist> if you wanted to build such a design you'd probably do some sort of hardware event style yield
<geist> kinda like ARMs WFE/SEV but a bit smarter
<geist> then your spinlocks dont spin, they check and then go into a sleep waiting for another core to signal the same address
dude12312414 has joined #osdev
eryjus has joined #osdev
<clever> geist: yeah, if you had a way to target the SEV, you could do that far more efficiently
<clever> how does SEV operate, when you have multiple guests under an EL2 hypervisor for example?
<geist> arm64 actually does, it's implicit when you store to the address you had previously acquired an exclusive line to
dude12312414 has quit [Client Quit]
_eryjus has quit [Ping timeout: 260 seconds]
<geist> caveats being that the size of the observation area is relatively large and defined per core
<geist> though i think it's always a cache line practically speaking
<geist> since that's really how it works: the cpu grabs the line exclusively and waits for another core to write to it, thus losing the exclusiveity
<geist> that triggers an explicit local SEV to the core
<clever> yeah, i read somewhere, that the load/store exclusive, expands the region up to a whole cache line
<clever> but the api only garantees for the host-size word you targeted
<geist> basically
<clever> can the EL2 api entirely hide that your even running under a hypervisor?
<clever> i can see how you might emulate all of the hw in a board, but masking any artifacts of the emulation would be tricky
ElectronApps has quit [Remote host closed the connection]
<geist> there's some bits somewhere that control the scope of SEV/WFe i think
<geist> like, wiether or not it's restricted to a single guest or not
<clever> ahhh, thats what i was thinking of
bgs has quit [Ping timeout: 264 seconds]
bgs has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
mahmutov has quit [Ping timeout: 268 seconds]
Oli has quit [Quit: leaving]
ElectronApps has joined #osdev
__xor is now known as _xor
<nur> the latest sigops newsletter I got is about graph computing
<nur> I wonder how that fits into OS research
<klange> sigops isn't actually about operating systems and I'm not sure it ever was
<klange> it's about "distributed systems"
<vin> https://www.youtube.com/watch?v=36myc8wQhLo OSDI has only 6% of paper related to oeprating systems. One of the good keynotes
<bslsk05> ​'USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware' by USENIX (01:06:19)
<vin> There are hardly any new OS designs and iimplementations being published in peer-reviewed avenues.
<kazinsal> yeah, new designs are pretty rare because they're universally either not useful for anything other than as a tech demonstrator for "if we had 40x the computing power and quantum coprocessors this would be disruptive!" or something so inventive it wouldn't have any papers written about it until after it received a commercial release
<nur> this didn't use to be the case
<vin> kazinsal: in the talk Timothy argues the importance of OS desgined for modern SOCs forget quantum computers.
<vin> what are your thoughts geist? I am interested in learning what motiviated you to start Fuchsia?
<geist> well, i didn't start it, i was just working at the time
<geist> more like being in the right place at the right time
<nur> Tim Roscoe's talk reminded me of Rob Pike's "systems research is irrelevant" waaay back in 2000
<nur> and many of the same things are still true
<nur> hardware has changed/software is stagnant
<vin> Oh I thought you started Zircon, sorry!
<geist> well, i was there at the beginning but i didn't personally start it
<geist> certainly dont have that kinda clout :)
<vin> geist: Nevertheless, what was the motivation for the project? Any *specific* problems google was looking to solve?
<geist> sadly those are precisely the things we aren't allowed to talk about
<geist> i mean having a modern capability based design, etc is fairly obvious
<geist> ie, build something from scratch with more modern security and compartmentalization from day 1
<vin> No worries :) I expect to see it in OSDI/SOSP 4/5 years from now.
<geist> hmm, whta are those?
<nur> OS conferences I guess
<vin> Yes
<kazinsal> OSDI is the usenix OS conference iirc
<geist> ah yeah
<nur> SOSP is the ACM one
<geist> probably worth doing some talks for that
<geist> reminds me there was a fairly good paper written about the fuchsia security model recently that i was reading that was fairly good
<geist> a bit inaccurate with the kernel but it was mostly talking about the component model in user space
<vin> Most of google's work has been published after a while in these conferences. Like GFS, Borg, Map reduce, Colossus, etc
<geist> it's a pretty good paper, not written by us so there are some inaccuracies, but it has some pretty good overview
<vin> Oh that's nice, I will give it a read. Thanks!
<nur> who are the authors
<klange> I've thought about doing a paper.
<geist> looks like some guys from University of Genoa
<klange> I thought about it more when I was still a university student... but ToaruOS wasn't really worth talking about back then.
<nur> they cited some blogs and even wikipedia but not my article on fuschia *grump*
ElectronApps has quit [Remote host closed the connection]
<geist> nur: oh that's right you wrote one too huh?
<nur> and all the time I spent questioning poor geist :)
<geist> hah
<nur> lessee if I can dig it up
<bslsk05> ​lwn.net: Fuchsia: a new operating system [LWN.net]
<nur> some of it already outdated :-|
<vin> klange: maybe you should! A talk at strangeloop would be a good start.
<nur> like "magenta" instead of "zircon"
<geist> hehyeah
<geist> long live magenta!
<klange> I did do a talk once. One of my previous employers did regular internal free-topic tech talk sessions and I did a whole deep dive "What happens when..." thing.
<klange> I need to redo that slide deck, since that was 2015 when I was still using newlib.
<Mutabah> You had a video of that, right?
<klange> Yeah should still be up on my YouTube but might be unlisted just because I'm terribly embrassed by it.
<geist> yeah i did exactly one talk in front of 1000 people and i have to say it was a bit terrifying
<klange> Giving that talk is actually what pushed me to do the NIH thing.
<geist> surprisingly less so leading up to it, i thought i had it nailed
<geist> but i started to lock up half way through it
<geist> but thankfully someone else was co-presenting and could kick me along
<klange> Because one of my coworkers - who had previously worked on NT before joining us - badgered me about newlib and whatnot.
<klange> ToaruOS is 100% built on spite.
<geist> so. bummer that happened, since it kinda crushed my confidence in things like that in the future
<kazinsal> yeah, I've done a couple internal presentations on like hypervisor architecture and stuff but only to the six or seven people in the company who find that kind of deep nerd stuff interesting
<geist> yah i can talk to folks i know without much trouble
<kazinsal> eventually I'd like to end up with an OS project I can give a talk about, but I think I also said a few years ago that I was aiming to have a release out by now, and well... ;)
<geist> yeah same
<kazinsal> I look forward to having something to give a talk about in 2028
<nur> me too, but then "getting a real job" got in the way
<nur> I now write customer service chatbots for Dell :-|
<zid> Finally someone who can fix my printer
<kazinsal> entertainingly I got my current job in part because of my earlier osdev stuff. not because it's relevant to my job, but because it was so bafflingly nerdy and clearly a tech passion project
<nur> zid, technically I would write you a bot that could forward you to someone who can fix your printer
<kazinsal> and also my director and I are both guitar nerds so that helped
<klange> I have a guitar now.
<nur> although can printers be fixed really? I feel they're cursed
<nur> I wonder what writing a printer driver feels like
<zid> printers are disposable items built around ink cartridges
<klange> This would not really be news except it was a preorder for a collab guitar that I placed nearly a year ago and it was delayed so the fact that it _finally_ arrived...
<nur> I guess I'll find out once I get to the "printer" part of the osdev exercise
<klange> Printer drivers are a bit of a misnomer. It's almost all document conversion, either to postscript or PDF.
<zid> If you only deal with networky printers that talk postscript I'm sure it's easy, it's the 'winmodem' printers that never work
<nur> cursed I say
<zid> where the drivers have to control the motors or whatever
<klange> And then you either blat it out over some serial interface or throw it at an HTTP endpoint.
<kazinsal> see, that's why I'm writing a network operating system. no one ever expects their router to have printer drivers ;)
<klange> I'm not aware of any of those that still exist. Everything is a PostScript or PDF printer these days, and CUPS profiles almost entirely consist of names for knobs.
<zid> In other words, only ever do osdev targetting precisely the easiest era of the tech you're talking about
<klange> This is why I target VMs. No one is going to print from their VM!
<nur> well, to a network printer :)
ravan has quit [Ping timeout: 260 seconds]
MarchHare has quit [Quit: Leaving]
pretty_dumm_guy has joined #osdev
C-Man has quit [Ping timeout: 268 seconds]
ElectronApps has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
bokfink has joined #osdev
wolfshappen has quit [Ping timeout: 260 seconds]
wolfshappen_ has joined #osdev
GeDaMo has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
Arthuria has joined #osdev
psychopacket has joined #osdev
psychopacket has quit [Quit: Textual IRC Client: www.textualapp.com]
psychopacket has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by guest2795!~Arthuria@user/arthuria))]
Arthuria has joined #osdev
<froggey> kazinsal: given that a whole lot of routers ship linux I'd be entirely unsurprised if some of them included printer drivers
Oli has joined #osdev
[itchyjunk] has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
adder has quit [Ping timeout: 245 seconds]
dennis95 has joined #osdev
<kingoffrance> bbbbbut, but...glass ttys! ttys on fire! display postscript! its printers all the way down!
* kingoffrance stops injecting meta
<kingoffrance> some printers just happen to have, say, a keyboard and mouse to assist driving them
<kingoffrance> REPL!
makersmasher has quit [Remote host closed the connection]
CryptoDavid has joined #osdev
adder has joined #osdev
srjek has joined #osdev
ahalaney has joined #osdev
<kingoffrance> https://en.wikipedia.org/wiki/IPO_model thats what i was looking for
<bslsk05> ​en.wikipedia.org: IPO model - Wikipedia
<kingoffrance> Many introductory programming and systems analysis texts introduce this as the most basic structure for describing a process.
dormito has joined #osdev
dormito has quit [Ping timeout: 268 seconds]
dormito has joined #osdev
eau has quit [Quit: bleh!]
heat has joined #osdev
makersmasher has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
eau has joined #osdev
bokfink has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
dormito has quit [Ping timeout: 268 seconds]
dormito has joined #osdev
ElectronApps has quit [Remote host closed the connection]
theruran has quit [Quit: Connection closed for inactivity]
pretty_dumm_guy has joined #osdev
FreeFull has joined #osdev
mahmutov has joined #osdev
air has quit [Ping timeout: 245 seconds]
Oli has quit [Quit: Lost terminal]
CryptoDavid has quit [Quit: Connection closed for inactivity]
Oli has joined #osdev
brynet has quit [Quit: leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
pretty_dumm_guy has joined #osdev
brynet has joined #osdev
crm has quit [Quit: Leaving]
dormito has quit [Ping timeout: 268 seconds]
zhiayang has quit [Ping timeout: 245 seconds]
sprock has quit [Ping timeout: 260 seconds]
dormito has joined #osdev
dormito10 has joined #osdev
hbag has quit [Remote host closed the connection]
dormito has quit [Ping timeout: 260 seconds]
dormito has joined #osdev
zhiayang has joined #osdev
dormito10 has quit [Ping timeout: 268 seconds]
dude12312414 has joined #osdev
ravan has joined #osdev
dennis95 has quit [Quit: Leaving]
adder`` has joined #osdev
eryjus has quit [Remote host closed the connection]
adder has quit [Remote host closed the connection]
eryjus has joined #osdev
dormito has quit [Read error: Connection reset by peer]
dormito has joined #osdev
darkstardevx has quit [Ping timeout: 245 seconds]
shikhin has quit [Quit: Quittin'.]
shikhin has joined #osdev
darkstardevx has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
tacco has joined #osdev
eremitah has joined #osdev
eremitah has quit [Quit: quit.]
mjg has quit [Ping timeout: 268 seconds]
sprock has joined #osdev
heat has quit [Ping timeout: 260 seconds]
wootehfoot has joined #osdev
jess has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
ss4 has joined #osdev
wootehfoot has quit [Ping timeout: 260 seconds]
Arthuria has quit [Ping timeout: 268 seconds]
GeDaMo has quit [Remote host closed the connection]
k0valski18 has quit [Quit: Peace out !]
srjek has joined #osdev
unmanbearpig has joined #osdev
<sham1> Good evening to all
* Arsen waves
ss4 has quit [Read error: Connection reset by peer]
noocsharp has joined #osdev
heat has joined #osdev
sprock has quit [Ping timeout: 264 seconds]
<klange> Updated my screenfetch-alike: https://klange.dev/s/sysinfo-updated.png
dormito has joined #osdev
mctpyt has joined #osdev
air has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
pretty_dumm_guy has joined #osdev
_eryjus has joined #osdev
eryjus has quit [Read error: Connection reset by peer]
eryjus has joined #osdev
ahalaney has quit [Quit: Leaving]
_eryjus has quit [Ping timeout: 264 seconds]
MelMalik is now known as AmyMalik
mjg has joined #osdev
vdamewood has joined #osdev
[itchyjunk] has joined #osdev
heat has quit [Remote host closed the connection]
niedzejkob[m] has joined #osdev
<niedzejkob[m]> TIL, from reading the sectorlisp code, that apparently BIOSes load the MBR at 0x600 too. Is this described anywhere?
sprock has joined #osdev
<kazinsal> never seen that behaviour before
<zid> isn't that inside the IVT
<zid> hmm I guess that might stop at 0x400 depending on whether I can count or not
<zid> It's possible that's the disk buffer location some random bios uses, and copies it to 7c00 before it runs it after checking the tag and stuff I guess
<clever> i have heard that some bios will jump to something like 0:7c00, while others jump to 7c0:0 ? something like that
<clever> and it can screw with programs that assume the segment reg when doing absolute jumps
<zid> they're the same linear address
<clever> exactly
<zid> 0x600 is definitely not
<clever> but if you jump to CS:10, you wont get the same linear addr
<clever> because the CS differs
<kazinsal> anything since like, the late 90s shouuuuuuuld use 0000:7C00
cooligans has joined #osdev
mctpyt has quit [Ping timeout: 260 seconds]
<zid> My 100% top guess is that it's a disk buffer used by possibly some common early bios
<zid> it definitely isn't standard
<kazinsal> CS=0 IP=7C00 is specifically defined in the BIOS Boot Specification from 1996 iirc
<kazinsal> but nothing about any other addresses
<zid> yep found it in a patent
<kazinsal> aha, it looks like in ye olde days MS-DOS would relocate its MBR to 0000:0600
cooligans has quit [Remote host closed the connection]
<zid> not quite sure who he is other than a guy with a couple of patents on bootsectors
<clever> i had at least one machine that was unable to boot random floppies
<clever> i suspect it was using the wrong CS for running the MBR
<moon-child> bet he made bank on that
<zid> I always load cs manually because I'd heard in the wild some biosen like that existed
<kazinsal> looks like it's assigned to Phoenix Technologies
<kazinsal> and expired in 2018
<clever> zid: ive also seen code in grub, that will do a far-jump to 0:7c10 for example, to fix that
<zid> yep
<zid> might as well, if you can spare the couple of bytes
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 268 seconds]
dude12312414 has quit [Ping timeout: 276 seconds]
dude12312414 has joined #osdev
mctpyt has joined #osdev
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
FreeFull has quit []