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
rorx has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
rorx has joined #osdev
MarchHare has joined #osdev
h4zel has quit [Ping timeout: 246 seconds]
h4zel has joined #osdev
nyah has quit [Ping timeout: 260 seconds]
gog has quit []
gog has joined #osdev
dormito has quit [Ping timeout: 246 seconds]
dude12312414 has joined #osdev
freakazoid343 has joined #osdev
superleaf1995 has joined #osdev
<superleaf1995> Should drivers be instanced per device or be a single instance managing multiple devices?
<moon-child> I think you asked this once before
<superleaf1995> Ah in the freenode irc channel i think
<moon-child> 2021-02-06 <superleaf1995> I have a few theorical questions: 1. Should the kernel load N drivers for N devices on system. (example: i have 20 nVidia cards, so i load 20 processes of module nouvau.kmod) or is it better to have a driver to control ALL of the devices in the system (rtl.kmod controlling the 3 RTL8139 cards i have)
<zid> Threads is also an option
<superleaf1995> i think geist mentioned something about just allowing the drivers to freely choose
<geist> yeah basically all of the above
<geist> you might choose to compartmentalize drivers based on risk vs reward
<klange> Drivers are code, there should be one of them and an instance of an object per device, whether that's a struct or a class or whatever your implementation allows.
<klange> imo
<superleaf1995> so generally i want 1 instance managing everything?
<zid> The obvious optimization is to re-use .text
<zid> the rest is up to you
<zid> on how you manage that
<superleaf1995> My kernel rn just spams a driver for each device
<superleaf1995> which is good until the memory starts to drop to comically small sizes
<klange> The one driver I have that actually correctly supports multiple things is my e1000 NIC driver. The code is only loaded once, each NIC gets a struct, the driver manages all of the structs.
<zid> Sounds like you'd need to hand-code that per driver though?
<zid> Automating it with some DLS (like TLS but for drivers?) might be a thing
<superleaf1995> TLS?
<superleaf1995> ah wait the thread thing
<superleaf1995> i mean why not, the kernel generally does not care what the driver does (but if it fucks up it will be instantly killed) - so i guess i can stash in some threading
<klange> It's just basic object-oriented design...
<superleaf1995> yeah...
<superleaf1995> talking of OO, i'm starting to code a mini database engine (horribly slow mind ya) that can run on my system, it's nothing big but i'm starting to slowly build an ecosystem around it
srjek|home has quit [Ping timeout: 245 seconds]
sts-q has joined #osdev
superleaf1995 has quit [Quit: leaving]
freakazoid343 has quit [Read error: Connection reset by peer]
freakazoid343 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
mahmutov has joined #osdev
freakazoid343 has quit [Ping timeout: 264 seconds]
freakazoid12345 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
mahmutov has quit [Ping timeout: 246 seconds]
h4zel has quit [Ping timeout: 250 seconds]
h4zel has joined #osdev
AssKoala has quit [Ping timeout: 250 seconds]
dutch has quit [Ping timeout: 245 seconds]
dutch has joined #osdev
ElectronApps has joined #osdev
<kazinsal> Ugh. Time to basically bisect my way through about 30 commits to find the offending one.
<kazinsal> Fuuuuuuuuuuuuck
<moon-child> that's 5 bisects max
<moon-child> not bad
<kazinsal> okay, found a failing one. time to jump backwards...
<kazinsal> gonna quicksort my way through this...
<kazinsal> aha! found it
<kazinsal> fuckin bug's been plaguing me for months
<kazinsal> time to test if this fix works
* kazinsal stares with hatred at this code
anon16_ has quit [Ping timeout: 246 seconds]
<kazinsal> magical. it's not my code.
<kazinsal> it's virtualbox.
<kazinsal> works *perfectly* on vmware
<moon-child> qeeeeeemu :3
<klange> I have long lists of bugs in qemu ;)
<klange> (qemu is where I spend most of my time, though...)
<kazinsal> vmware: packets go where they are told
<kazinsal> virtualbox: packets leave the virtual NIC and enter the void
ElectronApps has quit [Ping timeout: 245 seconds]
<klange> vmware seems to have a more... realistic network implementation? Often in a negative way if you're just trying to get packets to a guest...
<kazinsal> yeah, it's slower but more precise
<klange> I don't play with the tunnel backends for VBox or QEMU much, I hide behind slirp...
<kazinsal> I'm using the intnet backend on vbox because I need to test inter-VM forwarding
<kazinsal> and boy howdy does it suck
<kazinsal> it seems that once you get to a certain packets/second mark it just starts dropping shit
<kazinsal> I reeeeeeeally need a test rack
<Affliction> Just like real networks!
<kazinsal> oh, it's not doing it in a smart way
<klange> Just like real networks!
<kazinsal> it's just dropping random shit off the FIFO head
<kazinsal> real networking devices drop at the tail
<kazinsal> honestly I'd say this is just incorrect behaviour, but it's an Oracle product, so I don't know what I expected
<kazinsal> of course now I think I need to start optimizing memory usage... I am copying way too much
<kazinsal> it wasn't noticeable on my desktop, which has 3600 MHz DDR4
<kazinsal> on my ESXi box, which has 1333 MHz DDR3? oooooh boy
<kazinsal> losing literally almost two thirds of your memory bandwidth will show your memory constraints in force
<Affliction> "but it's an Oracle product, so I don't know what I expected" - A licensing audit, followed by a lawsuit? :)
<Affliction> I recall some network switches dropping older packets in the queue, to earlier signal congestion
ElectronApps has joined #osdev
<zid> time to buy 4 sticks of ram kaz
<kazinsal> honestly it's more like "time to give up on virtualization because virtualization + networking = bad juju"
<geist> y7ah you're running your router as a VM right?
<geist> well in a vm
<kazinsal> yeah
<kazinsal> as well as the client machines
<kazinsal> so there's three machines' worth of VM overhead, plus two virtual switches
<kazinsal> on some slow-ass memory with a 2 GHz Sandy Bridge core
<geist> yah that was my main complaint with the ECC ram i got for my server, it's much slower than usual desktop stuff
<geist> though not 1333
<klange> i don't even know what my current ram is
<geist> 2133 DDR4 i believe, but that was the cheapest i could find before it got hyper expensive for ECC
<klange> just that 64GiB seemed like a lot five years ago when I got it
<geist> and it was still pricy
<kazinsal> I think I'm going to end up replacing this thing with a recent-ish Ryzen and some mid-range DDR4
<kazinsal> it'll probably be way faster
<geist> that's what mine is, with ECC
<geist> has been a trooper
<kazinsal> I told myself that I wasn't going to buy myself any more toys after getting a Boogie but y'know
<klange> Amazon says I am running... four DIMMs of DDR3-2133, 16GiB each.
Geertiebear has joined #osdev
<klange> I imagine my RAM is half the reason this box is slower than my Surface.
<geist> i piddled with some timings and ran some random benchmarks before (compiling stuff, etc) and found that it mattered but not incredibly so
<geist> like, maybe 20% at the worst
<geist> though obviously can find some worst case scenarios
<klange> This box is so old now, and while I'm amazed a low-power laptop is faster the market for new parts has been problematic due to COVID and that flooding thing a few years ago.
<klange> So it's not like there's really anything worthwhile to buy to upgrade.
<klange> But I think I've made this rant before, when I was bringing my T410 back online. Ten years old, still seems to be a perfectly adequate and usable machine? It's a bit bulky, battery life sucks, but it chugs through builds just fine after replacing its dead hard disk.
<klange> Ten years before that was 2000. Pre-64-bit. Sub-gigahertz CPUs. The death of Moore's Law is apparent.
xenos1984 has quit [Remote host closed the connection]
elderK has quit [Quit: Connection closed for inactivity]
<kazinsal> yep, it's mostly just memory speed, cache size, and instruction throughput now
<kazinsal> we've been capped at about 5.3 GHz for five or six years now, even at 7nm
<geist> and, you know, features like efficient virtualization
xenos1984 has joined #osdev
<geist> well, just finished upgrading the arm workstation from 18.04 to 20.04
<geist> boots up and runs like a champ
<klange> Looking at what actually has changed since this Nehalem laptop... it predated USB3, was the last model of its line to not have EFI, Nehalem doesn't have gb huge pages...
<klange> Lenovo was kinda slow with EFI adoption, especially for these workhorse product lines.
scaleww has joined #osdev
<zid> I wish amd had a page like intel's ark
<zid> I have no idea what the memory bw is like on any ryzens
<zid> and they'd do it weird because of the numa setup anyway, and probably just add it all together
<kazinsal> from the 3000s onward it's all DDR4-3200
<kazinsal> the 2000s it's DDR4-2933 and the 1000s it's DDR4-2667
<kazinsal> in reality the 1000s are the only actually finicky ones and the 2000s are good at 3200 as well
<kazinsal> and the 3000s onwards are usually happy beyond that
<zid> okay?
<kazinsal> basically AMD doesn't gate memory bandwidth by product segment
<zid> neither does intel, but they do post what is officially supported
<zid> 45.8GB/s on a comet lake etc
<zid> via 2 channel ddr4-2933
<zid> 51.2GB/s on sandy bridge :P
paulusASol has quit [Quit: Bridge terminating on SIGTERM]
happy-dude has quit [Quit: Bridge terminating on SIGTERM]
novasharper has quit [Quit: Bridge terminating on SIGTERM]
<dragestil> i wonder whether i can ask about <ops-class.org>. basically i'm doing asst1 and don't quite understand the code with semaphore, more specifically when tracing the steps during boot, the cpu semaphore seems to magically go from 0 to 7 after a thread switch
<zid> someone wrote a 7 there :p
<dragestil> ...given it is configured with 8 cpus
happy-dude has joined #osdev
novasharper has joined #osdev
paulusASol has joined #osdev
MarchHare has quit [Quit: Leaving]
<dragestil> i did a bit more tracing, apparently the cpu_startup_sem->sem_count changed from 0 to 1 after a cpu wait() at https://github.com/ops-class/os161/blob/master/kern/arch/mips/thread/cpu.c#L296
<dragestil> can't really tell how it could happen
<zid> a thread wrote a 1
<dragestil> how could a thread do that? i was stepping in gdb and didn't see any other thread doing work
<zid> did you set your gdb to freeze all threads? it's kinda tricky to set up all that stuff imo
<zid> 'all-stop mode' I think it's called
<dragestil> no i didn't know about that
xntoan has joined #osdev
<zid> Assuming your gdb stub is clever enough to even do this for you
<zid> sounds like you might be emulating some random mips cpu in qemu or such, teaching about your threading sounds hard
<clever> ive been doing some jtag stuff, and my current config maps each cpu core to a different gdb connection port
<clever> so i would have to run 4 instances of gdb, and each manages a diff core
<zid> making it present each cpu as one thread sounds like a better way to set that up ngl
<clever> but there is something i need to investigate, that maps all of that to the gdb thread api
<clever> yeah
<dragestil> zid: hmm thanks
<klange> :)
<zid> nice
<zid> I was about to laugh at you crashing in libc, but it's in inet_addr so you get a pass
<dragestil> i feel like maybe i should try to understand the code without forcing gdb
<zid> C:\Users\zid>ping 86.0x9C03E
<zid> Pinging 86.9.192.62 with 32 bytes of data:
<zid> Reply from 86.9.192.62: bytes=32 time=7ms TTL=64
<moon-child> ping 1.1
<zid> inet_addr is.. special
<moon-child> zid: indeed
<clever> zid: i saw a post somewhere about all of those whacky forms, many years ago
<zid> I had that in my history
<clever> zid: i just realized, could this bypass blacklists for 192.168.* in a lot of services? ....
<dragestil> is there any less sadistic version of ops-class? i've read ostep and would like to get my hands on some kernel code
<zid> clever: Not unless you double-decoded it?
<clever> zid: things like matrix link previews, involve loading a user-supplied url from the server
<zid> You get the IP as the 'regular' form from socket api, filter on the string, then inet_addr it back to u32
<klange> dragestil: read some kernels, then; we've got a long list of ones you can poke at
<clever> zid: and if i trick the matrix server into loading 192.168.2.1, i get the routers status page
<dragestil> klange: what do you mean by reading some kernels? reading the code?
<clever> zid: there are blacklists to protect the server manager, but what about http://3232271615 ?
<klange> well if you want to get your hands on some kernel code, then yes :)
<zid> clever: yea that'd be a double decode :P
<clever> zid: this is also a threat in aws, with iam instance keys
<dragestil> klange: well i've been reading code from os161 kernel from ops-class, which is supposed to be instructional and well-commented, but i'm pretty stuck on understanding the implementation of semaphore there
<zid> clever: more likely, it just gets rejected as invalid, because it isn't in canonical dotted form, before the filters try to pass/fail the actual number
<clever> ah yeah
<clever> the regex to even detect a link may fail
<j`ey> dragestil: what about xv6?
<dragestil> because it depends on some context and thread switch code and i can't reason
<dragestil> j`ey: thanks, i'll take a look
elastic_dog has quit [Ping timeout: 264 seconds]
* EtherNet started reading xv6 docummentation recently
GeDaMo has joined #osdev
xntoan has quit [Ping timeout: 245 seconds]
zid has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
zid has joined #osdev
elastic_dog has quit [Ping timeout: 252 seconds]
Arthuria has joined #osdev
elastic_dog has joined #osdev
lleo has joined #osdev
vdamewood has joined #osdev
dormito has joined #osdev
<vdamewood> Is there any reason to support floppy controllers or IDE controllers in this day and age?
<vdamewood> Well, I guess "Because It's my OS and I want to run it on my old 486" is a good reason.
<vdamewood> I guess ISA and PCI-not-e are also on the list of things not to support.
<zid> 486 doesn't support anything that I support anyway
<zid> I support PCI just because it's trivial to do it
<zid> you just change the device probing code to use a read port instead of a read
<zid> good luck running my 2020 pci-e e1000 driver on your 486
<vdamewood> I wish I had a 486.
<vdamewood> *still
<zid> ebay :p
<vdamewood> Yeah, that's an option.
<klange> IDE is still the default in a lot of a VM setups, fwiw.
<vdamewood> klange: Actually stuff like that is what I was looking for.
nyah has joined #osdev
scaleww has quit [Quit: Leaving]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
ElectronApps has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 245 seconds]
dude12312414 has joined #osdev
[itchyjunk] has joined #osdev
elastic_dog has joined #osdev
Santurysim is now known as Ermine
dude12312414 has quit [Remote host closed the connection]
dennis95 has joined #osdev
dude12312414 has joined #osdev
snowbally has joined #osdev
Vercas7 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas7 is now known as Vercas
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
Retr0id1 has joined #osdev
Retr0id has quit [Ping timeout: 265 seconds]
Retr0id1 is now known as Retr0id
ElectronApps has joined #osdev
* snowbally meows
warlock has joined #osdev
<zid> gog evolved?
<zid> digimon or pokemon I wonder
<klange> Meowing is not exclusively gog's domain.
<zid> hmm yea, not using gog's cloak either
* gog meows
ahalaney has joined #osdev
<klange> Today, we can _all_ meow.
gog has quit [Quit: byee]
gog has joined #osdev
lleo has quit [Quit: beforge.net]
<gog> i don't control who may and may not meow
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #osdev
snowbally has quit [Remote host closed the connection]
meisaka has quit [Ping timeout: 268 seconds]
meisaka has joined #osdev
nvmd has joined #osdev
mctpyt has joined #osdev
<[itchyjunk]> moo
* gog offers [itchyjunk] some hay
* [itchyjunk] ruminates
unmanbearpig has quit [Quit: unmanbearpig]
* vdamewood gives gog a fishy.
* gog borða fiskur
srjek|home has joined #osdev
<gog> hm fish and chips would slap rn
AssKoala has joined #osdev
<vdamewood> I just ate all the Tater Tots, and I don't have any other kinds of chips.
<gog> we have potato
<gog> i could get fish later
<gog> hmmmmm
<vdamewood> Yum.
sprock has quit [Ping timeout: 264 seconds]
ElectronApps has quit [Ping timeout: 265 seconds]
anon16_ has joined #osdev
h4zel has quit [Ping timeout: 245 seconds]
EtherNet has quit [Quit: WeeChat 3.0]
EtherNet has joined #osdev
transistor has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
h4zel has joined #osdev
dennis95 has quit [Quit: Leaving]
sprock has joined #osdev
anon16_ has quit [Ping timeout: 245 seconds]
nyah has quit [Remote host closed the connection]
nyah has joined #osdev
anon16_ has joined #osdev
blockhead has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
<Bitweasil> Hm.
<Bitweasil> The boot loader stuffs an initrd in RAM somewhere. How does it communicate to the ARM kernel the location of such?
<clever> Bitweasil: device-tree, one sec
<Bitweasil> I can find the ATAGS field for it, just not the device tree details...
<clever> ive had to implement it, so i have example code for the bootloader end
<clever> Bitweasil: its linux,initrd-start and linux,initrd-end under /chosen
<clever> and now that we know the keywords, you can grep the linux docs for them
<Bitweasil> Ah hah!
anon16_ has quit [Ping timeout: 240 seconds]
<Bitweasil> Thanks, that's the bit I was missing, the keywords. Much appreciated!
<Bitweasil> ... and people wonder why I still use IRC. Search for esoterica for a few hours, or ask here. :D
<Bitweasil> And that's ungzipped in RAM, correct? The bootloader has to decompress it if it's been gzipped?
<clever> nope
<clever> linux will uncompress it for you
<clever> linux will also seamlessly handle if you concat several initrd's, i think even mixed compressed and uncompressed
<clever> each just gets unpacked to the tmpfs in turn
<Bitweasil> Ah, nice.
<Bitweasil> *bolts that into RAM and sees what happens*
<clever> Bitweasil: ipxe has a handy feature, where it will take an artitrary file, wrap it in a cpio header, and prepend it to the initrd
<clever> so you can just tell it to fetch foo.bin over http, and package it up into an initrd as /foo.bin
<clever> then it magically just appears at /foo.bin once linux unpacks every initrd
<Bitweasil> Huh. I've never done much with netbooting. Sounds a useful thing, though!
<Bitweasil> Well, it's trying to unpack it, at least...
<Bitweasil> *twiddles his thumbs*
<clever> Bitweasil: ive also had errors due to the end addr being off by one, check the loader.cc example above
<Bitweasil> Oh, you can't just fluff it out past the end?
<clever> yeah, linux gets upset if the end addr is wrong
<clever> checking my code, the end addr, points to the byte AFTER the last byte of the initrd
<Bitweasil> Ok. Didn't seem to whine too hard, I just rounded up to the next page.
<clever> the page alignment, may be to do with mapping things into the virtual space
scaleww has joined #osdev
<clever> but it may use the original end, for the decoding
<clever> its been a while since i read that linux source
<Bitweasil> Ok, easy enough to set that properly. :)
<Bitweasil> I've got "console=ttyAMA0,115200" in my command line, getting a "Warning: Unable to open an initial console" error - I've implemented the PL011, is that AMA0 or S0?
<Bitweasil> I guess it depends on DTB overlays and such, doesn't it?
<clever> Bitweasil: ah, i had to solve exactly that error
<clever> took me a few hours
<Bitweasil> And I'm not even entirely sure I'm matching real hardware. :D
<clever> Bitweasil: CONFIG_DEVTMPFS
<clever> without that, /dev/console wont exist, and youll get that warning
<Bitweasil> I've got a PL011 that should be more or less properly set up and at the defined address, but I'm not sure what got made or not made in the initramfs right now.
<Bitweasil> Oh, ok.
<Bitweasil> It's set to 'y' in my kernel config.
<clever> then /init gets ran, with a dead stdin/stdout
<clever> ah
<Bitweasil> I'll unpack my initrd and snoof around.
<Bitweasil> It was built on a Pi with a working HDMI out.
<Bitweasil> So may not be set up for serial.
<clever> when i was doing this level of bringup, i had to experiment with exit codes first
srjek|home has quit [Ping timeout: 245 seconds]
<clever> i compiled a custom /init, that was purely just: int main(int argc, char **argv) { return 42; }
<clever> and confirmed that the error was right
<Bitweasil> Bleh, changing to ttyS0 didn't fix it. Ok, I'll crack open the initrd and see what's going on.
<Bitweasil> And there's no /dev/ in my initramfs. :/ I suppose it's dynamically created, but... hrm.
<j`ey> there's a CONFIG_DEVMTPFS thingy
anon16_ has joined #osdev
<Bitweasil> Yeah, I have it set.
<Bitweasil> I'll poke around, this is just kind of bonus if I can get busybox working right now.
scaleww has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
AssKoala has quit [Ping timeout: 252 seconds]
sprock has quit [Ping timeout: 265 seconds]
h4zel has quit [Ping timeout: 240 seconds]
sprock has joined #osdev
mcfrdy has quit [Quit: quit]
mcfrdy has joined #osdev
AssKoala has joined #osdev
GeDaMo has quit [Quit: Leaving.]
Izem has joined #osdev
dormito has quit [Ping timeout: 245 seconds]
sprock has quit [Ping timeout: 252 seconds]
dutch has quit [Quit: WeeChat 3.2.1]
dutch has joined #osdev
dormito has joined #osdev
Izem has quit [Ping timeout: 245 seconds]
ahalaney has quit [Quit: Leaving]
anon16_ has quit [Ping timeout: 252 seconds]
anon16_ has joined #osdev
dormito has quit [Ping timeout: 240 seconds]
dormito has joined #osdev
vdamewood has quit [Quit: Life beckons]
dutch has quit [Quit: WeeChat 3.3]
freakazoid12345 has quit [Ping timeout: 265 seconds]
dutch has joined #osdev
sprock has joined #osdev
sortie has joined #osdev