mctpyt has quit [Remote host closed the connection]
mctpyt has joined #osdev
srjek has quit [Ping timeout: 260 seconds]
Arthuria has quit [Ping timeout: 260 seconds]
ZpCola has joined #osdev
frkzoid has joined #osdev
GeDaMo has joined #osdev
Gooberpatrol66 has joined #osdev
ZpCola has quit [Quit: Client closed]
Halofreak1990 has joined #osdev
Halofreak1990 has quit [Ping timeout: 272 seconds]
<azonenberg>
I find it somewhat ironic that my whole embedded architecture is supposed to be built around minimalism
<azonenberg>
and here i am putting a sshd in my bootloader
<azonenberg>
but it's for very practical reasons, i want the ability to OTA reflash via SSH
<azonenberg>
and i need the bootloader's ssh stack separate from all of the application binary code so they don't step on each other during the reflash
oldgalileo has joined #osdev
gbowne1 has quit [Quit: Leaving]
vdamewood has joined #osdev
<immibis>
people who are victims of actual rape probably don't appreciate when you trivialize it by saying having the volume too high is like rape
snowcra5h has joined #osdev
arminweigl has quit [Ping timeout: 268 seconds]
arminweigl has joined #osdev
snowcra5h is now known as Te7suo
<azonenberg>
ok soooo if I'm in an ARM (v7-M) hard fault handler
<azonenberg>
and I want to continue execution, skipping the faulting instruction
<azonenberg>
(assuming it's probably a memory read instruction)
<azonenberg>
how the heck do i do that...
<immibis>
increment PC by the instruction length before returning, presumably?
<immibis>
not the current PC - the one that the CPU is going to have after the return
<azonenberg>
So i actually found a better solution that lets me disable this fault in the first place
<azonenberg>
Ultimately what i'm trying to do is make flash uncorrectable ECC errors in the data portion of flash (caused by e.g. aborting a flash write by a power cycle) non-fatal
<azonenberg>
i already have my own crc checking around it
<azonenberg>
i want it to just say "that data is invalid" and return an error code rather than segfaulting, so i can gracefully recover
<GeDaMo>
Apparently you should be careful because high salt
<geist-sdf>
good to know
<geist-sdf>
i just gave her a tiny bit
Nixkernal has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nur has joined #osdev
Matt|home has joined #osdev
<kazinsal>
thinking about it, I've never actually had vegemite
<kazinsal>
oughta give it a go
<Mutabah>
Thin layer on toast
<Mutabah>
that's how you do it
<Mutabah>
or - just yolo with a tablespoon
<zid>
people kidneys are bad, cat kidneys are worse
<zid>
kidneys all think we're still saltwater fish
MrCryo has quit [Remote host closed the connection]
<sham1>
I mean, clearly it's working
<zid>
It works by just not being so shit that we all drop dead before we breed
<kof673>
%%$%#%#%% static binary, stripped: 669048 May 26 04:44 dynamic, unstripped: 7772 May 26 04:45 fopen() fprintf() fgets() isdigit() fclose() feof() ferror() that's about all it uses lol it is broadly 308 lines, but really more like 1/2 or 1/3 actual operations
<Mutabah>
libc is big
<sham1>
zid: works well enough. WONTFIX
<Mutabah>
specially the formatted string code
<kof673>
it is not a problem, just wow lol
<nikolar>
zid why would kidneys still thinking we're salt water fish mean salt bad when fish live in salty water
<zid>
It's just a mess of concentration gradients
<kof673>
if you have source of dependencies and/or LTO i would guess it would dramatically decrease :D
<zid>
freshwater fish, saltwater fish, monkey
<zid>
it can't figure it out
<sham1>
C++ is grinding one of my laptops to dust, from the sound of it
<zid>
Gotta concentrate that precious precious salt by making us drink a shit load of water, so that we can have some high osmotic power to get rid of that nasty salt!
<sham1>
We're stuck on a local maxima
<zid>
That's basically biologic in a nutshell
<zid>
you almost never get flukes that actually *improve* anything, just what is important radically changes and a bunch of things die
<zid>
ope, looks like it's now freezing everywhere, guess the awful broken gene that makes you grow blubber is a good gene now
<zid>
They've had a culture going on in a barrel of sea water or whatever it is they started with for like 40 years, tagging and sequencing all the little bacteria that live in it etc
<zid>
and there's basically *zero* predictive power in any measurement
<zid>
what determines which random subspecies go onto dominate for a while is completely random
<zid>
just based on what small changes happen to the environment in the barrel
<zid>
You can pluck out a mutation and go "Ah yes, now it's 40% better at producing xylophytomonoprotease-14-b, surely this is an improvment", then next week that protein turns into the favourite food of some other bacteria and they're all hunted to extinction etc
stolen has joined #osdev
DanielNechtan has quit [Quit: b0rk]
Nixkernal has quit [Quit: No Ping reply in 180 seconds.]
Nixkernal has joined #osdev
oldgalileo has quit [Ping timeout: 240 seconds]
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
netbsduser has joined #osdev
Left_Turn has joined #osdev
gog has joined #osdev
<azonenberg>
and then fast forward a few billion years and one of the bacteria's descendents has developed nuclear weapons
<azonenberg>
:p
* Ermine
gives gog a piece of cheese
* gog
is fascinated
<geist>
aren't kitties like lactose intolerant?
<sham1>
Doesn't mean they wouldn't be any less fascinated
<GeDaMo>
I'd assume that mammalian babies are all capable of digesting milk
<sham1>
They just shouldn't be eating the cheese
<GeDaMo>
Lactase persistence into adulthood is the oddity :P
<sham1>
Most mammals only eat the milk from their own species. Humans (and I suppose also cats in this case) are weird in that we also use the milk of other species, like bovines and goats and such
<sham1>
Also yeah, being able to break down lactose in adulthood is also weird
<gog>
many cheeses are lactose-free
<sham1>
If anything, lactose tolerance in adulthood is odd even in humans
<sham1>
It's really only for cultures that have done extensive cattle herding
<sham1>
So you have Europe (and by Europe I also mean European settlers in the Americas, Oceania and so on) and places like India
<gog>
esp aged cheeses
<gog>
the lactobacillus has time to eat all the sugar
<Ermine>
GeDaMo: I think cat milk is different from usual cow milk
<sham1>
You have large regions of the planet where people are lactose intolerant
<Ermine>
If I can drink milk, I'm lactose tolerant, right?
<gog>
if you can drink it without shtting your guts out
<kof673>
"the cat is ra himself" that cat generates the milk, and is its own father lol
osdev199 has joined #osdev
<zid>
Dog's milk was what I was going to start talking about next if you hadn't gedamo :P
<GeDaMo>
:P
<zid>
keep for a long time, jokes about dog milk
<osdev199>
On kvm/qemu, after finding the nvme controller, my kernel is displaying the nvme base address as 0x0 (BAR0 address)! I'm using the -M q35 option though and my PCI enumeration code is correct. Any idea?
<osdev199>
I have checked my code again. It is giving the correct nvme base address on my real machine.
<azonenberg>
Welp i found the root cause of my bug after disabling the segfault so i could troubleshoot
<azonenberg>
Turns out i had one piece of code doing things it really shouldn't do with flash
<azonenberg>
namely, writing more than once to the same page of ecc-protected flash because it assumed a 32 *bit* not 32 *byte* write block size
srjek has joined #osdev
oldgalileo has joined #osdev
oldgalileo has quit [Ping timeout: 240 seconds]
gildasio has quit [Ping timeout: 260 seconds]
gildasio has joined #osdev
Turn_Left has joined #osdev
netbsduser has quit [Ping timeout: 256 seconds]
Left_Turn has quit [Ping timeout: 268 seconds]
navi has joined #osdev
MrCryo has joined #osdev
MrCryo has quit [Quit: MrCryo]
MrCryo has joined #osdev
MrCryo has quit [Quit: MrCryo]
MrCryo has joined #osdev
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
\Test_User has quit [Read error: Connection reset by peer]
Test_User has joined #osdev
Test_User is now known as \Test_User
osdev199 has quit [Quit: Leaving]
oldgalileo has joined #osdev
Maja has quit [Quit: No Ping reply in 180 seconds.]
oldgalileo has quit [Ping timeout: 268 seconds]
Maja has joined #osdev
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
Matt|home has quit [Remote host closed the connection]
<bslsk05>
github.com: Raam/nvme.c at d096335722be61856700c1f02147cbd10a1a0e60 · robstat7/Raam · GitHub
<osdev199>
is it because the admin entry was never processed or is there something wrong with the commands I submitted to the nvme controller beginning line #258?
oldgalileo has joined #osdev
<osdev199>
I also tried asking questions on the osdev forum but non of them got approved by the moderators since I joined the last month. I don't know why.
Left_Turn has joined #osdev
oldgalileo has quit [Ping timeout: 260 seconds]
Turn_Left has quit [Ping timeout: 256 seconds]
oldgalileo has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 268 seconds]
<gog>
CR69
<jimbzy>
Hallo.
<jimbzy>
How have you all been?
<GeDaMo>
I don't know about anybody else but I'm OK :P
<jimbzy>
Good deal!
<osdev199>
gog: was that a reply to me?
MrCryo has quit [Quit: MrCryo]
MrCryo has joined #osdev
<sortie>
osdev199: In any case, this place is a pretty good place to ask questions, at least if you ask a few times and manage to get the attention of the right people
<sortie>
uint64_t val;
<sortie>
do { val = *((uint64_t *) acqb_copy); }
<sortie>
while(val == 0);
<sortie>
osdev199, without knowing the hardware in question, this is an infinite loop in C.
<sortie>
It sounds like you want to use the volatile keyword here
<sortie>
Since the compiler is free to optimize that to a single read
<sortie>
I assume the printk call would inhibit that optimization though
<sortie>
__asm__("mov rax, %0\n\t" ← Are you switching the compiler to another assembler syntax? That seems a bit iffy but I guess it's fine. Always double check the output assembly is what you expect
MrCryo has quit [Ping timeout: 268 seconds]
<gog>
osdev199: no, sorry
<gog>
that was at Ermine
<sortie>
osdev199: Are you seeing this on real hardware or a virtual machine?
<Ermine>
gog: CR420
<sortie>
Generally I'd encourage you to use safer ways of doing memory mapped IO
<osdev199>
sortie: let me quick test it with volatile uint64_t val. As I'm testing on my real machine, I will get disconnected and I will connect back.
<sortie>
osdev199: It's not just that location
<sortie>
Also in your initialization
MrCryo has joined #osdev
<sortie>
A well written driver would also use <endian.h> functiond and such to convert the endian but it's all little endian on your system so it doesn't matter for this bug
<osdev199>
sortie: initialization?
<sortie>
Places like nvme_init and other places
<sortie>
Basically anything that accesses memory mapped registers would be volatile
<sortie>
I kinda doubt it's your problem, but it is the correct way to write code like this, and get an assured happens-before relationship on memory accesses
<bslsk05>
github.com: BareMetal/src/drivers/storage/nvme.asm at master · ReturnInfinity/BareMetal · GitHub
<osdev199>
I also tried the same assembly code in https://github.com/robstat7/Raam/blob/master/nvme.asm but it was going into the infinite loop at the same place! The original driver works fine if I build his OS.
<bslsk05>
github.com: Raam/nvme.asm at master · robstat7/Raam · GitHub
<osdev199>
Strange I double checked every bit of line in my nvme.asm file still can't figure that out!
<sortie>
The OS may do some other CPU register setting in an earlier phase
<sortie>
Or configure PCI
<sortie>
My bet is that there is some hardware state that you have not set up correctly
<sortie>
It always is haha
xenos1984 has joined #osdev
<osdev199>
sortie: I don't think so. As far as I remember, he checks if PCIe is enabled before falling back to PCI. And in his 64-bit initialization and bus init code, he doesn't do any cpu register setting to be used in the nvme driver code.
<sortie>
If his OS works on your machine and yours do not, there is a difference
<sortie>
Debug until you find it :)
<osdev199>
I would rather write the driver from scratch again :P
<osdev199>
regarding your earlier suggestion, I would use the data structure for the MMIO during the refactoring phase...! Thanks for that.
troseman has joined #osdev
<osdev199>
sortie: can I debug it on qemu? Maybe additional tracing would help. I'm just not getting the right BAR0 address! I have double checked my code though!
<sortie>
Does the other OS work in qemu?
<osdev199>
yes.
<osdev199>
It's for qemu only.
<sortie>
Then see what it does to get the BAR0?
<osdev199>
Is this fact sufficient that I'm getting the right address (checked in my Linux OS) on my real machine?
<osdev199>
*cross-checked
<osdev199>
sorry, new to osdev.
<sortie>
osdev199, in general, in osdev, you *will have to debug and solve your own impossible problems* all the time. It's just how it is because there's not so many of us, so you will often be the first to run into something, or because it's a super weird problem with your implementation that takes a lot of time to figure out.
<sortie>
osdev199, in this case I know nothing of the NVME hardware as I have not implemented it myself, but I can guide you through the osdev debugging experience to debug the impossible :)
<sortie>
If you have an impossible bug, and you have something else that works, then one way of solving it is to incrementally make the two things more and more similar, until one of them changes behavior
<sortie>
Then you know what the key difference is. This may be very time consuming, or fast, it depends, but that is one way to find a weird difference
<sortie>
In this case, their OS works on your machine, but yours do not, so you can debug why that is.
<sortie>
Also in this case, their OS works on qemu, but yours do not, so you can debug why that is.
<sortie>
One way of doing this is to e.g. try to splice the code of the projects together in hybrids and see what piece is needed
<sortie>
Alternatively you can modify the logic at a higher level so the code does the same, more or less, even if it is not the same
<sortie>
There's other potential solutions too. You can read the data sheet for the NVME hardware very carefully and see if you can find something that it tells you to do, that you don't do. If there's anything the other driver did, which you skipped because you didn't think you needed it, maybe you did?
<sortie>
You can potentially also find a third operating system that may be a different implementation and compare with that too
<sortie>
If you're running in qemu, you can also use the debugger in qemu to probe the memory locations and see what's going on.
<sortie>
You can also modify the qemu source code with more debugging and see what is happening from the qemu pointer of view, maybe that'll reveal the bug
<sortie>
osdev199, right? So when you have an impossible bug like this, you will have to attack it from all sorts of angles, and see which one works. Trying to find a fast solution rather than wasting too much time, but being prepared to dig deep, because it may be really difficult to debug.
<sortie>
And we're here to guide you and maybe people here know stuff. Like it could've been a volatile issue. Or maybe someone does know NVME. You can maybe ask the authors of other implementations
<sortie>
osdev199, but once you solve your first truly impossible bug, you become a true osdever :) able to solve anything and make the computer do anything, with enough time and effort of course :L)
<osdev199>
sortie: thanks. I have noted your points. This is really interesting.. and of course hard :) Thank you for your help :)
hl_ is now known as hl
<Ermine>
Afaik most impossible bugs are caused by concurrency issues
sortie has quit [Ping timeout: 246 seconds]
Left_Turn has joined #osdev
<osdev199>
Ermine: I don't have any concurrent processes running.
<Ermine>
kernel is concurrent environment by itself
<Ermine>
Anyway, please make sure to tell us what was the culprit if you manage to fix this bug. Good luck!
<osdev199>
I meant I don't have multiple threads running.
<osdev199>
sure.
Turn_Left has quit [Ping timeout: 272 seconds]
<GeDaMo>
Interrupts and what not
osdev199 has quit [Remote host closed the connection]
<Ermine>
Yeah, they add non-determinism too
osdev199 has joined #osdev
sortie has joined #osdev
<osdev199>
oh.
osdev199 has quit [Remote host closed the connection]
osdev199 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 255 seconds]
osdev199 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
netbsduser has joined #osdev
MrCryo has quit [Remote host closed the connection]
Gooberpatrol66 has quit [Quit: Konversation terminated!]
gbowne1 has joined #osdev
zetef has joined #osdev
foudfou has quit [Remote host closed the connection]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
foudfou has joined #osdev
Te7suo is now known as snowcra5h
osdev199 has joined #osdev
<osdev199>
Hi, I'm trying to execute a hello world asm userspace program from my kernel in kernel mode but I'm getting the invalid opcode exception. It is very hard to debug it because the rip is ubounded.
<osdev199>
In kernel's C file (global scope): void (*hello)(void) = (void (*)())0x4016d0;
<osdev199>
from assembly file: call hello
<osdev199>
and my hello.asm is: int3
<osdev199>
ret
<osdev199>
only two lines. Assembled using fasm.
<Ermine>
Are you sure this this an actual address of your procedure?
<dostoyevsky2>
do kernels written in c typically have a main?
<geist>
a main of some sort, but possibly not named `main` precisely, because that has certain language assumptions about args
<dostoyevsky2>
yeah... but then wouldn't it make sense to just load (e.g.) the kernel as an ELF executable from the boot sector?
<geist>
possibly, but it's difficult to write an ELF loader in 512 bytes
<geist>
so usually there's a second stage
<geist>
but i'm not entirely sure what you're getting at
heat has joined #osdev
<osdev199>
Ermine: Yes. I am reading the two bytes at starting from that address and they are correct for the instructions. memcpy is working.
<heat>
good morning linux users
<dostoyevsky2>
hmmm... isn't grub much more than 512bytes anyways? It already has terminal emulators for vt100 and others
<geist>
dostoyevsky2: indeed. it is built of multiple stages internally
<heat>
it has a module system!
<dostoyevsky2>
And you can also specify parameters for the linux kernel in grub... so just add an ELF parser... that doesn't seem to be hard either, but not sure if the processor might not be yet in the right state to just map the executable into ram
<heat>
osdev199: i told you the other day, you have to have a PCI bug
<heat>
there's no way the NVMe BAR0 is 0, and info pci in qemu's monitor would tell you that
<geist>
dostoyevsky2: yeah okay that's what i was getting at. didn't know what you were asking about, since you said 'loaded from bootsector'
<Ermine>
hi heat
<geist>
from a second stage loader like grub? sure. loading as elf would be nice
<heat>
hi Ermine
<osdev199>
heat: I have asked a different question today :)
<dostoyevsky2>
geist: I just wonder why the vmlinuz thing can't just be a standard ELF with a main... and they instead used to a different way (I guess)
<geist>
historically if nothing else. it's complicated
<geist>
also keep in mind it works completely differently on different architectures
<Ermine>
./vmlinuz
<heat>
vmlinuz was originally also a bootloader
<geist>
exactly, you used to (maybe still can) just dd it to a floppy disk and it ran
<heat>
also, you can't do lots of really early stuff in C, so just a straight up main doesn't work
<geist>
ie, in general linux depends not so much on the previous stage to load, which is IMO a good idea
<geist>
since grub is just oneo f many loaders that can load linux
<heat>
yeah the really common one is EFI these days
<osdev199>
heat: I will check that later. Thanks.
<dostoyevsky2>
do both the initramfs and then kernel boot use the same executable format? Or is the actual kernel then an ELF or the like?
<heat>
initramfs isn't an executable
<geist>
it's basically an archive of a bunch of files
<heat>
cpio yeah
<Ermine>
I wonder if any distro pushes vmlinuz straight into efi Boot variables
<dostoyevsky2>
yeah, the vmlinuz contains the initframfs and the actual kernel that will boot
<heat>
no
<Ermine>
initramfs is a separate thing
<heat>
vmlinuz is the actual kernel, the initramfs is Generally(but not always) separate
<Ermine>
You must be confusing it with UKI
<geist>
and the kernel finds the initramfs it via <mechanism>
<dostoyevsky2>
ah...
<geist>
where <mechanism> varies, including just searching in a fixed spot, or after itself, etc
kspalaiologos has joined #osdev
<geist>
passed as an arg, look in device tree, etc
<dostoyevsky2>
And grub has an ext3fs also in its code so it can actual read the vmlinuz?
<geist>
also note thats just how linux does it, other oses may do it totally differently
<geist>
yes in general grub reads the kernel + initramfs out of an existing fs, that it has a lot of drivers for
<osdev199>
So if I write int3 inline assembly instruction in my kernel, it works. But if I the binary executable from my kernel, it doesn't. Where can the cpu catch an invalid opcode? On call or just after the call or?
<heat>
osdev199: after the call
<Ermine>
I wonder how does it figure if given initrd does contain intel/amd ucode
<dostoyevsky2>
geist: Macos seems to do a lot of their own stuff in the EFI firmware... I noticed that when I tried to install linux on Macbooks, sometimes grub just wouldn't boot
<geist>
Ermine: i looked into it at some point, there's a whole complicated thing where linux searches the initramfs for the ucode very early
<geist>
sort of a linear search
<osdev199>
heat: but the next instruction should be int3 itself, right? Or am I missing something?
<geist>
so that it can get to the ucode before doing much else
<heat>
yeah it knows the path name IIRC
<heat>
osdev199: correct. you should trap at 0x40...
<heat>
an invalid opcode hints that eiher 0x40... is bad, or your exception handlers are busted
<geist>
this is all in ring0?
<geist>
as soon as you add ring3 to the mix the exception handler bit gets more complicated (need TSS, etc)
<osdev199>
I didn't get 0x40, the hint.
<osdev199>
geist: yes
<heat>
i mean the address you're calling
<Ermine>
isn't setting up gdt with tss included the first thing you'll do anyway?
<heat>
not if you haven't needed to muck around with userspace yet
<geist>
Ermine: not really. you dont need to set it up until you do userspace
<geist>
you have to set up a GDT, but only need a pair of segments for ring0
<Ermine>
those dummy segments from gdt tutorial I guess
<zid>
tss isn't needed until you wanna take an IRQ while in userspace, really
<geist>
FRED take me away!
<osdev199>
heat: "osdev199: correct. you should trap at 0x40..." could you elaborate?
<zid>
freeeed
<heat>
if int3 is at address ABCDEF, you should trap at 0xABCDEF with a debug exception (or is it breakpoint? don't remember)
<heat>
and the PC will be ABCDEF
<heat>
an invalid opcode would hint you're executing garbage and not the int3, a bad PC would hint you screwed up your exception handling
<osdev199>
what do you mean by trap?
<heat>
"The term trap refers to a processor's mechanism for capturing an executing thread when an exception or an interrupt occurs and transferring control to a fixed location in the operating system"
<osdev199>
noted.
<osdev199>
But the PC will be the address of the next instruction immediately after int3 at ABCDEF, right?
<heat>
no
<heat>
unless i'm misremembering something, but i don't think i am
<osdev199>
AFAIK, PC stores the address of the next instruction to be executed. Trapping is occuring at ABCDEF.
<heat>
it's an exception, that instruction hasn't retired yet
<heat>
int3 will not continue
kspalaiologos has quit [Remote host closed the connection]
<osdev199>
aha, I see.
<heat>
ie if you inspect a page fault's PC, it'll point to the offending instruction
<osdev199>
ok. Thanks.
<Ermine>
int3 calls #BP handler
heat has quit [Quit: Client closed]
<Ermine>
heat got interrupted
heat has joined #osdev
<osdev199>
so in my case, it is an invalid opcode + bad PC.
<heat>
connection went oopsie
<Ermine>
heat handled the interrupt and iret'd
<osdev199>
cool :D
<osdev199>
As I don't have a garbage at the address, I guess something is wrong with my exception handling. But what could be that?
<bslsk05>
go-acme/lego - Let's Encrypt/ACME client and library written in Go (976 forks/7353 stargazers/MIT)
<gog>
shit ineed to figure out something with node tomorrow
<Ermine>
furthermore, I hate the fact I need to specify source package in import directive
<gog>
i can't remember what
<Ermine>
liek import "github.com/some/package/v1"
<bslsk05>
github.com: Page not found · GitHub · GitHub
<netbsduser>
the time has come
<netbsduser>
i need turnstiles
<netbsduser>
i am doing a new tmpfs this time fully pageable and i can't have the basic locks in paged memory
<dostoyevsky>
netbsduser: spin locks could work in paged memory, no?
<netbsduser>
dostoyevsky: they always raise IPL to >= softint IPL so i can't
<netbsduser>
page faults can't be serviced at or above softint level
<netbsduser>
as they are liable to wait
<dostoyevsky>
netbsduser: In OpenBSD tmpfs is just ffs/ufs without a disk
<netbsduser>
dostoyevsky: that's MFS
<netbsduser>
they imported a proper tmpfs from netbsd (regular files have an anonymous vm object, although openbsd i believe still didn't have mmap/read or write() coherence as it didn't map the vm object directly)
<netbsduser>
but as i understand it they couldn't get it to work so it was thrown out of the central openbsd repository
<dostoyevsky>
they had tmpfs working for a while but they didn't like the code, smelled of too many CVEs and they don't care if using a regular filesystem in memory is slower if they like the code mroe
<osdev199>
how to disassemble an elf64 binary in Linux?
<gog>
objdump -d
<osdev199>
thanks.
<dostoyevsky>
osdev199: I my code I preferred `ndisasm -b64 elf' over objdump -- forgot why, though
<osdev199>
gog: don't know why it was not working the earlier on elf binaries!
vdamewood has joined #osdev
frkazoid333 has joined #osdev
<gog>
objdump defaults to at&t syntax
<gog>
nasm always uses intel
<netbsduser>
dostoyevsky: i wonder what cves they thought it would produce
mctpyt has quit [Remote host closed the connection]
mctpyt has joined #osdev
<dostoyevsky2>
> In reality, every time I look at the VFS kernel layer, I get side-tracked into thinking this is horrible code (the marshalling/unmarshalling of parameters is very unnecessary, and doing pseudo inheritance by hand at the function pointer level is horrible... there's a huge amount of weird duplicated code in there... having three vfs structs for each fs based on the type of file (normal file or
<dostoyevsky2>
otherwise) is rather strange, and I'm reasonably certain some of the failure mode is dubious at best.