<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
<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>
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
<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
<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?
<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?!
<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
<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
<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)