<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
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
<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]
<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 ?