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
pony is now known as as
as is now known as pony
freakazoid333 has joined #osdev
riposte has joined #osdev
dutch has joined #osdev
ephemer0l has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<klange> geist: I just can't justify a ban for being overly annoying :\
<geist> fair enough
<kazinsal> imho "overly annoying" is a euphemistic way of saying "generally disruptive"
<kazinsal> I'll be honest, I'm pretty sure I've never actually seen geist get *angry* at someone in this channel until today
<geist> oh i do sometimes
<kazinsal> that's the kind of zen buddhist monk slapping someone tipping point that makes me wonder "maybe something needs to be done"
<geist> though not as much lately, and i wasn't so much angry as maybe if i went all caps he'd listen
ephemer0l has joined #osdev
iorem has joined #osdev
zoey has quit [Quit: Leaving]
freakazoid333 has quit [Read error: Connection reset by peer]
tacco has quit []
<gog> mostly i'd just like to see an end to the go-rounds about fairly basic concepts that he clearly thorougly misunderstands
<gog> and the conversations that start feeling like markov chains
freakazoid333 has joined #osdev
gog has quit [Ping timeout: 240 seconds]
pphs has quit [Ping timeout: 252 seconds]
sts-q has quit [Ping timeout: 272 seconds]
sts-q has joined #osdev
nyah has quit [Quit: leaving]
Celelibi has quit [Quit: Quitte]
diamondbond has joined #osdev
Celelibi has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
Izem has joined #osdev
freakazoid333 has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
geist has quit [Ping timeout: 255 seconds]
geist has joined #osdev
Izem has quit [Quit: Izem]
Izem has joined #osdev
diamondbond has quit [Ping timeout: 258 seconds]
Izem has quit [Quit: Izem]
freakazoid333 has joined #osdev
Bonstra has quit [*.net *.split]
zhiayang has quit [*.net *.split]
acidx has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
stux|away has quit [*.net *.split]
Darksecond has quit [*.net *.split]
sauce has quit [*.net *.split]
danieldg has quit [*.net *.split]
alexander has quit [*.net *.split]
pounce has quit [*.net *.split]
bslsk05 has quit [*.net *.split]
nickster has quit [*.net *.split]
sauce has joined #osdev
acidx has joined #osdev
pounce has joined #osdev
alexander_ has joined #osdev
zhiayang_ has joined #osdev
nickster has joined #osdev
bslsk05 has joined #osdev
Bitweasil has joined #osdev
zhiayang_ is now known as zhiayang
GeDaMo has joined #osdev
gorgonical has joined #osdev
<klange> Eater's got me actually reading USB specs and starting to work on an xHCI driver...
<klange> I have an ExpressCard xHCI two-part card in the T410, so should be able to test on hardware against some HID devices, once I get things working enough in QEMU.
Izem has joined #osdev
<geist> klange: yeah xhci looks at least educational
GeDaMo has quit [Ping timeout: 265 seconds]
ElectronApps has joined #osdev
GeDaMo has joined #osdev
tenshi has joined #osdev
Darksecond has joined #osdev
<geist> oooh eater did another video, i see it now
asymptotically has joined #osdev
paulusASol has quit [Quit: Bridge terminating on SIGTERM]
happy-dude has quit [Quit: Bridge terminating on SIGTERM]
hgoel[m] has quit [Quit: Bridge terminating on SIGTERM]
Mutabah has quit [Ping timeout: 258 seconds]
Mutabah has joined #osdev
paulusASol has joined #osdev
<nur> video?
hgoel[m] has joined #osdev
happy-dude has joined #osdev
<geist> youtube
<nur> have a link?
<geist> not off the top of my head no
<geist> go to youtube and search for ben eater
<nur> ah gotcha
<nur> I was unfamiliar with "eater"
<geist> ah yeah. ben eater. he's pretty fun to watch do TTL logic stuff
<nur> and I just smashed that subscribe button
<geist> but recently he started looking at USB with a scope and decoding it. neat to see it visualized
<nur> I've been doing this awhile but I only have a vague idea of how to talk to hardware
<nur> I know that the hardware itself helps tell you how to talk to it, via things like uefi, acpi, and devicetree
<nur> and pci
<nur> but again, my understanding of that is still hazy
<j`ey> uefi, acpi, dt is software, that tells you how to talk to the harrdware
<nur> right
<nur> and it gives you stuff like... addresses right?
<j`ey> yeah
<nur> I see
<nur> and that's about it right
<nur> the hardware drivers need to use the addresses that the firmware gives it, and they also need to know how to talk to the device right
<j`ey> yep
<j`ey> so they have a driver for device X, and the firmware says device X is at address A
<nur> it's just that whenever a new thing comes out, OS's like Linux seem to already work on it like all the drivers "know" how to talk to it already.
<nur> like, a new SoC
<nur> or a new virtual machine type thing from Amazon
<j`ey> if there's no new device drivers, yeah
<nur> so even if there's a new CPU like say, M1, as long as the architecture is supported by Linux it should just "work"?
<geist> yah lots of times linux doesn't just work, but some vendor did some work prior to releasing it
<nur> aha
<geist> the architecture part of it, yes
<geist> but that's jsut one part
<nur> there are vendors and there are like hackerpeoples who go "woo look we got Linux on this thing"
<j`ey> nur: well the m1 is a bad example :P
<geist> it's a big part. and one that we spend a lot of time here, but a well specced architecture (ARM is one of them) then a well designed ARM core by any vendor is pretty easy to port to
<nur> that's always impressed me
<geist> the cpu part
<geist> M1 however as an SOC is highly highly nonstandard
<geist> puts the broadcomm stuff that i always complain about to shame
<nur> okay bad example since Apple locks down their laptops
<nur> maybe a better example is graviton
<geist> possibly another ad example. because that's a cpu that amazon makes for their own purposes and also probably doesn't fully document
<geist> a SOC
<j`ey> CPU is only one part really, the linux code will run.. but that doesnt mean it has any drivers!
<geist> right
<nur> so how does it...work
MarchHare has quit [Ping timeout: 252 seconds]
<j`ey> nur: they add drivers!
<geist> how does what work?
<nur> "they" being Amazon?
<geist> yes
<nur> j`ey, how do distros like redhat etc.
<geist> one does not run redhat on a graviton
<geist> no one does but amazon
<nur> ah
<geist> you can run redhat on a virtual machine hosted on a graviton
<nur> but one imagines those drivers need to go into Linux as open source
<j`ey> on aws youre getting a vm
<geist> but that's a completely different kettle of fish
<geist> they probably do
<geist> but yuo can't get ahold of a graviton so it's kinda moot
<nur> right
<geist> though that being said it's not that exotic most likely, just anther server arm soc
<geist> that's fairly standardized now
<nur> so you couldn't like, run a custom OS on an AWS hosted VM
freakazoid333 has quit [Read error: Connection reset by peer]
<nur> or maybe you can I dunno
<geist> sure you can. again a hosted VM on an arm core != running on the native core
<j`ey> you can, because the VM will be "standard"
<geist> totwlly differnet thing
<nur> what is "standard"
<geist> right, the VM exposes a single virtual machine, including fake devices, etc
<geist> whartever amazno declares is standard
<nur> and we have drivers for those "fake devices" already
<geist> right, because amazon adds them to upstream
<nur> got it
<geist> or it's a standad piece of hardware, like say, AHCI or XHCI
<nur> right
<geist> (though amazon in particular i think has their own virtual devices they like to expose, which are unique to amazon)
<geist> but they upstream drivers for those for sure, so others can run linux distros/etc on their VMs
<klange> I'll stick to targeting QEMU and the old laptop next to me.
sortie has joined #osdev
<geist> whatever the *physical* device looks like from a driver/device point of view is a different thing, but you wont see that unless amazon gives you the ability to run 'bare metal'
<geist> maybe they will, maybe they already do. there are bare metal x86 solutions in some of thecloud providers
<sortie> Mornin'
<sortie> It is vacay time for me \o/
<geist> woot. last week was vacay for me
<sortie> I got myself three weeks (barely used any vacation this year)
<nur> as I understand it Qemu has a set of devices that resemble some physical real world devices
<geist> that's right
<j`ey> nur: yes and some virtio devices, which are not real world
<geist> and some fake devices (like everything virtio) which are intended to be more easily emulatable
<nur> and even if you specify nothing in the command prompt qemu will emulate some default one for you
<nur> I was only vaguely aware of virtio
<nur> but now all the pieces are beginning to make sense
<geist> right note that qemu for any given architecutre just has a define machine to emulate. on x86 it's almost always a PC of some type
<geist> sice for the most part the PC 'machine' is the only real interesting thing that uses x86
<geist> but on other arches, there's a --machine switch which tells qemu which hardware to pretend to be
<geist> (and on x86 there are valid things in --machine, but mostly jsut variants of PC)
Izem has quit [Quit: Izem]
<nur> if you leave out --machine when running say arm64 what does it default to
<geist> i'm ntosure it does
<geist> i think it may tell you to select one
<geist> since there's no real reasonable default
<klange> qemu-system-aarch64: No machine specified, and there is no default
<geist> anyway that's really how most of the world work, think of x86 and PC as sort of an exception to the rule
<geist> it's a case where arch (x86) == machine (IBM PC clone of some type)
<nur> klange, does it give you an error or something?
<klange> It literally prints that^
<geist> so lots of times when we talk about things like PIC and PIT and bios and whatnot those are really artifacts of the PC platform, not x86
<nur> oh
<nur> oh I see
<nur> ahhh
<geist> but just so happens that pretty much all x86s (except for some embedded stuff) are just a variant of a PC
<nur> I'd like to take a moment to appreciate how educational all this has been. I am a total newbie even though I've been trying to learn this for years. So thanks everyone. :)
<geist> sure!
<j`ey> :3
<klange> While I was setting up my gcc 10 and accompanying binutils I noticed that some time in the last decade the -pc- triplet component has fallen out of favor
<geist> it's always rewarding when you hear the light over someones head blink on through the internet
<nur> lol mine's pretty dim so I appreciate everyone's patience. This is a cool community :)
* nur thinks irc is better for his education than 90% of his undergraduate degree in CS
<geist> but but not enough constant memes!
<klange> My degree allowed me to get a visa for the country I live in, so it was worthwhile for that.
<sortie> Honestly I sort of consider osdev my honorary masters degree
<sortie> Totally ruined my studies but learned so much
<nur> I suppose a paper thing is useful in a way
<nur> but man did my undergrad degree suck in a lot of places
<nur> the stories I could tell around a campfire
<moon-child> klange: I still have x86_64-pc-linux-gnu
<moon-child> v 11 or so
<nur> my network class lectures were100% useless as they were taught by an unqualified guy. I learned by reading the textbook, Andrew Tanenbaum's Computer Networks
<nur> years later I met Tanenbaum and thanked him for his wonderful books and he smiled politely but had a look on his face that said "why do I keep running into these nerds?"
<moon-child> haha
<klange> My last year of high school, the AP CS teacher (she also taught several math courses) was cleaning out a cabinet. I got a copy of Andy's Modern Operating Systems. I think it was a first edition from '92 - so quite old at the time! - but still very inspiring.
chartreuse has quit [Ping timeout: 252 seconds]
<klange> The spambots on the forum are getting smarter... and more pervasive. And chase still has not replied to my emails. I hope he's okay.
<geist> omg, i was just piddling with trying out a windows irc client
<geist> and i typed in irc.libera.net for the server. wanna guess what that actually points to?
<klange> freenode
<geist> whiskey tango foxtrot
<klange> you're a bit late on that one
<geist> that is naaaaasty
<j`ey> geist: just more scummy behaviour!
<klange> nothing that happens in relation to freenode surprises me any more
<immibis> IIRC that was done by some troll, not freenode themselves
<j`ey> immibis: it has freenodes cert
<immibis> j`ey: yes because that's how this works. You connect to freenode's IP, the server will give you freenode's cert.
<j`ey> hm
<geist> right, was about to point out to be totally fair it could have been some other asshoel yeah
<immibis> unless SNI is involved, the server doesn't know you were trying to connect to a different domain name
z_is_stimky has quit [Read error: Connection reset by peer]
<immibis> you can point whatever domain you like to someone else's IP address
z_is_stimky_ has joined #osdev
<klange> your client does, though
<immibis> your client doesn't know it's actually connected to freenode. Unless it checks the cert. I have no idea why IRC is okay with self-signed certs
<immibis> and unverified certs in general
<clever> SNI is the client informing the server about what domain's cert you want, after you connect
<j`ey> different registra, so maybe
<immibis> if the server is only intended for one domain it won't look at SNI
<geist> yah if i looking into the libera.net domain it doesn't necessarily seem to beregistered by freenode
<immibis> apparently this DRAM init thing requires a bunch of precomputed parameters that I can't find a copy of. Maybe I should just use bite the bullet and use U-Boot instead
<sortie> I believe the IRC protocol has a redirect support
<geist> C/O LIBERA.NET which is a totally different one than the freenode.net address
<immibis> irc.freenode.chat is also a completely different network I believe
<geist> well anyway. i fell for that one for a while. laaaame
tacco has joined #osdev
Bonstra has joined #osdev
asymptotically has quit [Quit: Leaving]
scaleww has joined #osdev
<immibis> well i pulled in a whole bunch of code from u-boot including their calibration data and now I can access DRAM
<clever> nice
<clever> always helps if somebody already has open source for dram init
<j`ey> immibis: do you have the serial port working?
<immibis> j`ey: I don't have the hardware for the serial port; I theoretically have the hardware to make the hardware for the serial port, stored in a box somewhere, but I don't particularly want to find where it is
<j`ey> oh
<j`ey> fair. that would be super useful tho :P
<immibis> clever: I thought maybe I could run the blob that u-boot got their information from, but i can't really find that blob; I found the *code* part of the blob but it requires calibration data as input
<immibis> since i don't particularly care about figuring out *why* certain registers have certain values (which u-boot seems to have done some work on); just as long as it works
<immibis> but that wasn't easier because the blob didn't include the needed data
<clever> immibis: for the rpi0 to rpi3 lineup, i have source that was RE'd from blobs, and i'm mostly figuring it out to be able to extend it
<immibis> this is a different chip
<immibis> from a different manufacturer
<clever> for example, ive figured out how the clock divisor relates to the ddr2 freq, so i can now overclock the ram if i choose to
<clever> yeah
<immibis> someone has already figured out RAM overclocking on this chip. U-Boot has the clock speed as a config parameter
<clever> i also see where the MR registers are handled
<clever> so in theory, i could implement suspend to ram
<immibis> what is a MR register
<clever> a register inside the dram chip itself
<clever> for the configuration of the ram chip
<clever> it can enable things like self-refresh
<clever> then the ram refreshes itself, and you can fully shutdown the SoC and ram controller
<j`ey> immibis: so whats currently working, and can we see the source?
<clever> at next power-up, you need to detect that you did so, initialize the ram differently, and then restore cpu state
<clever> and boom, you have suspend to ram!
mahmutov has joined #osdev
<immibis> j`ey: here is the previous working thing, it blinks the LEDs and runs the vibration motor. https://wiki.osdev.org/User:Immibis/PinePhone_Blinky
<bslsk05> ​wiki.osdev.org: User:Immibis/PinePhone Blinky - OSDev Wiki
<j`ey> immibis: write some C! :P
<j`ey> so 0x01C2086C is some LED periph
<immibis> j`ey: assembly was a good stepping stone, turns out C works out of the box which is good (the u-boot code is C). Just had to write a memcpy and memset
<immibis> https://files.pine64.org/doc/datasheet/pine64/Allwinner_A64_User_Manual_V1.0.pdf Pine64 has released all the documentation they have
<immibis> so describing the registers isn't terribly important here, but specifying how to configure your toolchain is
<immibis> at least if you had no idea previously, like i didn't
<j`ey> where 'here' = the wiki?
<immibis> 'here' = 'in a hello world program'. The point is "I got a program running" not "Here is how the LED register works"
<j`ey> ok right :)
<immibis> but perhaps i will write more documentation later. This is a GPIO peripheral and you have to refer to the schematic to see what's connected to what
<clever> immibis: normally, device-tree tells you what is on each pin, but at earlier stages like uboot, the DT hasnt loaded yet
<j`ey> or boot with uboot and get a dtb
<clever> enles your using a uboot with the board dtb baked in at compile time
<immibis> of course the dtb is baked into uboot
<immibis> where else would it be? there's no BIOS
<j`ey> uboot is the bios!
<immibis> the usual boot flow seems to be: boot ROM -> u-boot SPL (from SD card) -> u-boot proper (from SD card)
<immibis> exactly
<immibis> u-boot is the BIOS
<immibis> but i am not using u-boot, except for the dram init code I copied...
<j`ey> hmm interesting, I didnt realise SPL was first.. 'secondary program loader' sounded like it came after uboot
<clever> j`ey: a lot of arm chips can only load a small fixed size blob from a fixed offset on flash, and that is the SPL
<clever> and the SPL then deals with loading a variable size blob, and maybe bringing the ram online first
<immibis> then an MBR is also an SPL
<immibis> (usually)
<clever> yeah, MBR does kinda fit the role of SPL, though you have a lot of api backing it up
gog has joined #osdev
isaacwoods has joined #osdev
asymptotically has joined #osdev
zhiayang has quit [Remote host closed the connection]
zhiayang has joined #osdev
nur has quit [Ping timeout: 240 seconds]
stux|away has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Ping timeout: 252 seconds]
ElectronApps has joined #osdev
mekeor has joined #osdev
mahmutov has quit [Ping timeout: 258 seconds]
mahmutov has joined #osdev
Arthuria has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
nyah has joined #osdev
zoey has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
Izem has joined #osdev
nur has joined #osdev
MarchHare has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
ElectronApps has quit [Remote host closed the connection]
freakazoid333 has joined #osdev
Arthuria has quit [Ping timeout: 265 seconds]
heat has joined #osdev
iorem has quit [Quit: Connection closed]
<Izem> what's a simple C compiler for osdev? Is it possible to make a cross compiler with tinyc?
<j`ey> Izem: why do you want a simple C compiler?
<j`ey> why not use gcc like most others?
<heat> maybe fun
<Izem> I don't care about performance, I hoped to spend less time reading compiler documentation
<heat> why do you need to read compiler docs?
<j`ey> Izem: I think sticking with gcc, and looking at what other people have done will be simpler, personally
<heat> ^^clang also works
<Izem> that was my experience from a previous attempt, also it does take a lot to build
* heat wonders if ICC has a cross compilation mode
<j`ey> yeah but you dont have to rebuild it that often
<Izem> if not, then gcc is ok
<j`ey> https://wiki.osdev.org/TCC who knows how good this article is
<bslsk05> ​wiki.osdev.org: TCC - OSDev Wiki
<heat> >batch files
<heat> run
<j`ey> hehe
<Izem> thanks
<heat> waiiit
<heat> the build system is a .bat?
<GeDaMo> There's a project for a minimal bootstrap for GNU stuff which uses tcc to build gcc at one point, I think
<bslsk05> ​oriansj/stage0 - A set of minimal dependency bootstrap binaries (33 forks/491 stargazers/GPL-3.0)
<GeDaMo> Hmm ... I don't see any reference to tcc there, maybe I'm thinking of another project
<bslsk05> ​guix.gnu.org: Guix Further Reduces Bootstrap Seed to 25% — 2020 — Blog — GNU Guix
<GeDaMo> Ah, that's it :)
heat has quit [Quit: Leaving]
heat has joined #osdev
mhall has quit [Quit: Connection closed for inactivity]
<Izem> Is this a concern "Dynamic ELF libraries can be output but the C compiler does not generate position independent code (PIC). It means that the dynamic library code generated by TCC cannot be factorized among processes yet. " ?
<nur> so uh the isr bug that took me weeks to debug was: I didn't leave enough space on my stack for the return address
nanovad has quit [Ping timeout: 258 seconds]
<nur> thats why my stack was getting clobbered
jjuran has quit [Ping timeout: 255 seconds]
<Izem> wasn't able to compile tcc, gcc it is then
<heat> nur, that makes no sense
<j`ey> it's a shame that linux cant be built with tcc anymore
<nur> I needed to leave 4 bytes for the CPU to stick a return address in
jjuran has joined #osdev
<nur> isn't that how it is?
<heat> that still makes no sense
<heat> no
<nur> well it works _now_ :-|
<heat> call pushes the return address
<heat> no need to "make space"
<nur> yes and before call we leave 4 bytes before the 16b boundary
<nur> ...right?
<heat> why 4 bytes?
<nur> 32 bits
<heat> but why 4 bytes
<nur> the size of an address
<heat> but why exactly 4 bytes
<heat> the misalignment is random
nanovad has joined #osdev
<nur> not if you realign it _before_ you stick the parameters in like I did
<heat> so you align it two times?
<nur> nope just once
<nur> the struct is 76 bytes
<nur> align it, push the struct in
<nur> and you have 4 more bytes to make it an even 80
<nur> and that 4 bytes is the return address
<nur> and then call the function
<heat> so you align it two times
<heat> also if you "allocate the return address" you're breaking the ABI
<heat> it stops being 16 byte aligned
<nur> how come
<heat> sub $4, %esp will misalign the stack again
<heat> and then call will subtract it again by 4
scaleww has quit [Read error: Connection reset by peer]
<nur> I never do sub $4
<nur> I just align it once
<heat> how do you allocate it then
<nur> I align it with: and %esp, 0xfffffff0
<nur> so at this point the stack is 16b aligned yes?
<heat> yes
<nur> and THEN stick 76 bytes of data in
<heat> yes
<nur> then I call the function
<nur> the CPU will push the return address before calling
<heat> that padding is just padding
<heat> not the return address
<nur> there's no padding
<heat> yes there is
<heat> you need to have padding at the end
<nur> to make it 80 bytes?
<heat> yes
<heat> because that is 16 byte aligned
<nur> but where would the return address go
<heat> right after it
dormito has quit [Ping timeout: 252 seconds]
<nur> well if I do that, part of my parameters get clobbered
<nur> if I leave 4 bytes, it works
<heat> everything after the call instruction knows it's 4 bytes misaligned and that's it
<nur> I don't know how else to explain this behaviour
dormito has joined #osdev
<heat> OH
<heat> I SEE
<heat> the abi doesn't guarantee that arguments passed by value aren't touched
<heat> that's why you pass by pointer
<nur> I mean, I guess I could. But I like finding out why it was failing in the first place.
<heat> it's doing stuff with 8(%ebp) because it's clobbered
<heat> it *can* write to the arguments
<heat> and it does in fact use them as stack space when optimising
<nur> ah I see
<nur> the compiler decided "you won't be needing this when the function returns"
<heat> the abi did
<nur> I see.
freakazoid333 has quit [Read error: Connection reset by peer]
Izem has quit [Quit: Izem]
immibis_ has joined #osdev
immibis has quit [Ping timeout: 255 seconds]
Mooncairn has joined #osdev
asymptotically has quit [Quit: Leaving]
Izem has joined #osdev
Izem has left #osdev [#osdev]
freakazoid333 has joined #osdev
Arthuria has joined #osdev
nick8325 has quit [Quit: Leaving.]
lucf117 has joined #osdev
silverwhitefish has quit [Read error: Connection reset by peer]
silverwhitefish has joined #osdev
XgF has quit [Remote host closed the connection]
XgF has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
geist3 has joined #osdev
<geist3> ah nice, libera has a web chat set up now
<heat> this is getting out of hand
<heat> now, there's 3 of them D:
<geist> haha
<geist> geist2 is my trail run of irccloud. i'm actually thinking about just switching to that
<geist> and having irssi as backup, mostly for logging
geist3 has quit [Quit: Client closed]
pyzozord has joined #osdev
<pyzozord> hey I am a bit confused about ctrl+alt+f1-6, it seems to switch to ttys. On tty1 I seem to have gnome login screen. On tty2 is my gnome session, on tty3-6 I see shell login screen. Does that mean my entire user session lives in tty2 even when I create many terminal emulator tabs? How does that work? And why is there only 6 ttys?
srjek|home has joined #osdev
<pyzozord> How come it switches between text mode and graphical mode? How is that related to ttys?
<geist> that's 100% how the distro has set it up
colona has joined #osdev
<geist> i honstly dont know precisely how a gui session 'consumes' a tty like that, but it appears to just due to a quirk in how linux does that
<geist> the number of ttys is usually set up by the init process (and systemd in modern stuff). what the config files look like for systemd i dunno. it used to generally be something like /etc/inittab
<geist> and it would describe how many ttys to create, what to put on them, etc
<pyzozord> so are tty kind of like "user slots" - on my system there can be up to 6 "users" logged in? And I got two atm: gnome login shell, and my gnome session?
<geist> something like that
V has quit [Ping timeout: 268 seconds]
<geist> note that remote logins you can usuallyhave an infinite number, since they create a 'pseudo tty' on demand
<geist> key is a login session (including a gui) needs some sort of tty to anchor it to for job control reasons and whatot
<pyzozord> and those 'pttys', will they live onther one of the ttys 1-6?
<geist> yes they are a different numbering
<geist> pty0, pty1, etc
<pyzozord> so each tty has a set of ptys?
<geist> if you ssh into your machine and look at the logins with 'who' or whatnot you'll see the tty its associated with
<geist> no ptys are completely separate
<geist> you can create one on demand via some api i forget
<pyzozord> ah so there is just two lists: list of ttys and list of ptys
<geist> any others yes
<geist> i think 'console' can be considered a tty
<geist> i think to linux it doesn't really matter. a lot of things can be a tty in the kernel, and the name just doesn't need to collide
<geist> but AFAIK most of them are ttyX, ptyX, or maybe one of the serial ports (ttySX), or the console
<heat> ptys are ttys but user-mode
<heat> the console points to a specific tty, and acts like a tty
<heat> ttys are, well, ttys
<geist> exactly. a pty is kinda like a pipe but also has tty semantics
<pyzozord> so it looks like each tty has to be connected to a pty?
<heat> no
<geist> stuff like ssh, gnome terminal, etc will create a pty and feed data through it so your shell has a tty under the hood
<heat> kernel-managed ttys are all kernel, no pty involved
<geist> no again. tty and pty are not connected to each other at all
<geist> a tty is associated with a thing that was created at boot (in this case)
<geist> a pty can be created on demand
<geist> every time you ssh into your machine it creates a new pty, for example
<pyzozord> ok, then why have two systems like this?
<geist> i just described it
<geist> they're not two sysstems
<geist> they're just two *implementations* of a tty
<heat> they're one system with two implementations
<geist> any number of drivers in the kernel can say 'i just make a tty for you to use' if they implement a particular api
<geist> ptys are used when there's no physical hardware to bind a tty to
<heat> ptys share most of tty code, but when it comes to getting input and output and whatnot, it goes through the pty
<geist> you create one virtually, hence the 'pseudo' part
<geist> but also since there's no hardware to bind to, you can create as many as you like
<geist> and dynamically
<heat> you can think of a tty as a bunch of code, data and behavior that is shared by things
<geist> i think it's actually easier to think about if you dont have a console, and dont have a gui. but say you have a computer with 8 serial ports
<geist> you start the computer, it could have 8 serial ttys configured
<geist> ttyS0, ttyS1, ttyS2. each with a login on it
<heat> at the backend you can have something like a serial port driver that reads/writes, or a virtual terminal that reads from the keyboard and writes to the screen
<heat> or a pty that goes through user-space
<geist> yah a tty is more of an api with additional behavior on top of just poking data through it
<geist> job control, etc
<geist> and the logic that backs that
<pyzozord> ok but I have just one keyboard and one screen. Well actually two keyboards and two screens because it's a laptop. Why do I have 6 ttys
<heat> because it's useful to create more ttys
<pyzozord> you said that tty connects to some physical hardware
<geist> because that's a feature of the linux console driver. it takes one piece of hardware (keyboard + vga output) and then multiplexes it
<pyzozord> oh I see
<geist> that's simply a feature of the driver to expose multiple multiplexed copies of itself
<pyzozord> but then why multiples tty, why not juse pty?
<heat> yeah
<geist> it doesn't *have* to, but it seems to be a general feature that most BSDs, linux, etc support when you hve a physical console like that
<geist> because ptys != ttys
<heat> because ptys mean you would need to do it in user-space
<geist> right. ptys *are not associated with hardware*
<geist> that's precisely the difference
<heat> and historically you do lots of these things in the kernel
<geist> ptys are just two endpoints , both have to be read/written in user space
<pyzozord> i see so pty can't get keyboard input directly from keyboard?
<geist> say, for example one endpoint is a sshd for a ssh login, and the other one is your shell
<geist> correct
<heat> pyzozord: it can if you make it do that with your own code
<bslsk05> ​man7.org: pty(7) - Linux manual page
<geist> right, you'd need a process that is reading and writing to some device
<pyzozord> I see
<geist> you *could* build a posix system that doesn't implement anything but ptys if you wanted, but you'd need some sort of daemon that is reading and writing /dev/keyboard and /dev/vga or whatnot
<geist> and doing all that logic in user space
<geist> that functionally what happens when you are using X windows
<geist> your gnome terminal is pretending to be a console and taking keyboard inputs from X and whatnot, feeding it through a pty it created for the shell you're running inside it
<heat> you can think of a tty as some sort of a struct like struct tty { funcptr post_input; funcptr write; }; and all variations just have different function pointers
<heat> (in pty terms, writing to master goes into post_input, writing to the slave goes into write)
<geist> and thkng of the tty api as being above and beyond just simply a device to read/write characters, like you might get if you opened say a 'raw' serial port
<pyzozord> so how come when I switch between ttys the graphical mode changes?
<heat> dunno
<heat> ask the vterm
<heat> that's all vterm
<geist> because each one has a different configuration. that's the point of it multiplexing the console for you
<heat> the ttys have nothing to do with resolution or video modes or whatever
<geist> it stores completely separate state for each. that's a feature.
<heat> ttys are fancy pipes
<pyzozord> when I switch to tty2, gnome detects it is now active and "takes over" controll over the graphics card and makes it display other stuff?
<geist> so X windows has grabbed onto one of the ttys for you, and it's a nice feature that it can switch back and forth between the graphical mode X is using and text mode
<geist> i dont think gnome necessarily sees it, but honestly i dunno how the gpu level handoff works there
<geist> probably what happens is X/wayland ceases to get input from the keyboard and whatnot and maybe some sort of notification that its no longer got the output so it can stop drawing
<geist> dunno about the latter
<geist> but for the text mode ttys that would be it. keyboard input just doesn't get redirected to the ones that aren't active
<geist> but anything in th background that's posting new text to an inactive tty is probably still being consumed in the kernel, and a vt100 emulation is still running in the background
<geist> and just rendering to a fake buffer that's not currently being displayed
<geist> again, that's a feature of the multiplexed VT driver in linux
<pyzozord> ok and vt stands for virtual terminal, so it's a driver to a virtual device, not a physical one, but this dirver does access physical input and output devices, correct?
<geist> i wouldn't say that's what i means
<geist> i just said VT because heat did. i honestly dont know what linux's name for the driver is
<geist> also i *assume* you're talking about lnux here
<pyzozord> yes
<geist> these things work similarly on BSDs and just have different names for baically the same thing
<geist> asnyway i think you have enough info to go do some readon
<geist> i dont know the details you're looking for specifically, i can only talk about it generically, as in 'that's probably what it'd do' plus 'what i've generally seen linux do'
<geist> but i dunno what the specifics are
mcs51 has joined #osdev
<pyzozord> yes I'll read a bit more and come back with more questions
<pyzozord> geist: heat: thanks!
pyzozord has left #osdev [#osdev]
z_is_stimky_ has quit [Read error: Connection reset by peer]
z_is_stimky has joined #osdev
GeDaMo has quit [Quit: Leaving.]
mahmutov has joined #osdev
<heat> yes they call it vt
<heat> it's "virtual" because it's technically not a physical device, but a combination of the two(display for output and keyboard for input)
zoey has quit [Ping timeout: 255 seconds]
skipwich has joined #osdev
<geist> yah it's virtual in the sense that they're providing multiple virtual terminals multiplexed on top of a single physical
<mjg> you guys mentioned 'lo fi' music, anything specific?
<geist> https://youtu.be/5qap5aO4i9A for example
<bslsk05> ​'lofi hip hop radio - beats to relax/study to 2021-07-11 21:24' by Lofi Girl (live)
<geist> lofi girl is i think kinda the originator of it. at least was the first one to get 'big'
<geist> there are tons of other streams like this with different variants
<bslsk05> ​'Need For Speed 4 High Stakes Soundtrack - Callista (HD 1080p)' by NFS2SE3HP4HS8U2 (00:04:20)
gog has quit [Ping timeout: 265 seconds]
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
Mooncairn has quit [Ping timeout: 265 seconds]
mahmutov has quit [Ping timeout: 272 seconds]
mahmutov has joined #osdev
Izem has joined #osdev
mcs51 has quit [Quit: WeeChat 3.0]
freakazoid333 has joined #osdev
mahmutov has quit [Ping timeout: 258 seconds]
<doug16k> https://en.cppreference.com/w/cpp/memory/shared_ptr "The pointer held by the shared_ptr directly is the one returned by get(), while the pointer/object held by the control block is the one that will be deleted when the number of shared owners reaches zero. These pointers are not necessarily equal." How?!
<bslsk05> ​en.cppreference.com: std::shared_ptr - cppreference.com
<doug16k> how can they possibly be not equal
<kazinsal> C++: where deterministic behaviour is not required
<heat> lol
<heat> that's legalese for "here be dragons"
<doug16k> is it just a race where it isn't enforcing store ordering on the shared_ptr pointer and/or the control block pointer?
<geist> possible the shared ptr is actually pointing to some subclass?
<geist> and due to virtual inheiritance the ptr is offset from what you get
<geist> ie, a shared_ptr<B> to some subclass of A, but you're operating on a shared_ptr<A> so get() gets you a ptr to the A portion of it
<geist> and all that virtual inheirance stuff can end up with offset ptrs and wehatnot
<geist> i assume you can easily cast a shared_ptr<B> -> shared_ptr<A> since it should generally act like a regular pointer
<heat> oh
heat has quit [Remote host closed the connection]
<heat> good point
gog has joined #osdev
Izem has quit [Quit: Izem]
<doug16k> it sets that when the shared_ptr is constructed, how did it get two different pointers?
heat has joined #osdev
<doug16k> I mean sets the control block field to be equal to the shared_ptr's pointer field
<doug16k> seems like I need to know why it says that to properly implement shared_ptr
<heat> doug16k: casts
<doug16k> it must be that all those fields aren't atomic, and shared_ptr is intended to be lock free, so they just say yolo and let weakly ordered stores set the control block field?
<heat> get() returns a different pointer because of inheritance weirdness
<doug16k> what?
<doug16k> nonsense
<heat> the control block still stores the pointer to the original object
<heat> why?
<doug16k> when it constructed the shared_ptr it sets up the control block. the type won't miraculously change between setting shared_ptr ptr field and control block pointer
<heat> std::static_pointer_cast
<heat> you get a shared_ptr with a different type but same refs
<doug16k> how does that magically unsynchronize the shared_ptr ptr and the control block ptr
Izem has joined #osdev
<heat> the shared_ptr will have a possibly-offset pointer to the control block's ptr
<heat> due to weird inheritance stuff
<doug16k> you don't seem to understand what shared_ptr is doing
<heat> i understand what shared_ptr is doing
<doug16k> shared_ptr has a strong and weak ref count, plus, either a pointer to the instance (if not combining instance and control block) or the instance itself
<Izem> what's the significance of chroot, /, and unix systems? I know they used chroot to bootstrap unix, but what about when it first started?
freakazoid333 has quit [Remote host closed the connection]
Mooncairn has joined #osdev
<doug16k> cppreference says the control block pointer and shared_ptr pointer might not be equal. that's not possible
<doug16k> how can the type of a control block pointer not match the owning shared_ptr
<doug16k> 's pointer
<doug16k> they would point to the same type and would cast to the same thing
<heat> they can point to not-the-same-type
<doug16k> how
<doug16k> what do you think assigning to a shared_ptr does?
<heat> static_pointer_cast
<heat> that does a cast
<heat> you still have the same control block(e.g the same reference counting)
<heat> but the pointer is different
<heat> s/is/can be/
<doug16k> static_pointer_cast makes a new shared_ptr does it?
<heat> yes
<doug16k> all fucked up where it is using old control block and different instance? bullshit
Arthuria has quit [Ping timeout: 265 seconds]
<immibis_> there's literally a constructor that explicitly lets you associate any shared pointer with any control block
<bslsk05> ​en.cppreference.com: std::shared_ptr<T>::shared_ptr - cppreference.com
<immibis_> "8) The aliasing constructor: constructs a shared_ptr which shares ownership information with the initial value of r, but holds an unrelated and unmanaged pointer ptr."
<doug16k> where is the other pointer value
<immibis_> the obvious reason to do such a thing is so your pointer to some part of a structure can hold a reference to the entire structure
<doug16k> how does that point the shared_ptr at A and the control block at B
<immibis_> shared_ptr<foo> f = make_shared<foo>(); shared_ptr<bar> b(f, &f->field_of_type_bar); // b uses the same control block as f but it pointers to the field_of_type_bar
<bslsk05> ​gist.github.com: shrd.cpp · GitHub
<heat> just like this
<immibis_> shared_ptr<int> a = make_shared<int>(); shared_ptr<double> b(a, new double); // probably a bug
<heat> (in very pseudo code of course)
<doug16k> so you can point the control block at the refcounted thing and get points to a member?
<immibis_> doug16k: the control block holds the reference count(s) and the deleter function. The control block "is the refcount" and it also remembers what to do when the refcount gets to 0
<heat> yes
<doug16k> I see. thanks
<doug16k> since C++20
<doug16k> right?
<heat> it can do that since C++11 at least
<heat> because of static_pointer_cast and friends
<heat> that's just the constructor being exposed to outside uses
<doug16k> shared_ptr is crap. I have seen it at top of profile
<immibis_> doug16k: c++20 is the && one. The const& one is not since c++20
<geist2> yah i was just pointing out that it could be because of the 'raw value of a ptr may change in a virtual inheiritance thing based on what subclass you're looking at' thing
<doug16k> ya, that doesn't explain how two different pointers get in a shared_ptr
<geist2> okay.
<doug16k> I didn't know two types was a thing at all in shared_ptr
<geist2> of all the things i plan on doing today, thinking too much about C++ isn't it
<doug16k> I never use it because its performance is atrocious
<doug16k> shared_ptr == "can't be bothered to manage the ownership"
<geist> alas. it seems to be the standard for stuff at work
<doug16k> "do it over and over k thanks"
<geist> because 'humans suck at programming so must assume everything is broken'
<heat> shared_ptr being at the top of the profile is the user's fault
<heat> it's a big boy ptr, not a unique ptr
<geist> that being said we use an intrusive one in the kernel, so at least there's not a second structure
<geist> though still pays the price with all the atomics
<doug16k> it shouldn't be possible for operator-> to be at the top of a profile for a smart pointer
<doug16k> er, sorry, copy construct
<heat> (and even a unique ptr generates significantly worse code than a raw pointer)