<LittleFox>
(like if you need a network driver and nfsroot or whatever
<LittleFox>
hihi
<LittleFox>
yes
<LittleFox>
geist
<geist>
also on that topic, qemu's implementation of?
<geist>
the transport is usually virtio-9p right?
<LittleFox>
LF OS fs is all going to be 9p via IPC messages, have a lib9p written already - doing a lot of things but not complete
<doug16k>
I peeked at it. seems elegant
<LittleFox>
ah pci transport, right?
<geist>
i dunno!
<LittleFox>
only looked at tcp and LF OS ipc transports for now
<geist>
anyway, i guess the question is is it worth putting time into it?
<LittleFox>
it looks nice
<geist>
someone at work asked about it, and it seems like maybe a decent thing to implement
<LittleFox>
but the 9P2000 I implemented for now lacks some things, I hope the newer ones don't make it a mess to provide those things
<doug16k>
windows recently implemented it right? for WSL?
<LittleFox>
I think, yes
<LittleFox>
was my big hope to get virtio-fs in windows
<LittleFox>
x)
<geist>
unclear to me how it is supposed to stay in sync with house file changes?
<geist>
host
<LittleFox>
well its a network filesystem
<LittleFox>
same problem as always
<LittleFox>
you either cache and have performance and problems
<LittleFox>
or you don't cache and its correct
<geist>
sure but it seemed pretty simple so it didn't have a notion of oplocks or whatnot, which can be used for that sort of stuff
<LittleFox>
but slow(er)
<doug16k>
LittleFox, yes but there are places between those extremes
iorem has joined #osdev
<geist>
exactly
<LittleFox>
hmyes
<LittleFox>
I think I saw extensions somewhere
<LittleFox>
like linux not really using the original 9p messages if possible?
Arthuria has quit [Ping timeout: 244 seconds]
<doug16k>
something like windows "oplock" where you can acquire a range of a file for ownership and cache it locally. if someone else goes to read it, it sends you an oplock break, and you writeback - just like cpu cache coherency
<doug16k>
then you cache locally and there can be a far away potentially incoherent copy
<bslsk05>
ericvh.github.io: Plan 9 Remote Resource Protocol Unix Extension
<doug16k>
you mean those extensions?
<doug16k>
it seems so simple
<LittleFox>
no the .L ones especially
<LittleFox>
ah .u was the one with numeric uid/gid/muid
<LittleFox>
(I need that one in the near future I fear ^^')
<LittleFox>
there is also one for 64bit timestmaps, .u still has 32bit like 9P2000
<doug16k>
now I realize it is same thing as I linked, yours is newer
<LittleFox>
my link also includes .L, another extension - Linux specific originally
<doug16k>
look at 7.1 of my link
<LittleFox>
sec
<doug16k>
it's the version packet
<LittleFox>
yes?
<LittleFox>
defining the semantics for extensions
<LittleFox>
but what do you want to say to me with that?^^'
<doug16k>
nothing. I was elaborating on <doug16k> now I realize it is same thing as I linked, yours is newer
<LittleFox>
ah
<LittleFox>
confused Fox sometimes, sorry
<doug16k>
yeah i was confusing, sorry
<doug16k>
those locks are only advisory though right?
<LittleFox>
hm don't know
<doug16k>
there isn't a mandatory lock anywhere is there?
<doug16k>
it would have to be mandatory if you are going to introduce aggressive caching wouldn't it?
<LittleFox>
hm yes
<LittleFox>
its describes as being like fcntl(F_SETLK) so yes
<LittleFox>
sorry out of knowledge here ^^'
<LittleFox>
"The Linux v9fs client translates BSD advisory locks (flock) to whole-file POSIX record locks. v9fs does not implement mandatory locks and will return ENOLCK if use is attempted." even directly written in that doc
<doug16k>
you can lock a range of a file, but it only synchronizes with other programs that may have also locked that range. anyone can go trample it
orthoplex64 has joined #osdev
<doug16k>
fcntl setlk are reader/writer locks
<doug16k>
i.e. you can acquire shared ownership that locks out writers, or you can lock out readers and be the exclusive writer
<doug16k>
for each range
<LittleFox>
I guess the real fun is when ranges overlap but aren't the same
<doug16k>
it's fairly straightforward if you have a tree data structure and keep the locks sorted by offset
<doug16k>
then you can warp speed to the relevant node and look at its neighbours
<doug16k>
since they overlap, yeah it isn't that easy
<doug16k>
I should look how I did it
<doug16k>
I completely forget!
<doug16k>
ah, not finished is why
<LittleFox>
:D
<doug16k>
it's mostly done
<doug16k>
I think I realized that overlapping range thing and stopped to think about it
<doug16k>
the query you need is (ranges that start before A) & (ranges that end after B) then look at those
<doug16k>
B+ tree loves that kind of query
<doug16k>
don't have one yet
<doug16k>
probably don't need to go that far though
<doug16k>
a simple vector will be unbeatable up to some number of locks
<doug16k>
to lock range A to B you need to check all existing ranges that end after A and begin before B
mahmutov_ has quit [Ping timeout: 244 seconds]
<doug16k>
what are you supposed to do if SEEK_CUR current_offset + lseek_offset is signed overflow?
<doug16k>
screw up like everyone else? :P
<geist>
nice. i love to nerd snipe a topic, then walk away and come back an hour later after everyone has discussed it to death
<geist>
advanced information gathering
<moon-child>
with 32-bit?
<doug16k>
moon-child, any bit, really
<moon-child>
use 64-bit ints anyway
<moon-child>
64-bit overflow not really worth handling
<doug16k>
they can't overflow?
<doug16k>
what if the caller is a comedian?
vdamewood has joined #osdev
<doug16k>
if I seek to 0x7ffffffffffff000, then flock 8K, does that lock 0x7ffffffffffff000-0x7fffffffffffffff AND 0x0-0xFFF ?
<gog>
a dword and a qword walk into a BAR
<doug16k>
or just screw up?
<gog>
i don't have a punchline
<geist>
i've been trying to think of a pun involving msi or pio or something
<geist>
but really coming up blank
<geist>
i guess i'll see myself OUT
<vdamewood>
We should call 80 bits an fword.
<moon-child>
doug16k: if you do standard higher/lower half then you don't ever have to worry about overflow yielding a valid pointer
<geist>
fun thing i learned from reading 68k manual recently
isaacwoods has quit [Quit: WeeChat 3.1]
<doug16k>
moon-child, file pointer
<geist>
not to be outdone by x86, 68k has a 96bit float
<geist>
take that x87!
<moon-child>
is it worth supporting 64-bit-sized files? Seems kinda excessive
<moon-child>
imo
<doug16k>
4G is too small
<geist>
64 may be a bit excessive, but it's the next size up
<moon-child>
yeah. So you use 64-bit offsets even in 32-bit. Let the compiler sort it out
<geist>
unless the inode wants to use the top 8 or 16 bits or something
<moon-child>
(I mean, 64-bit offset, max filesz less than 64 bits)
<geist>
also in the case of sparse files, it's actually entirely plausible that you create and use an excessively sized file
<doug16k>
something always limits it way under actual 64 bit sizes, yeah
<geist>
though generally bad idea, etc
<moon-child>
geist: large yes, but I think it's reasonable to cap it below the full 64-bit range
<moon-child>
bbiab
<doug16k>
yeah, what happens to the seek position if you write one byte at offset 0x7fffffffffffffff?
<geist>
63 certainly helps since that avoids the whole negative space issue
<doug16k>
signed overflow is what happens
<doug16k>
I am looking at my code for that right now and my eyes are seeing maybe overflow all through the seek position stuff
<geist>
by simply disallowed negatively signed files it at least helps trap a lot of those sort of errors
<geist>
since it'd be officially not allowed
<geist>
also gives you a proper signed off_t that can hold all of file_size_t
<doug16k>
why does that help? not being negative doesn't solve much
<geist>
though i guess off_t as a file size works too, but only define as the positive part of it
<doug16k>
locks are {offset,length}. each one might signed overflow
<geist>
(if off_t is defined as 64bit signed)
<doug16k>
I guess what I am saying is, is it okay to just error signed overflow, or do you have to truncate
<doug16k>
on file offset updates
<doug16k>
doesn't flock need to be able to lock negative seek space?
<doug16k>
or am I mixing it up with windows mandatory-only locks and the huge offset you add to make it not really the file, to simulate advisory
<doug16k>
yes, linux fcntl disallows negative space locks "...but not bytes before the start of the file."
gog has quit [Quit: bye]
<doug16k>
arbitrarily it seems
<doug16k>
no reason not to allow it
<doug16k>
I'm not prejudiced against negative numbers. I like negative numbers
<bslsk05>
gist.github.com: Find first erring seek position · GitHub
<doug16k>
not likely to matter, but the filesystem I tested on is 1TB
<doug16k>
sucks for an API like file lock to expose you to the filesystem
<doug16k>
filesystem has nothing to do with it imho
<doug16k>
locks are imaginary
<doug16k>
seek position is imaginary too
<doug16k>
filesystem has nothing to do with locks in my implementation
<kazinsal>
I've just got home from a two hour walk in which I smoked several bowls, with big plans for OS stuff to work on, and I've discovered a box of cookies I forgot that I'd bought
<kazinsal>
happy weekend, #osdev
<doug16k>
all the performance enhancers at once
<kazinsal>
considering I'm planning on writing an optimized route lookup system, very much so
<johnjay>
okular lets you add bookmarks to pdf. why did i not know this
<doug16k>
why print help to stderr. is that all errors? no!
<doug16k>
2>&1 party
<johnjay>
i always wondered that at first. why not put it all on same file handle
<doug16k>
the error channel being separate is great
<doug16k>
you can send the data to stdout, and all the complaints to stderr
<doug16k>
if --help is an invalid parameter and your "error message" is hacked in to be the reply as the help output, and that goes to stderr, then your program is a hack :D
<doug16k>
I love how it folds everything into one case, but don't get carried away, there are cases
<doug16k>
don't you pipe --help to less sometimes?
<doug16k>
I avoid the terminal scrollback, tiring on hands
<kingoffrance>
all the time, and yes stuff like that is annoying when it goes to err
<kingoffrance>
ideally in magic land help output would be standard format (or an option for "machine readable" maybe) so tools/scripts could parse it and see what a command supports easily
<kingoffrance>
some commands i guess kind of do "compiled with options: <long list>"
<kingoffrance>
like vim and such
<doug16k>
powershell did that by making it objects going to input and output, not characters
<doug16k>
then pipe into formatters
<kingoffrance>
yeah, i havent messed with stuff like that so i am somewhat weary, nevertheless low hanging fruit general idea i think can still be done with just "plaintext"
<kingoffrance>
the original pipeline idea was more involved, but i dont recall details
<kingoffrance>
so one could argue the prevalent notion is already "toned down" version
<doug16k>
yeah, you can deal with plaintext well enough
<doug16k>
the humans like it
<doug16k>
does this say that adding 1 to INT64_MAX gives INT64_MIN result if it were the same type as type1 and type2 ? (but returns true too in that case)
<bslsk05>
gcc.gnu.org: Integer Overflow Builtins (Using the GNU Compiler Collection (GCC))
<doug16k>
the cast implies it truncates
<doug16k>
yeah
<doug16k>
in my kernel, the file offset can be 0 to INT64_MAX. I just added all the EINVAL checks for overflowing pos+size and pos+offset
<doug16k>
if the filesystem can't handle over 64KB in a file, you can still flock_ex a byte at 0x7fffffffffffffff
<doug16k>
wait, at ...fffe
<doug16k>
...fff + 1 is overflow
ZipCPU has joined #osdev
<doug16k>
I'm wondering when compilers are going to generate an abort/#ud when you do 1 << 31
<doug16k>
technically, they are allowed
<geist>
interesting, 68k solves the 'interrupt just before halt' problem by having the STOP opcode take an immediate value which is what to load into the SR register
<geist>
and the SR register contains the user/supervisor mode + interrupt disable flags, etc
<geist>
so basically you can simultaneously mask/unmask irqs and halt the cpu
dh` has joined #osdev
<doug16k>
which powerpc is the one amiga used right before the end?
<doug16k>
I should just look at all the machine init and pick nice modern one
chin123 has quit [Remote host closed the connection]
chin123 has joined #osdev
<doug16k>
ah, the most obvious one: ppce500 generic paravirt e500 platform
<doug16k>
ah, that machine absolutely requires ppc64
<doug16k>
requires 64 bit mmu
<kingoffrance>
summoning geist for vax questions is one thing, summoning Belxjander for amiga questions i dunno, maybe you need to play the right module
sprocklem is now known as sprock
<geist>
doug16k: in general 601 was the first, then 603 is where it started looking like a real thing
<geist>
then 604, 750, 7450, 950, etc
<geist>
there are later ones that are more for an embedded thing
<geist>
as well as cell processors and whatot
<geist>
and at the same time IBM was developing POWER line, which PPC and POWER have traditionally had a complex relationship, though later versions of the architecture spec merged
<geist>
in apple parlance, G3 = 750, G4 = 7450, G5 = IBM 970
<geist>
(not 950, 970)
<geist>
like lots of risc machines, 64 is not much different from 32, just a mode bit and then more bits in the registers
<geist>
since it is condition flag based you have to at least tell it what mode its in so it knows where the sign bit is and whatnot, but otherwise the ISA is pretty similar
<geist>
threre was a period in the mid 2000s where i actually had more PPC machies in my house than x86. still have most of them, but that was a brief period
piotr_ has quit [Ping timeout: 268 seconds]
<doug16k>
yeah I just figured out a moment ago (before tabbing back to irc) that 604 is the default
<doug16k>
in qemu
<geist>
yah thats a reasonable ppc32
<geist>
pre all the vector bits, basic powerpc
<doug16k>
haha, I am poking around trying to pick a machine and cpu combo and just got: qemu-system-ppc: RAM size incompatible with this board. Try again with something else, like 192 MB
<geist>
yah there isn't a real good default machine ther
<doug16k>
if I want to use 604, the only -M that works are 40p g3beige mac99
<kingoffrance>
i thought oldworld mac was called nubus :)
<kingoffrance>
there was mklinux :)
<geist>
that was the 68k stuff
<kingoffrance>
:/ so theres 2 old worlds :/
<kingoffrance>
*at least 2
<geist>
yeah, but i think they stopped using *world after ppc
<geist>
it was oldworld and nuworld and then intel
<kingoffrance>
:/ i had a 603 or 604 at one point, i remember because i built a linux from scratch (because not many mklinux at that time, was already dead) and wanted to "optimize" it lol it was crashy, but it built. i think i had busybox maybe.
<bslsk05>
en.wikipedia.org: BootX (Apple) - Wikipedia
<doug16k>
`info roms` says nothing!
<kingoffrance>
#@#$$#$@#$@
<kingoffrance>
anyway "For the similarly-named bootloader that is one of the bootloaders that enables Old World PowerPC Macintoshes to boot native (i.e. non-MkLinux) Linux, please see BootX (Linux)."
<kingoffrance>
so i dunno, some ppl call ppc stuff "old world" too
<kingoffrance>
not saying thats right, just where i got it from
<doug16k>
qemu does
<doug16k>
powermac is "oldworld" in their code
<doug16k>
idk if it is right either
<kingoffrance>
that one says "non-mklinux" so i dunno, i had to go to sourceforge to get kernel and/or patches IIRC, it wasnt mainline whatever i did, probably 2.4.x -- so maybe mklinux is what i am wrong on
<kingoffrance>
i did use bootx though, anyways
GreaseMonkey has joined #osdev
<kingoffrance>
i just found an old mac someone was throwing out and it was free, is only reason i did all that years ago
aerona has quit [Quit: Leaving]
<doug16k>
oh wow. you can't load a -bios. it ignores it. it must be -kernel. wtf?
<doug16k>
I mean, it's even a uboot bin file with the header
<doug16k>
it's a bios
<doug16k>
now I have to configure which option loads it lol
<doug16k>
-bios or -kernel
<doug16k>
I wonder if I just put both
<doug16k>
it's no wonder nothing is in memory, lol
<doug16k>
it's fun to watch the list of symbols get loaded by qemu in gdb
<doug16k>
I didn't see libencylopaediabrittanica go by, but it might be there
<doug16k>
oh I see what's going on. there is no rom on that machine. it just miraculously has the firmware in ram at power up
<doug16k>
dumb
<doug16k>
my rom header is silly and thinks it loads at 0xffe00000 and is 2MB and enters at 0xfff00100
<doug16k>
doesn't matter I guess
<doug16k>
that may be why it doesn't use -bios
lleo has joined #osdev
<kingoffrance>
quoth Aside from PCI/NuBus, the other major hardware division is "New World", meaning iMac and later, and "Old World", meaning pre-iMac.
gmacd has quit [Remote host closed the connection]
<doug16k>
ref405ep is working on a bunch of cpus
<doug16k>
I appreciate the suggestion though. I didn't know where to begin before
<doug16k>
that one is 128MB only. wow
<doug16k>
good enough
<doug16k>
my standards are getting lower by the minute :P
<doug16k>
give me a 64KB one that disassembles and I'll be happy at this point
<j`ey>
lol D:
<kingoffrance>
https://github.com/landley/aboriginal/tree/master/sources/targets used qemu machine "g3beige" but youll have to see how it built gcc etc. and used musl and uclibc the 440fp has CONFIG_BAMBOO=y (linux kernel option) the other does not no idea about gdb and objdump
<bslsk05>
github.com: aboriginal/sources/targets at master · landley/aboriginal · GitHub
<kingoffrance>
basically old, but something that should've worked at some point
<kingoffrance>
worked with qemu i mean
<kingoffrance>
quote what it was Aboriginal Linux is a shell script that builds the smallest/simplest linux system capable of rebuilding itself from source code. This currently requires seven packages: linux, busybox, uClibc, binutils, gcc, make, and bash. The results are packaged into a system image with shell scripts to boot it under QEMU. (It works fine on real hardware too.)
<moon-child>
I'm pretty sure gcc itself depends on a buttload of other junk
<kingoffrance>
this was old, that might've been true :)
<moon-child>
(though maybe patched?)
<moon-child>
ah, that too
<doug16k>
I must have disassembly to work with an assembly language I know next to nothing about
<doug16k>
if qemu can'
<doug16k>
t disassemble it, I'm guessing it can't execute it
<doug16k>
the bytes are the right bytes, matching the gibberish that objdump says
<doug16k>
qemu disassembles to same gibberish
<doug16k>
I should just drop ppc
<doug16k>
trainwreck arch
<j`ey>
have you done m68k yet? :P
<doug16k>
no pci
<doug16k>
I could make it work though
<doug16k>
mips64el is weird!
<doug16k>
ide, fdc, rtc, dma-chan, dma-cont, pic, .... think is a PC!
<doug16k>
thing
<doug16k>
you access the I/O with an MMIO window
<doug16k>
PIC though? wow
<doug16k>
how?
<doug16k>
what does the bus cycle to get the vector?
<doug16k>
imagine you don't? you could read the in-service register!
<doug16k>
hey if you have a pc-only os project, it looks like most of your stuff would port over to mips64el "malta" board without too much work, from the I/O list
<doug16k>
even i8042, parallel, cirrus logic vga, acpi
<doug16k>
I bet they even connected the IRQs to the PIC the way you would on a PC
<doug16k>
j`ey, I intend to get m68k to work, once I have at least a few of the generic pci ones working
<j`ey>
so mips next? seems like you think it's PC like :P
<doug16k>
it isn't
<doug16k>
the malta board it defaults to it
<doug16k>
is
<doug16k>
I don't care about it being pc like for this
<j`ey>
true
<doug16k>
I was just pointing out that it's practically a PC if someone wanted to try moving their stuff to another arch without having to do the driver part
<doug16k>
even the keyboard stuff would port over
<doug16k>
and pic
<doug16k>
can you believe pic?
<doug16k>
isa dma chip is there. has the dma registers for the upper 8 bits of each channel
<doug16k>
fdc?! I can't believe how much pc is there
<doug16k>
so probably fdc dma works with isa dma
<doug16k>
funny how they never had a fancy host controller with rings and autonomous operation for floppies
<doug16k>
what did old apple use for floppy interface?
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<doug16k>
the same as disk format as PC
<doug16k>
different filesystem of course
<sortie>
Hello
* sortie
has coffee
<sortie>
osdev on a Saturday? It's more likely than you think!
<doug16k>
since upgrading to 11.1.0, it broke my uefi. I figured out why. it was setting the first section LMA and VMA to zero no matter what I did in linker script. I put a dummy section that eats 16 bytes as first section, look what it does now: https://gist.github.com/doug65536/6eb5ba42b345aaef855449ac5eba335d
<doug16k>
how stupid is it for the debug sections to be first? extremely. they are stripped from one efi sees
<doug16k>
ld is asinine
<doug16k>
I could make the base 3ffff0 and strip off that stupid .victim section and it all lines up as intended
<geist>
yah i did a LK hack to the malta board a while back
<geist>
pretty strange
<geist>
however, i've actually seen that sort of thing twice in person: Sun Blade 100 and a PPC board.. what was it called
<geist>
there was a period there in the early 2000s when you could basically take a standard PC south bridge and hook it up to whatever PCI bus your cpu implemented, even if it wasn't x86
<sortie>
Me: Carefully writes securely written IP layer.
<geist>
so the sun blade 1000 was a ultrasparc IIe (single chip soc sparc + PCI bus) that had a standard VIA southbridge on it
<sortie>
Contributor: Packet of doom.
<geist>
the ppc machine i forget what it was. i had one for a while
<geist>
but it was basically same thing. some embedded PPC + generic southbridge
<geist>
had all the old 640k memory hole and whatnot to make it happy
<geist>
anywaym, a malta was probably the same thing
<doug16k>
makes sense
Arthuria has joined #osdev
<doug16k>
probably lowered cost a lot
<geist>
Pegasos II! that's what it was
<geist>
some european company made them, tried to sell them
<geist>
not sure they survived that long
<geist>
i had one for a while until it died
<doug16k>
they totally broke my efi bootloader build in gcc 11.1.0
<bslsk05>
lore.kernel.org: [PATCH] x86/setup: Document that Windows reserves the first MiB - Borislav Petkov
<j`ey>
apparently windows reser.. well bslsk05 said it
<j`ey>
"Unconditionally reserve the entire first 1M of RAM because BIOSes are known to corrupt low memory"
<doug16k>
I reserve the first MB after it gets going
<doug16k>
you must use 1st MB for SMP start
<j`ey>
yeah, i remembered that, so i wonder what this BIOS corruption actually means
<j`ey>
idk, dont fully understand it
<doug16k>
it means some idiotic code writes to addresses below 1MB when it shouldn't
<doug16k>
some stupid buggy code accidentally corrupts your data and they didn't notice
bsdband55 has joined #osdev
<j`ey>
that makes it worrying for the SMP startup!
<doug16k>
well, not *that* often
<j`ey>
heh
<doug16k>
over a long time period the odds get good
lleo has quit [Read error: Connection reset by peer]
<doug16k>
if your machine's firmware exhibits the issue
<j`ey>
just reboot and hope for the best!
<doug16k>
that patch is just the usual hatefulness of linux devs
<doug16k>
some infinitesimal, but nonzero number of machines do that and they get all pissy
<j`ey>
but.. you also reserve 1mb lol
Burgundy has joined #osdev
<doug16k>
not because of that
<doug16k>
because the cpu has a harder time determining the memory type of memory accesses below 2M
<j`ey>
oh is this the MTRR thingymabob?
<doug16k>
because it has workaround to deal with broken code that overlaps I/O region MTRRs with large WB pages
<doug16k>
ya
Chankra has joined #osdev
<doug16k>
it's like spelling. eventually that broken code isn't broken anymore, because they made it work, in spite of their manuals always saying that is UB
<Chankra>
Hello. I will invent an operating system. Is it a good approach to take, let for example, Unix 32/V, and port it to the i386 or to EM64T, as a way to learn how to do the operating system developments?
<doug16k>
now overlapping fixed MTRR region is correct spelling
<j`ey>
heh
<Chankra>
My theses; I will learn how the real OS (Unix 32/V) works. But also I will learning how the i386 or EM64T works. Yes, I will learn how to program its interrupt controller, how to use the MMU (for Unix 32/V expect one), I will learn all kind of thing about the i386 computer and her hardware when I try to port the Unix
<doug16k>
they doubled down on their insistence that page tables and MTRR are *really* UB above 2M line :P
<doug16k>
if they conflict
<j`ey>
Chankra: is that Unix mostly in C?
<j`ey>
Chankra: does it actually have an arch/ folder, for keeping stuff modularised?
<doug16k>
Chankra, you have to do the whole port to start testing anything that way, don't you?
<Chankra>
j`ey: It have a file "machdep.c" where it have routines for thing like signal a process, map physical memory into a process virtual address space, startup the system, create a copy-on-write clone of the parent process address space. And some assembly language file too. I think, that these are where most of architecture depending code is
<j`ey>
machdep, sounds like bsd
<Chankra>
Unix 32/v is the OS, which the BSD came out of by forking it
<doug16k>
Chankra, I think you'll learn about porting that particular kernel, mostly
<doug16k>
what would you learn about "operating systems" from that?
<doug16k>
you would learn good stuff though
<doug16k>
the context switching and manipulation of virtual memory
<Chankra>
doug16k: I will learn to the low-level hardware of i386, and I will be force to become dearly familiar to Unix 32/V, and then I will know, "This is how the real OS work"
<doug16k>
if you want to learn x86 hardware, you should just make your own kernel from scratch
<doug16k>
then it isn't utterly overwhelming at the start
bsdband55 has quit [Read error: Connection reset by peer]
<Chankra>
Then I set project series to enhance the ported OS. I schould add the Kqueue event multiplexer, or I should invent a good virtual memory management system and make mmap, or any thing which I will want do to enhance
<doug16k>
you can incrementally introduce more and more, once you get stuff working
<V>
Chankra: that OS is ancient, not really representative of what a real operating system will look like. the code will likely be an awful introduction (it'll use a very old dialect of C, and likely is filled with very poor practices for today's standards)
<Chankra>
doug16k: Yes, that is what I want do, incrementally enhance the Unix 32/V, and eventually I have rewrited almost it all
<doug16k>
Chankra, how many years is this plan?
<V>
lol
<V>
just don't do it. write a thing from scratch
<Chankra>
I take as many years as it will need to learn it truly. But the Unix 32/v has small code, so it is not big and confusing to understand
<doug16k>
Chankra, you are the perfect person to write it from scratch, since you want to learn the actual hardware, not try to skip everything
<Chankra>
You think it will be better to start from zero, truly? I can try to
<V>
Yeah, going with a preëxisting piece of software will lock you into its design choices
<V>
And that's not a good thing given how ancient this is
<doug16k>
Chankra, you can be up and running with a multiboot kernel without too much trouble, then you just get started. you need to be able to print messages to serial and read input, so figure out something for that. once that works, maybe get the display working
<doug16k>
get interrupts working
<doug16k>
get PS/2 keyboard and mouse working
<doug16k>
up to your neck in x86 by then
<GeDaMo>
Too late to turn back :|
<doug16k>
eventually get to PCI and PCIe and MSI and MSI-X and IOAPIC and SMP and routing IRQs to particular CPUs, make a bunch of drivers
<doug16k>
you should be a pretty competent programmer already
<doug16k>
the bugs can be mind blowing
<GeDaMo>
osdev: where print debugging is a luxury :P
immibis has quit [Remote host closed the connection]
Burgundy has left #osdev [#osdev]
<doug16k>
and you might not even have a stack, at all
Burgundy has joined #osdev
<j`ey>
stack? that's just a software convention
<GeDaMo>
No call. Only jump. :|
<doug16k>
I should look through some of these old unix
<klange>
<dog saying "no take! only throw!" except it's "no call! only jump">
<V>
that image was in my head :p
amanita_ has joined #osdev
<doug16k>
that code wouldn't even compile now
<Chankra>
Thanks for you suggestions doug16k. I will try your order of work. I wonder what bibles are good for to learn OS architecture. So far: I study McKusick's "Design and Implementation FreeBSD Operating System" and Tanenbom's "Operating System Design and Implementation" (he write about Minix.) I also keep some reference manual on i386 and EM64T
<bslsk05>
danistefanovic/build-your-own-x - 🤓 Build your own (insert technology here) (9697 forks/109353 stargazers)
<doug16k>
is one of them, "build your own github forking sock puppet" :P
<Chankra>
The Minix book has great depth of knowledge although the Minix seem to be simplistic. While FreeBSD book has good overview of things used in a very efficient and modern OS. I study very carefully the chapter on the Mach virtual memory manager. how it is highly portable, and it is the basis of FreeBSD's VM system. I think, that I will take special interest in it
immibis has joined #osdev
pretty_dumm_guy has joined #osdev
mahmutov_ has quit [Ping timeout: 244 seconds]
isaacwoods has joined #osdev
IRCMonkey has joined #osdev
IRCMonkey has quit [Client Quit]
IRCMonkey has joined #osdev
bsdbandit01 has joined #osdev
nyah has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
f4t4l_3rr0r has joined #osdev
f4t4l_3rr0r has quit [Client Quit]
IRCMonkey has quit [Ping timeout: 268 seconds]
maksy has joined #osdev
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
piotr_ has joined #osdev
andydude has joined #osdev
mahmutov_ has joined #osdev
IRCMonkey has joined #osdev
dennis95 has joined #osdev
jaevanko has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
andydude_ has joined #osdev
mahmutov has joined #osdev
yomon has joined #osdev
z_is_stimky_ has joined #osdev
immibis_ has joined #osdev
nyah has quit [*.net *.split]
andydude has quit [*.net *.split]
jaevanko has quit [*.net *.split]
mahmutov_ has quit [*.net *.split]
Burgundy has quit [*.net *.split]
z_is_stimky has quit [*.net *.split]
sortie has quit [*.net *.split]
immibis has quit [*.net *.split]
andydude_ is now known as andydude
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-rc1]
iorem has quit [Ping timeout: 252 seconds]
vdamewood has joined #osdev
flx has quit [Ping timeout: 272 seconds]
vinleod has joined #osdev
vdamewood is now known as Guest8105
Guest8105 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
asymptotically has joined #osdev
mahmutov has quit [Ping timeout: 268 seconds]
z_is_stimky_ is now known as z_is_stimky
dutch has quit [Quit: WeeChat 3.1]
bsdbandit01 has quit [Read error: Connection reset by peer]
<johnjay>
according to rdepends the gnulib package depends on the automake packages. even though gnulib is intended to just be random stuff you copy into your project.
dutch has joined #osdev
Lucretia has quit [Quit: Konversation terminated!]
immibis_ is now known as immibis
bsdbandit01 has joined #osdev
Lucretia has joined #osdev
Chankra has quit [Quit: CGI:IRC (Session timeout)]
bsdbandit01 has quit [Read error: Connection reset by peer]
lleo has joined #osdev
jaevanko has joined #osdev
piotr_ has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bsdbandit01 has joined #osdev
mahmutov has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
* sortie
writes sort(1)
<sortie>
TITLE SEQUENCE
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
Arthuria has quit [Ping timeout: 244 seconds]
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
IRCMonkey has joined #osdev
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
IRCMonkey has quit [Quit: .oO (bbl tc folks~!)]
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
pretty_dumm_guy has joined #osdev
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
flx has joined #osdev
* sortie
implements sort -h, a more humane sort.
skipwich has quit [Ping timeout: 252 seconds]
gareppa has joined #osdev
GeDaMo has quit [Ping timeout: 268 seconds]
vdamewood has joined #osdev
GeDaMo has joined #osdev
<geist>
good afternoon, fronds
<kazinsal>
buenos ding dong diddly dias
<gog>
goðan daginn
gareppa has quit [Quit: Leaving]
<kazinsal>
dammit. it looks like wt might not actually properly support changing the text colour in response to a vt100 bold command
<kazinsal>
this is really annoying because wt is also capable of running HLSL shaders over the terminal window, so I've got a really nice VT terminal effect but I can't make bold text brighter
<kazinsal>
it also seems to slightly be off on how it counts row height so an 80x24 screen with a fixed bitmap font isn't really actually 80x24. disappointing
<kazinsal>
hopefully they'll fix that eventually. back to boring ol' putty
GeDaMo has quit [Quit: Leaving.]
diamondbond has joined #osdev
diamondbond has quit [Read error: Connection reset by peer]
<gog>
without the shortcomings of conhost ansi support
bsdbandit01 has joined #osdev
bsdbandit01 has quit [Read error: Connection reset by peer]
<maurer>
I'm writing up a thing and am interested in any well regarded writeups of the dangers of C++ exceptions in embedded/kernel.
<maurer>
Anyone have anything?
<maurer>
(Or on the other side encouraging them I suppose, though I doubt that those are as common)
gog has quit [Ping timeout: 264 seconds]
Arthuria has joined #osdev
yomon has quit [Remote host closed the connection]
Burgundy has joined #osdev
asymptotically has quit [Quit: Leaving]
dennis95 has quit [Quit: Leaving]
<kazinsal>
gog: Oh wow, I recognize the name of the guy who wrote that haha
<doug16k>
maurer, catching them isn't the good part. the good part is the cleanups that run, unlocking/releasing RAII on the way
<maurer>
doug16k: Sure, but for that to be safe, 100% of your resources must be under RAII paradigm
<doug16k>
they are, obviously
<maurer>
someone does `cli; f(); sti;`? You're boned.
<maurer>
OK
<doug16k>
why wouldn't I? it's zero cost in C++
<doug16k>
smart pointers cost zero extra overhead
<doug16k>
same with unique_lock. it doesn't do any more than I would have done by hand
<doug16k>
maurer, what do you think cli does?
<doug16k>
do you think it masks exceptions? it doesn't, it masks hardware IRQs
<maurer>
Yes, but if `f()` throws an exceptions
<maurer>
the IRQs never get unmasked
<doug16k>
they do if the unwinder handles rflags
<meisaka>
just put the IRQ flag into RAII
<maurer>
My understanding is there's no hook at `try`, so how does the unwinder know what state to reset them to?
<doug16k>
that's what I do
<maurer>
meisaka: Yes, that works, my point is that there are plenty of resource-like things, and if you go exceptionful, you need to make sure that 100% of things are RAII if you call a maybe-exceptionful function
<doug16k>
maurer, simplest way is what meisaka mentioned, just a destructor
<bslsk05>
github.com: dgos/isr.S at master · doug65536/dgos · GitHub
<doug16k>
tells the unwinder how to restore it
<doug16k>
the unwinder that comes with libgcc thinks it is running in user mode, so it won't, out of the box, but gdb does it with frame command, and you could add it to the unwinder
<doug16k>
hopefully you won't be making a java application though, that throws 250 exceptions/sec like a clown
<doug16k>
think of it as a small chance that an exception isn't a guaranteed lockup, if it was holding a lock when it faulted
<doug16k>
what does that scenario do without exceptions?
<doug16k>
you are complaining that it hurts when you get shot with a bulletproof vest on. try it without the vest, see how much it hurts
<doug16k>
what's the plan in C? setjmp on the entry into everything that needs catching? ya right
<doug16k>
with C++ exceptions, it is *zero* cost to enter try
<doug16k>
and zero to exit. you only execute extra instructions if an exception occurs
<maurer>
I mean, the counterproposal is just make everything return an error code and decide on site whether to handle it, propagate it, etc. and how to clean up if needed
<doug16k>
ah, you mean just magically never throw exceptions. can't believe I never thought of that
<doug16k>
seatbelts are pointless too. just don't smash into anything
<maurer>
...You can literally disable exceptions. Nothing magical about it.
<doug16k>
how do you disable exceptions?
<Griwes>
maurer: freeing resources RAII style is what you should be doing in C++ regardless of exceptions
<maurer>
`-fno-exceptions`
<doug16k>
lol
<maurer>
Griwes: As much as possible, yes. There's a difference between "You must be using RAII or you will have a bug" and "Use RAII when possible, it's nice"
<Griwes>
You must be using raii or you will have a bug tho
<Griwes>
Regardless of exceptions
<Griwes>
Add an early return to a function and forget a free, same result
transistor has joined #osdev
transistor has quit [Client Quit]
<doug16k>
exactly. when you are first making the spaghetti of goto error handler, you had it all straight. next week when people touch the code, they'll probably make it leak
transistor has joined #osdev
<Griwes>
or write a vulnerability by messing it up
<Griwes>
Which one was it that did the double goto thing, heartbleed?
<j`ey>
yep
<j`ey>
goto fail;
<doug16k>
maurer, even if you never throw or catch or anything, the exception ABI gives you the same stack trace as gdb, using eh_frame to enable unwind, starting from any arbitrary instruction, because it already had to be able to go up to each caller's frame to unwind
<doug16k>
unless you like backtraces that say ?? ?? ?? after the top function, you put the frame info in the interrupt handling
<doug16k>
even if you don't touch exceptions with a ten foot pole
<doug16k>
since you already had to put the unwind info there, it isn't much to go the extra few inches and enable unwind
<doug16k>
but anyway, even if you completely implemented it, you should avoid it as much as possible, like you usually should do
<doug16k>
if you expect code to throw, you are doing it wrong
<doug16k>
it should throw because it can't believe what just happened, not because it is an expected error condition that happens every time
Burgundy has left #osdev [#osdev]
<doug16k>
more of a panic-level reaction than normal control flow
<doug16k>
I implemented it because I simply had to know how unwinding works
<doug16k>
could not go on any longer not knowing :P
<doug16k>
I am easily amused by implementing fancy control flow things, like plt trampoline dynamic link that preserves every register (when possible)
<doug16k>
every register is as it was when it called the plt stub
GreaseMonkey has quit [Ping timeout: 264 seconds]
<doug16k>
wow, mips64 is interesting. has all these extra sections like .far, .fardata, .const
gmacd has quit [Remote host closed the connection]
Arthuria has quit [Ping timeout: 245 seconds]
<doug16k>
it's another processor that can hardly reach anything
<geist>
probably also has small data/etc like riscv and microblaze and a few others
<doug16k>
in it's most compact addressing mode I mean
<doug16k>
its
<doug16k>
so you put the .data and .bss as close to .text as possible, and the compiler puts big stuff in the far ones?
<geist>
yah was fiddling with 68k codegen last night and it has the problem that it has too many ways to address pcrel
<doug16k>
and the big stuff won't push stuff far away from .text?
<geist>
and without relaxation at the linker, there's no good way to guess how far
<geist>
since all references (data, pcrel, all deltas from all addressing modes, etc) can be 8, 16, 32
<geist>
but the compiler has to assume the worst and generally always emits a 32bit for things like branches or data references
<doug16k>
those must add up
<geist>
there's a -mpcrel but then it seems to just always assume 16 bit offsets. -relax doesnt do anything on ld
<geist>
it's an ideal situation for true linker relaxations, but doesn't seem to be implemented
Sos has quit [Quit: Leaving]
<doug16k>
any idea what the .pdr section is?
bsdbandit01 has joined #osdev
<geist>
negative. if you could figure out which .o its from can probably find out
<doug16k>
good idea
<geist>
then could at least see if it's rodata or text or whatnot
<geist>
probably another one of those things that just gets merged in
<geist>
someone on the net says "It's used to describe the stack frame layout in the debugging information. Yes, you can strip it in the build script it's not needed for running the app."
<sortie>
git commit -m 'Add -bdfgikhMnt options to sort(1).'
bsdbandit01 has quit [Read error: Connection reset by peer]
<sortie>
BOOM. What a commit. I SORT.
<doug16k>
it emits a bunch of funny input sections, like: .reginfo, .MIPS.abiflags, .gcc_compiled_long64, .mdebugO64
<geist>
yah souds like a lot of those are 'WTF is this binary' sections
<geist>
my brief fiddling with mips is there are a bazillion ABIs
<doug16k>
yeah, I noticed
<kazinsal>
sortie: So many options it looks like you sneezed in the middle of your commit message!
<doug16k>
-mkitchen-sink
andydude has joined #osdev
andydude has quit [Client Quit]
<sortie>
kazinsal: I could also have said “Implement POSIX” or even “Implement all the GNU kitchen sink that BSD also agreed to” but letter spaghetti it was \o/
<sortie>
Turns.. out.. sort(1) is TRICKY to implement correctly.
<kazinsal>
Sorting things sucks.
<kazinsal>
Especially doing it quickly.
<sortie>
The sorting part is easy
<sortie>
Language lawyering POSIX to figure out the EXACT semantics of -k is hard
<doug16k>
sortie is doing his part to lower entropy in the universe
<geist>
propping up the POSIX hedgemony
<sortie>
It still bothers me I haven't been able to figure out a good -x option
<sortie>
I'm thinking radix short or somethingh
<sortie>
*sort
<sortie>
Needs to combine well with -i to not compare unprintable chars
<kazinsal>
I need to write up a flowchart or something to figure out how to quickly sort routes by longest prefix match so when a route gets added or removed, the final mtree can be updated quickly
<doug16k>
kazinsal, sounds like a self-balancing tree
<sortie>
I could definitely make my sort(1) a lot faster and more scaleable but at least it's correct now if you don't feed it extremely large memory exhausting files
<doug16k>
I was wondering whether you supported sorting chunks and merging them
<sortie>
I do have the -m option for that yeah, per POSIX. Although I don't support dumping intermediaries to $TMPDIR
<sortie>
Anyways although sort(1) isn't very sexy osdev, it's one of those programs that will either create problems because of missing/wrong features. or you do all the features correctly and you basically never need to think of it again because everything works wonderfully for everyone
<doug16k>
for giant input, just split it into manageable chunks and merge them
<sortie>
Although it slows me a bit down, these days I try to just implement the whole POSIX programs whenever I need features. It's time saving to just read and handle all the POSIX requirements at a single time
<sortie>
Later I will be able to do lots of sexy osdev on top of common boring functionality like this, it's all about building on top of good primitives to make super cool things seem easy
<sortie>
Anyways this was a fun Saturday hackaway project. Listened to music on loop and just kept fixing one test case after each other and now it's 2 AM and I got a correct enough program
<sortie>
Been a while since I was this productive
<doug16k>
what should I do about gcc breaking my uefi build completely with stupid windows security changes in pep emulation?
<doug16k>
start debugging ld?
<sortie>
doug16k, uh, um. Reconsider your live choices?