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
wand has joined #osdev
<blockhead> looking at scroll back i see mention of brk & mmap. interesting, since I've been learning x86 assembly in linux. the bad thing is, a month or so ago I needed to do some memory allocation. ince i couldn't figure whihc was better, i flipped a coin to decide mmap or brk
<heat> better? probably mmap
<heat> simpler? defo brk
<blockhead> so now i'm reading that brk is considered depreciated ... and a month ago the coin said brk :p
<heat> brk is "deprecated"
<heat> whatever that means
<heat> i'm not aware of any real plans to deprecate it in linux
<blockhead> depreciated often means someone on 4chan doesn't want people to use it ;)
<zid> compared to sbrk it is
<zid> not compared to mmap
<heat> sbrk is an illusion
<heat> wake up sheeple
<blockhead> yeah, i can see what you mean there. when i read up on sbrk & brk i could see how one could easily be written as a wrapper to call the other
<heat> brk is the syscall (usually)
<zid> mmap is the only useful syscall though
<zid> all other syscalls are wrappers around it
<heat> the thing with brk is that it's so trivial to implement you may as well do it
<heat> there's no real cost in supporting it
<heat> you will need memory mapping and region expansion functionality, always
_xor has quit [Quit: WeeChat 3.6]
<heat> (which is why I don't understand why fbsd dropped it)
<AmyMalik> me neither
<zid> To annoy porters
<zid> of linux software
* blockhead will stay with brk for now. when i learn more i can revisit the brk vs mmap matter
<zid> mmap is just arbitrary
<zid> and supports flags
<zid> so if you need either of those, you need mmap
<zid> the end
<heat> linux software doesn't use sbrk
<zid> prove it
<zid> I want the source to every linux program, with the output of grep sbrk attached
<heat> it's trivially proven by looking at musl, which stubs out sbrk() for external users (not the heap)
* blockhead does man sbrk (in linux atm) and yep there it is
<zid> so lots of programs use it
<zid> anything that's linked to musl
<zid> is what you're telling me
<mjg> you can't retire sbrk
<heat> no, musl uses it
<heat> programs use musl
<mjg> binary cmpat is king
<heat> checkmate liberal
<mjg> musl or no musl, old shit uses it, so that's that
<zid> so nobody uses opengl because they use loaders for it?
<heat> exactly
<zid> okay just checking
<heat> what is "opengl"?
<heat> you just have a lot of implementations of it
<mjg> > Pride and Prejudice and Zombies
<zid> It's a medicine that makes your thingy bigger
<mjg> what the fuc
<mjg> k
<heat> Budget: 28 million USD
<heat> Box office: 16.4 million USD
<heat> yup seems about right
<zid> clerks 3 only needed a budget of 7, zombies cost a lot appaerently
<heat> mjg, anyway apparently fbsd removed it for arm64 and riscv
<heat> pls fix
<mjg> heat: i don't know if *removed*, i would expect they were never there
* kof123 raises the pot by throwing in alloca()
<mjg> and in that caes why would you add mofo
<heat> why would you not add it originalyl
<kof123> alloca! alloca! alloca!
<heat> alloca is fine
<mjg> presumably by the time the ports emerged there was no need
<mjg> mofo
<mjg> as the malloc in system did not use it
<heat> yeah but like
<heat> the point is brk is just a mremap
<heat> there's no cost in having it
<mjg> yo mama is mremap
<heat> also freebsd added mremap but with the wrong signature and flags
<zid> Your mother is recalloc, nobody uses her correctly and leaves a bug in where the reallocated region is at a different base
<mjg> heat: wut
<mjg> heat: now that's a bug if true
<heat> wait no
nyah has quit [Ping timeout: 264 seconds]
<mjg> zid: interestingly see reallocf
<heat> it doesn't even have it?
<mjg> freebsd syscall api does not
<bslsk05> ​www.freebsd.org: mremap
<heat> netbsd does
<mjg> i see something in linux emul layer but i have no idea if that works
<zid> Are there any syscalls that work in 3D
<zid> or are they all 2D only
<heat> but it's slightly different
<heat> mjg, how does jemalloc expand an mmap allocation?
<mjg> i'm guessing it just mmaps some more
<mjg> and it lands where it lands
<heat> that's depressing
<heat> and as you would say, highly pessimal
<zid> we should stop talking about alloc
<mjg> how so
<zid> and just add one to my kernel
<zid> first one with a patch wins
<mjg> i mean maybe it is, i can't comment, but i doubt it matters in case of jemalloc
<mjg> there is a treshold past which it always mmaps
<mjg> and i suspect it is page size
<heat> void *newp = mmap(new_size); memcpy(newp, p, old_size); munmap(p, old_size);
<mjg> so the above is moot
<heat> how is this not pessimal?
<mjg> why on earth would it do the above
<zid> I swear 80% of the words that mjg and heat exchange are "pessimal"
<heat> what else can it do?
<heat> there's no mremap
<mjg> what scenario in your opinion provokes this
<heat> realloc
<heat> just to be clear, in mmap allocations
<heat> which I assume it does, like every other malloc
<mjg> ok, for those that indeed sounds like a problem
<mjg> well let mer estate, if something was served from a dedicated mmap call, then ye, that sounds like a problem
<mjg> but i'm not so sure glibc can easily avoid it
<mjg> say you mmap, and then mmap again
<mjg> did you make any provisions for these mappings to not be adjacent?
<mjg> if not, you are back to the problem
<mjg> let's do a quick check what glibc is gonna do
<heat> mremap can not only extend and shrink but move
<heat> so your mapping is transparently moved through MMU magic
<mjg> wow glibc still uses brk
<mjg> scrwe it
<mjg> it's approaching 2:30 here, i'm turning in for the day. will flame in the next cycle
<heat> musl stopped using brk because they replaced their dlmalloc-ish thing with a slab-ish thing
<heat> haha
<heat> ptmalloc is literally a heavily modified dlmalloc
<zid> heat where is my patch
<heat> that's why it uses brk
<zid> heat should I make my OS run TWO copies of zelda
<zid> or add an allocator
<heat> 1st
<mjg> THREE copies
<zid> I could do 12
<zid> then I run out of cpus
<mjg> "i need 3 hours"
<mjg> "you got 2"
<mjg> "i'll do it in 1"
<zid> I was thinking 3-4 weeks
<mjg> 's how you sound like
zaquest has quit [Remote host closed the connection]
<bslsk05> ​news.ycombinator.com: Google search was giving errors when searching “how many emojis on iOS” | Hacker News
tsandstr has quit [Remote host closed the connection]
zaquest has joined #osdev
<kof123> alloca(3) DESC takes memory hostage BUGS freed if and when the stack frame police show up
<moon-child> yeah glibc kinda crap
<moon-child> strfry(3) still best function though
<kof123> + (chat patch) thin blue stack pointer line/arrow
gog has quit [Ping timeout: 264 seconds]
SpikeHeron has joined #osdev
smach has joined #osdev
Lumia has joined #osdev
freakazoid332 has joined #osdev
[spookyjunk] has quit [Remote host closed the connection]
wereii has quit [Quit: ZNC - https://znc.in]
wereii has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
smach has quit [Ping timeout: 252 seconds]
civa_ has joined #osdev
civa has quit [Ping timeout: 250 seconds]
Raito_Bezarius has quit [Ping timeout: 268 seconds]
smach has joined #osdev
Lumia has quit [Remote host closed the connection]
Lumia has joined #osdev
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
LostFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
PapaFrog has joined #osdev
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
Lumia has quit [Ping timeout: 264 seconds]
Lumia has joined #osdev
heat has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #osdev
Gooberpatrol66 has joined #osdev
smach has quit []
<geist> installed freebsd 13.1 on the same pentium 4. runs pretty great
<geist> or at least doesn't seem too unreasonable
<geist> uses a little more memory at boot sitting still (14MB) but that's still pretty tiny compared to lots of other distros
sprock has quit [Remote host closed the connection]
sprock has joined #osdev
<zid> I'd expect a pentium 4 machine to be nearing a gig, if it's a serious machine, anyway
<zid> so 14MB seems like a rounding error
<geist> well, it's ess of whether or not it has the memory to hold it (it does, 1GB) but more of 'does the average program completely blow the L1/L2 caches'
<geist> my personal theory is that's the main reason older machines seem to fall off a cliff running newer software. or alternatively, the hidden cost of newer software
<geist> it's bigger but as long as you have cache that can keep up with it it doesn't nonlinearly scale
<geist> but you're right, i was just doing a make buildkernel a while ago and noticing the ave3rage cc process was like 134MB
<zid> yea, newer software just does a lot more useless shit that is pure overhead, and I don't even mean in a "bloat" way, I mean like
<geist> so you really do need a fairly big machine by old machine standards
<zid> allocating an array of struct cpu cus smp exists, so now there's an extra pointer
<zid> etc
<geist> yah stuff like localizations
<geist> yah
<geist> or just generally more features that *may* be used, so comes along with the text segment, etc
<zid> right
<zid> but even things like kernel structs bloating up because they *exist*, regardless of whether you use them
<zid> s/but/and/
<geist> so usually an interesting metric i like to eyeball when running older versios of BSD or linux is just fire up top and see what the average RSS is for things like init or shells, or whatnot
<geist> and sure enough between freebsd 6.4 and 13 it seems like the average program has at least doubled in size
<geist> but there aren't a substantially larger number of [processes at rest, because freebsd hasn't done much in that area, it seems
<zid> The PLT is a goodish example
<geist> fbsd 6.4 you could see the averge RSS of a sh or whatnot at just under 1MB. here it's more like 2.4MB
<zid> that shit be slow, we just don't care cus cpus are fast
<geist> yah totes
<geist> or alternatively we just statically link stuff or inline the crap out of it because on modern machines that's fast since they have the cache to soak it up
Lumia has quit [Quit: ,-]
<geist> but yeah i'm a little surprised i had 1GB in this old P4. i must have upgraded it somewhere along the way because no way did i pay for 1GB at the time. that would have been hella expensive. i think its the max this mobo takes
<zid> I don't think I remember what I had with my p4
<zid> just what I had with the q6600 I replaced it with, 4GB
<geist> probably 256 or 512 maybe
<zid> I think I maybe had 1GB
<zid> but I had late p4 not early p4, prescott 3.0GHz era
<geist> i do remember a few years prior the P3 had 128MB when i bought it
<zid> yea my celeron came with 128MB
<zid> It was later upgraded to 192MB
<geist> yah this is a midlife P4 apparently. early 2022, it seems. i waited until they had HT i think
<geist> wanted to replace a dual p3 with soething that at least looked like 2 cpus
<geist> 2002
<zid> 2200
<Matt|home> i read an article that had a rather conservative viewpoint on structs.. basically that they obfuscated code and should be avoided wherever possible.. also some garbage about fewer header files/dependencies/variable names
<Matt|home> i do agree that if you have a struct with more than a few elements.. that's probably too many though
<geist> heh, well folks are entited to opinions
<zid> They certainly are
<Matt|home> i've said it before, but the linux process struct is too complex
<zid> My fingernails taste really spicy
<zid> I think maybe my lips or fingers have chili on them
<geist> yah reminds me, i need to trim mine. they're too long today
<geist> wheres those clippers...
<Matt|home> i mean realistically how complex does a process need to be in order for it to be usable and not broken on a modern system
<Matt|home> surely not that much
<Matt|home> but yeah there seems to be extremes in terms of code design i'm noticing.. it usually seems like either "i have so much memory that i'll write my software needs 30 gigs of ram to operate comfortably" versus "it's 1969 and i _really_ need to make use of these last 8 bits.. memory doesn't grow on trees"
<Matt|home> im not a huge fan of the idea of letting the kernel determine what memory is _required_ , there really should be more constraints
<Matt|home> admittedly it'd be extremely unpopular if you wrote a web browser that only let you open two instances of it and maxed out at ten tabs each for example, but it'd still be a constraint
<geist> well, i think that's a bit unfair
<geist> i think modern software just geenrally expects more
<Matt|home> yeah but honestly there's a lot of unecessary bloat which could be gotten rid of
<geist> and given modern cpus you're not required to write stuff in the most size/space optimal, so if you use something inefficient to do it but you get it done, then that's it
<geist> oh sure but at the end of the day lots of stuff is some persons time
<Matt|home> ja
<geist> ie, if i write some app to do a thing that it uses a bunch of overbloated std:: stuff and i use the wrong algorithms and it hits the heap way too much
<geist> but no one cares, because it works just fine on anything reasonably modern then so be it
<Matt|home> i think for my userland i'll go with my approach to memory management.. something like, more restrictive than normal but with the right system calls or whatever you could get around it if you knew what you were doing
DanDan has quit [*.net *.split]
ptrc has quit [*.net *.split]
Killy has quit [*.net *.split]
ephemer0l has quit [*.net *.split]
clever has quit [*.net *.split]
mjg has quit [*.net *.split]
remexre has quit [*.net *.split]
sham1 has quit [*.net *.split]
zid has quit [*.net *.split]
ornitorrincos has quit [*.net *.split]
LittleFox has quit [*.net *.split]
lg has quit [*.net *.split]
kaichiuchi has quit [*.net *.split]
pitust has quit [*.net *.split]
hl has quit [*.net *.split]
amj has quit [*.net *.split]
danlarkin has quit [*.net *.split]
stephe has quit [*.net *.split]
<geist> like, i dunno, i'm writing some app that takes a bunch of files and intelligently renames them based on some pattern
pitust has joined #osdev
<geist> so, you can microoptimize the list of file names usig something that's small/fast, or yolo it, no one cares
<geist> because N is reasonable
stephe has joined #osdev
danlarkin has joined #osdev
<geist> so as you read the filenames in you put it ina std::vector and it keeps resizing itself. is that ideal? nope. who cares
<Matt|home> i can give you a very specific use case of somebody caring, because i was in that situation for the longest time :p
<geist> sure, there might be one, but just sayin that's a valid way to go about things
<Matt|home> where i was dirt poor and couldn't afford anything more modern than a 30 year old desktop for the longest time. so im pretty biased in that i admit
remexre has joined #osdev
ptrc has joined #osdev
ornitorrincos has joined #osdev
LittleFox has joined #osdev
hl has joined #osdev
<geist> yah
zid has joined #osdev
<zid> oh good, libera just exploded on me, several severs disconnected at connect, a couple got stuck during checking ident
<geist> this is me mostly personally coming to terms with the inevitable march of time. i *like* highly optimal 8 bit cpus and hand tuned assembly to fit in 256 bytes kinda stuff
amj has joined #osdev
<geist> yah looks like a split happened
<zid> Anyway, the main issue is that hardware and software just move too quickly now.
sham1 has joined #osdev
<geist> yah
<zid> Look at an early psx game vs a late psx game
<zid> exact same hardware
clever has joined #osdev
<geist> and security/safety is so important now it feels like it's hard to really enjoy building something with care
<zid> just because people had more time to spend learning what they could get away with within the budget
<geist> when that overrides everything
<zid> These days people just write everything in memory safe languages and raise the system specs if they picked a slow one
<zid> from a 1GHz core2 to a 1GHz i3
<zid> which is trivial amounts of performance
<geist> exactly
<geist> i'm saddened, but then being sad at that is ultimately fruitless
lg has joined #osdev
<zid> And if it isn't hw moving too quickly, it's the software moving too quickly
<zid> new version of chrome every 7 days
Killy has joined #osdev
<zid> can't stand around fixing bugs or making things faster, we have 14 new specs to write and implement
<geist> well, im fairly well aware of that (the whole chrome updating so fast). that's a very googly way of doing things
<geist> and its pretty bewildering
<zid> It's how people operate in general, google is just better at it
<zid> most people *try* to do it
<geist> but relies on insane amount of unit tests and internal testing
<zid> especially with the death of unix
<zid> where every application has to reimplement an entire OS by itself
<geist> yah
<Matt|home> <zid> new version of chrome every 7 days <-- if that's what chrome does then fuck that noise. also not a fan of bowing down to 10 unskippable ads in a row, so firefox all the way
<geist> sure but there are *good* reasons for that. it's not just about shoving ads down your throat
<geist> but it's so hard to maintain that sort of release cadence
<Matt|home> that's a little too insane for me imo, but hey it's their company
<sham1> It's not just about shoving ads down your throat, but it totally is
<kof123> eh, my wacky "filesystem" will have hundreds of functions (to get/set each field) ...that's surely slower, but i tend to do that anyways, since in "primitive" languages that is a step towards interceptor pattern via a function pointer, for example. or long ways away may make "RPC" easier. in any case, i just figured if calling c from asm, you seem to have to know e.g. padding of a struct, so at that point you are manually specifying it
<kof123> anyways (or the compiler dictates it)
<kof123> so ... i dont know how i feel about structs, but for that i am purposely avoiding for now
<kof123> i guess i try to do a middle road, overengineered meta but in an old language lol
<kof123> and overengineered gazillion features/fields, but optional. that leads to branchy code though surely
<kof123> or ifdef hell
<kof123> but then to keep it manageable, you can have a function that dispatches to x "Helper functions". i guess i dont care about overhead of many many small functions, if its a problem hopefully a compiler will inline etc. or i found "cmix" "function specializer" the other day :D
<kof123> TLDR: choose your battles
<sham1> A sufficiently smart compiler ought to inline
<kof123> " something like, more restrictive than normal but with the right system calls or whatever you could get around it " i guess i second that, but i am other way around: a gazillion features, but nearly all can be disabled if need be
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<kof123> *program specializer C-Mix: Making Easily Maintainable C-Programs run FAST The C-Mix Group, DIKU, University of Copenhagen you can find an ancient version and a paper or two :D the pdf paper has a contrived example, but should explain well what it does
<kof123> reminds me of what synthesis os supposedly did
<kof123> its another "middle road" IMO; write generic code, let the tooling make it fast
civa_ has quit [Quit: Leaving]
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mavhq has joined #osdev
epony has quit [Remote host closed the connection]
smach has joined #osdev
IRChatter0 has joined #osdev
IRChatter has quit [Ping timeout: 264 seconds]
IRChatter0 is now known as IRChatter
nyah has joined #osdev
jack_rabbit has quit [Quit: You have been kicked for being idle]
GeDaMo has joined #osdev
gog has joined #osdev
gog has quit [Client Quit]
bauen1 has quit [Ping timeout: 252 seconds]
DanDan has joined #osdev
smach has quit []
epony has joined #osdev
mjg_ has joined #osdev
Burgundy has joined #osdev
freakazoid332 has quit [Ping timeout: 250 seconds]
SpikeHeron has quit [Quit: WeeChat 3.7]
smach has joined #osdev
SpikeHeron has joined #osdev
bauen1 has joined #osdev
smach has quit []
<ddevault> fucking interrupts
<ddevault> help me sanity check my serial thing
<ddevault> I'm using qemu
<ddevault> I'm waiting for an interrupt from the serial port so I can write more data
<ddevault> IER has bits 0 and 1 both set
<ddevault> and LSR has THRE and TEMT set
<ddevault> yet, no interrupts
bauen1 has quit [Ping timeout: 264 seconds]
<ddevault> I have FIFOs enabled
<ddevault> startup sequence is IER <= 0; LCR <= 0x80; DL_LSB <= 1; DL_MSB <= 0; LCR <= 0x03; FCR <= 0xC7; IER <= ERBFI
<ddevault> then when the driver is asked to write something, it does x <= IER; x |= ETBEI; IER <= x
<ddevault> then waits for an interrupt that never comes
nanovad has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<ddevault> (first it checks for THRE in LSR and writes right away if the port is ready, though)
nanovad has joined #osdev
blockhead has left #osdev [#osdev]
kof123 has quit [Remote host closed the connection]
smach has joined #osdev
<Mutabah> ddevault: 1. Did you enable that interrupt on the PIC?
<ddevault> yes
<Mutabah> 2. Did you ACK the interrupt on the serial controller (e.g. by reading/writing the status?)
<ddevault> I checked that the IRQ is installed, and PS/2 IRQs have worked with the same method before
<Mutabah> (don't know that controller well enough to say with certainty)
<ddevault> as for acking the IRQ, I think so, but in any case I would assume at least one interrupt comes through
<ddevault> to be sure I read from LSR an extra time during setup
<ddevault> maybe I should read from IIR during initialization and process any interrupts which may already be pending during init
<kazinsal> uart on a legacy pic should be outb(0x20, 0x20) to ack the irq
<kazinsal> never seen a uart on the secondary pic
<ddevault> it's IRQ 3 and 4 iirc
<ddevault> 3 for this com port
eroux has quit [Ping timeout: 252 seconds]
eroux_ has joined #osdev
<ddevault> eagerly polling IIR & LSR before waiting for an interrupt does not have an effect
<Mutabah> Hmm... I think you need to read from the buffer (empty it)? to reset the interrupt?
<Mutabah> Oh, wait, you're doing tx
<Mutabah> Do you know the conditions for it to interrupt?
<ddevault> it should interrupt in this case if ETBEI is enabled in IER and the tx fifo is empty
<ddevault> if the fifo is empty LSR should read 0 in THRE
<ddevault> what I do is
<ddevault> 1. set up the port (using the sequence I described above)
<ddevault> 2. buffer data for write, which checks for THRE=0 in LSR, writes up to 16 bytes if true (and it is true initially), then enable ETBEI in IER if there's more data to write (and there is)
<ddevault> then it waits for an IRQ
<ddevault> the IRQ never arrives
<Mutabah> Fallback option: Read/modify the qemu source :)
<ddevault> haha
<Mutabah> (modify to add some extra logging)
<ddevault> true
<Mutabah> 100% serious
<ddevault> I know
smach has quit []
<ddevault> hum
<ddevault> if I'm reading this qemu code correctly
<ddevault> the receive interrupt is never raised if the FIFO is enabled
<ddevault> that does not seem right
Burgundy has left #osdev [#osdev]
smach has joined #osdev
Burgundy has joined #osdev
smach has quit [Remote host closed the connection]
shikhin is now known as handy
handy is now known as shikhin
xenos1984 has quit [Ping timeout: 260 seconds]
<ddevault> well, qemu thinks it should raise an IRQ
<ddevault> so why doesn't it actually happen...
<ddevault> I am so confused
xenos1984 has joined #osdev
smach has joined #osdev
<ddevault> it was masked on the PIC
smach has quit [Client Quit]
<ddevault> oddly I had ruled that out because in /b 0x20 on the qemu monitor reported 0
smach has joined #osdev
sav_ has joined #osdev
smach has quit [Client Quit]
sav_ has quit [Client Quit]
bauen1 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
frkzoid has joined #osdev
ephemer0l has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
civa has joined #osdev
poyking16 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
carbonfiber has joined #osdev
bauen1 has joined #osdev
kindofwonderful has joined #osdev
<kindofwonderful> Opertaing System Development
<kindofwonderful> how was your weekend ?
heat has joined #osdev
<heat> ddevault, did you give up on the i915 driver?
<kindofwonderful> i915 ? the wireless driver ?
<ddevault> heat: no
<ddevault> I haven't started it
<ddevault> but I still plan to write it
<ddevault> have some blockers to address first
<heat> ah cool cool
<kindofwonderful> i guess i need to re change my name
xvmt has joined #osdev
FreeFull has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
smach has joined #osdev
smach has quit [Client Quit]
smach has joined #osdev
smach has quit [Client Quit]
smach has joined #osdev
smach has quit [Read error: Connection reset by peer]
smach has joined #osdev
hellstabber5 has quit [Ping timeout: 248 seconds]
xenos1984 has quit [Ping timeout: 250 seconds]
smach has quit []
hellstabber has joined #osdev
frkzoid has left #osdev [Leaving]
gog has joined #osdev
xenos1984 has joined #osdev
hellstabber has quit [Quit: Textual IRC Client: www.textualapp.com]
y0m0n has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
dude12312414 has joined #osdev
gildasio has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
gildasio has joined #osdev
dude12312414 has quit [Ping timeout: 258 seconds]
* geist yawns
dude12312414 has joined #osdev
<geist> yay another monday
<mjg_> someone has a good case of the mondays?
<geist> well, i wouldnt say a good case, just... the monday's
liz has joined #osdev
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
antranigv has quit [Ping timeout: 252 seconds]
terminalpusher has joined #osdev
<sham1> Monday is fun when it results in a constant pattern of life
<geist> well it could be a sunday
<geist> that's my fun day
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid> do I get honzuki earlier or later when dst changes at the end of october, someone do math for me
<gog> geist: your "i don't have to run day"?
<geist> gog: ❤️
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
<heat> yes emojisssssssss
weinholt has joined #osdev
<heat> my mission today is to get my OS to build under my OS
<heat> for the street credz
<gog> i believe in you
<heat> thanks
<gog> :)
<heat> i also believe in whatever you're doing
<gog> cool, i'm actually doing a satanic ritual right now
<heat> nice
<heat> i believe in it
terminalpusher has quit [Remote host closed the connection]
<bslsk05> ​'Belial Behemoth Beelzebun Asmodeus Satanas Lucifer 😈' by Bobo Ellie Buns (00:00:14)
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
eroux_ has quit [Ping timeout: 268 seconds]
<heat> woah
<heat> i asked ya yesterday, what's it drawing on?
eroux has joined #osdev
smach has joined #osdev
<pbx> framebuffer device
<pbx> provided by the boot loader on x86, i do have a driver for the TI OMAP framebuffer on arm.
<heat> does it open /dev/fb0 or something?
<heat> (and mmap it I assume)
<pbx> yep. after a few ioctls to learn about the format
vdamewood has joined #osdev
eroux has quit [Ping timeout: 248 seconds]
eroux has joined #osdev
<heat> i get anxious running my linux system for too long
<heat> 244k pids is a lot :/
<heat> wait sorry
<heat> 2.4million pids lmao
eroux_ has joined #osdev
eroux has quit [Ping timeout: 250 seconds]
<heat> i'm still a good bit off the wrap around point but jeez i hate this
<heat> the poor system needs a reset
<acidx> heat: $ echo $$ -> 3741954
<heat> your warcrimes do not justify mine
<heat> up 2 weeks, 22 hours, 53 minutes
<acidx> 21:52:07 up 1667 days, 19:36, 11 users, load average: 0.04, 0.03, 0.00
<pbx> 137018 pts/5 00:00:00 bash
<pbx> 2421630 pts/5 00:00:00 ps
<pbx> lol
<acidx> I really need to reboot this machine but I'm lazy
<pbx> compiling big stuff tends to do that
y0m0n has left #osdev [#osdev]
<heat> i feel like my system is leaking memory
<heat> in a fully used state it fills up swap completely
<gog> i reboot every day
<heat> i don't reboot because I'm lazy
<Griwes> Swap? What's that
<Griwes> I simply have gigabytes of extra memory in my systems
<heat> send some my way
<heat> i take laptop ddr4 dimms
<gog> i want to upgrade to 32gib
<gog> no reason
<gog> i just can
<heat> i have 8 and its kinda enough and kinda not
<heat> it's workable
<Griwes> Sorry, all my laptop ddr4 is in this Mobile Workstation, providing its 128GB of ram
<heat> ................................
<heat> fuk u
<heat> is that the new zfs system requirement? :v
<Griwes> lol
<Griwes> ;D
poyking16 has quit [Quit: WeeChat 3.5]
<Griwes> No, but I happen to sometimes build things with nvcc on it
<heat> is nvcc memory hungry?
<gog> 8 wasn't enough
<gog> i have work to do and no time for paging
<heat> i had the idea nvcc is just a modified clang
atilla has joined #osdev
<atilla> whos doing riscv stuff here
<heat> lots of people
<heat> what's your question
<atilla> are you wearing pants right now?
<heat> i'll skip that question
<heat> for ...reasons
<atilla> ok. has anyone dabbled in multiprocessing in riscv?
<heat> not quite but i'm more or less aware of what you need
<heat> what's your specific question?
heat has quit [Remote host closed the connection]
heat has joined #osdev
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #osdev
<mats1> what else are you wearing?
<kindofwonderful> pedro
<kindofwonderful> shit i just hope im not /ignored by heat.. seems like a guy who i need in one of the days
<heat> a gimp suit
<Griwes> heat: yes to the first and no to the second lol. nvcc is an EDG frontend that parses code and generates a different form of that code that are then fed to another EDG frontent per target arch and also a host compiler
<Griwes> But while nvcc is often a culprit because it literallty compiles the same code many many times and isn't particularly efficient at it, there's also ptxas that is invoked by nvcc
<Griwes> And despite the name, ptxas is actually an optimizing compiler that Goes Too Hard quite often
<heat> so why are you not using clang's nvidia support? that seems horrible lmao
<Griwes> Because clang cuda is, arguably, worse lol
<Griwes> And also our customers primarily use nvcc :P
<heat> maintaining a separate compiler that branches into more compilers and takes a lot of memory and isn't efficient is... yay?
<heat> make nvcc a clang fork ggez
<Griwes> Ideally yes, but there's so much more nuance to deal with there lol
<Griwes> Ask me in 5 years and maybe by then we will have shipped some things we are working on and planning to work on :V
<heat> !RemindMe 5 years
<heat> wait, this isn't reddit?
<heat> r/LostRedditors
<heat> you should like, totally break your customers
<heat> that's what they like
rurtty has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.7]
<geist> atilla: did you have a question? heat and I absolutely have dabbled in multiprocessing
SpikeHeron has joined #osdev
<heat> was I the only one who noticed their name....
<kindofwonderful> is there a way to determine the native character set of a machine ?
FreeFull has quit []