xFCFFDFFFFEFFFAF has quit [Ping timeout: 260 seconds]
Arthuria has joined #osdev
heat has quit [Ping timeout: 268 seconds]
joe9 has quit [Quit: leaving]
osdev199 has joined #osdev
xFCFFDFFFFEFFFAF has joined #osdev
netbsduser has joined #osdev
<osdev199>
Hello, I'm asking my question again after the last night. I'm writing a 64-bit kernel and in the UEFI boot loader, writing to frame buffer is not working after calling ExitBootServices. However it works and fills the color if called before calling the same function. Please see line #109 at https://pastebin.com/fbC6yGfu. Any suggestions? Thanks.
<bslsk05>
pastebin.com: /* * Boot loader written using gnu-efi. */#include <efi.h>#include <efil - Pastebin.com
netbsduser has quit [Ping timeout: 256 seconds]
Arthuria has quit [Ping timeout: 246 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
osdev199 has quit [Remote host closed the connection]
netbsduser has joined #osdev
<rustyy>
hey guys, how i do view the kernel stack of a user-space process in Windows? something like /proce/PID/stack in Linux
<Mutabah>
For what purpose?
<Mutabah>
also, is that file the kernel stack or the userland stack? exposing kernel stack (even read-only) seems very strange
<rustyy>
the frikking WriteFile() hangs indefinetly
<rustyy>
in the Windows kernel
<Mutabah>
Doesn't windows have debugging tools that can check the cause of those?
Fingel has joined #osdev
<kazinsal>
yeah you should be able to just examine the wait chain
<kazinsal>
Mutabah: I think you need to build the kernel with a specific CONFIG_ for /proc/<pid>/stack to function, because, yeah, it's specifically a "DO NOT ENABLE THIS IN PROD" feature
<kazinsal>
you do need root to read it but still
<rustyy>
kazinsal: it is enabled by default in Debian and Arch and probably other distros
<rustyy>
apparently you can do a similar thing in Windows, Process Explorer can show a kernel part of the stack for the thread
<rustyy>
GetThreadContext() is the api, right?
<rustyy>
and StackWalk64() right?
netbsduser has quit [Ping timeout: 268 seconds]
masoudd has joined #osdev
rustyy has quit [Ping timeout: 268 seconds]
rustyy has joined #osdev
Fingel has quit [Quit: Fingel]
netbsduser has joined #osdev
osdev199_ has joined #osdev
osdev199_ is now known as osdev199
netbsduser has quit [Ping timeout: 268 seconds]
zetef has joined #osdev
osdev199 has quit [Ping timeout: 272 seconds]
netbsduser has joined #osdev
masoudd has quit [Quit: Leaving]
op has quit [Ping timeout: 268 seconds]
theyneversleep has joined #osdev
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
goliath has joined #osdev
zetef has quit [Ping timeout: 264 seconds]
gbowne1 has quit [Quit: Leaving]
npc has joined #osdev
theyneversleep has quit [Ping timeout: 268 seconds]
npc has quit [Ping timeout: 256 seconds]
npc has joined #osdev
zetef has joined #osdev
npc has quit [Ping timeout: 264 seconds]
spareproject has joined #osdev
spareproject has quit [Ping timeout: 256 seconds]
craigo has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
npc has joined #osdev
gog has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
heat has joined #osdev
gog has quit [Remote host closed the connection]
gog has joined #osdev
netbsduser has joined #osdev
<heat>
gog
<gog>
heat
<heat>
good mornen
<kazinsal>
gog
<heat>
btw kazinsal /proc/pid/stack is totally okay in prod
<heat>
it gets auto-enabled if you turn on any sort of stack tracing
spare has joined #osdev
<mjg>
i don't understand how proc stack is supposed to be unsafe
npc has quit [Ping timeout: 256 seconds]
pog has joined #osdev
<mjg>
and i don't recall any distro which does not have it
<heat>
you can't actually enable stack tracing without linux auto-enabling proc/pid/stack for you
<mjg>
i would argue most of these options should get whacked
<mjg>
as in make it non-optional
<mjg>
how many people even build test all the whacky combinations
<pog>
kazinsal
<heat>
mjg, maintainers like randconfig, intel ci also builds randconfig
<heat>
some arm people might have it off
<heat>
the small 32-bit arm
<mjg>
fucken' stack traces?
<heat>
and so on for all the other shitty embedded stuff
<mjg>
i don't think whacking basic debug facilities like this one makes any sense
<mjg>
especially for production
gdd has joined #osdev
<heat>
i mean yeah totally, but someone has done it before
<heat>
they're probably doing it now
<heat>
we need to stop them
<mjg>
have you removed latencytop yet
<heat>
oh thanks for reminding me
<heat>
totally forgot about that
<mjg>
maintain a TODO list
<heat>
0. get a girlfriend
<heat>
1. remove latencytop
<heat>
though i guess to submit patchen you can't have 0.
<mjg>
that's if you submit from arch
<heat>
OH
<heat>
do you use oracle linux?
<mjg>
the L man himself is married
<mjg>
but then again, he is not using arch, is he
zetef has quit [Ping timeout: 252 seconds]
<kof673>
almost a double joke :/ > Ellison's friend Steve Jobs, former CEO and co-founder of Apple Inc., was the official wedding photographer [...] They divorced in 2010.
* kof673
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
<kof673>
that [...] kind of changed the meaning of that excerpt lol
<bslsk05>
'1957: The SPAGHETTI HARVEST | Panorama | Classic BBC clips | BBC Archive' by BBC Archive (00:02:45)
gorgonical has quit [Ping timeout: 272 seconds]
bauen1 has joined #osdev
gbowne1 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
xFCFFDFFFFEFFFAF has joined #osdev
<chibill>
Been working on a low level FAT32 read-only driver lately, (for my own OS, on my own hardware) pretty fun so far. Hate to think how hard trying to do EXT would be.
<netbsduser>
you must be joking chibill
<netbsduser>
FAT32 is bizarre while EXT2 is just what you'd get if you sat down a competent and thoughtful person and asked them to create a basic but reasonably efficient filesystem
<heat>
yes
<heat>
ext4 is the amish filesystem
<heat>
not too old, not too modern, not too simple, not too complex
<heat>
just right
<heat>
ext2 is also good but it has aged a good bit from having linear dirs, not having extents and not having journalling
<geist>
FAT has the real advantage that its actually used on SD cards and whatnot. tis why i have been working on it first in LK too
<chibill>
Going to say FAT32 is fairly simple, compared to to everything going on in EXT3, with Inodes, journalling and everything else.
xenos1984 has joined #osdev
<heat>
FAT is simple but it's awkwardly simple
<geist>
also supporting all 3 variants is annoying
<heat>
like, if you're designing a VFS around FAT you'll end up with an awful awful VFS
<geist>
thats' the big issue
<sham1>
ext4 is a nice root fs
<sham1>
FAAAAAST
<heat>
ext4 is reasonably fast and very stable
<heat>
xfs is super fast
<heat>
zfs is
<heat>
fat is bad
<heat>
but sadly you need FAT anyway
<sham1>
lolefi
<chibill>
Well, seeing as I am just righting a simple bios that has to live in a ROM at the start of my machines memory, and all its doing is loading up a "kernel" binary to memory and jumping to it.
<heat>
efi, sd cards, usb drives, etc
<geist>
yah keep in mind implementing a full ext4 involves some btrees and journalling
<netbsduser>
the principle merit of FAT today is making for an interesting exercise in implementing it in an optimal way
<sham1>
EFI_MJG_PROTOCOL_LOLLER
<geist>
those two components will probably swamp most of the development effort
<chibill>
Currently also stuck in ASM till I finish writing my C Compiler for my system
<netbsduser>
ext4 i think it's understandable for people to recoil from a little because of the HTrees and such
<heat>
you're writing a BIOS?
<netbsduser>
very competent FS though and quite bulletproof
<heat>
geist, the journalling is not actually that hard
<chibill>
Yea, making an OS for a full custom (at least in that it use a homebrew CPU, most other things try to follow standards) system.
<netbsduser>
it is not a magical wonderfilesystem like ZFS and it's not a highly scalable superfilesystem like XFS but it's more than good
<geist>
yep. i've generally moved my machines to btrfs over time, but i also like to utilize the snapshotting stuff
wantyapps is now known as wantyapps1
<geist>
heat: yeah i kow, but it's compared to a lot of other things fairly complex
wantyapps1 is now known as wantyapps
<geist>
the btrees in the dirs are probably most of the effort
<geist>
but yes nothing in ext4 is particularly difficult, there's just a fair amount of it, compared to simpler thingsl ike ext2 or fat
<heat>
linux uses a pretty simple scheme by default, basically you say "i want to write this to this block", then you write it, then you confirm the write in the journal
<heat>
oh yeah totally
<heat>
probably not the greatest choice if its your first fs ever
<chibill>
Even EXT2 has a log of moving parts compared to FAT32.
<heat>
no it doesnt
Matt|home has joined #osdev
<geist>
the split superblocks and allocation groups and whatnot is pretty annoying
<geist>
if it had one big ass bitmap and one big ass inode list and one big ass inode bitmap it'd be perfectly straightforward
<heat>
yeah but then it'd be PESSIMAL
<geist>
not for SSDs. that was totally built around spinning media
<chibill>
Really? For FAT32 its fairly simple to read the root DIR, find the FAT for its files, and read a file based on its name. Its hard to find info even on the wiki how I would do something similar in Ext2.
<heat>
yes, really
<geist>
chibill: the big difference is that dirs and inodes are different in ext2 (and pretty much all unix fses)
<geist>
which though sounds more complicated, makes things much more straightforward
<netbsduser>
i suppose the only real merit of the cylinder groups in ext2 today for modern SSDs is that it does maybe facilitate some parallelism (depending on how your implementation looks)
<geist>
2 smaller layers in the FS code instead of it mashed together
<heat>
you get the inode 2, which is your root directory. the files are listed linearly in the root dirs contents, you basically look at it and see your file (as an inode), and you open that inode
<geist>
most of the complexitiesof FAT and unix vfs is because the dir entry is the inode
<geist>
right. dir entries are basically { name, inode # }
<heat>
netbsduser, i'm pretty sure a lot of the xfs speed advantages have been attributed to their aggressive use of allocation groups
<geist>
and then you have a straightforward way to go from inode # -> inode
<heat>
it SCALEZ!!
<geist>
heat: sure but you could do the same thing even if they were all in one place
<netbsduser>
heat: that would accord well with it being developed, i think, as part of cellular IRIX
<netbsduser>
their solution to the scale problem was extreme replication
<heat>
geist, in the xfs case they have per-AG btrees so it really wouldn't in their case
<geist>
i posit except for the indexing stuff, beos's BFS is actually a pretty good middle ground
<chibill>
execpt based on the wiki I need to jump thru multiple hoops to get to the inodes that make up the file it self from the data in the inode that is the root dir. Or am I reading the short 5 single sentence bullet points wrong?
<netbsduser>
cellular IRIX is like one IRIX per NUMA domain with interaction governed by something that resembles a distributed system
<geist>
approximately ext3 class (journalling) with some ext4 bits (extent based stuff) with extended attributes
<heat>
ext4 is basically ext3 with extents
<heat>
ext3 is ext2 with journalling and hashed dirs
<zid>
where did they add the ENTERPRISE
<geist>
otherwise bfs is a prety standard looking unix fs with a single allocation group, and no inode tables (inode #s are simply the block number)
<netbsduser>
and it's beyond any doubt, no one would ever try to argue otherwise, that replication is the secret to scaling right up, whether it be the kind of explicit replication that cellular IRIX did, or the implicit form that RCU and friends facilitate
<bslsk05>
github.com: lk/lib/fs/ext2/ext2.c at master · littlekernel/lk · GitHub
<geist>
but point is onc eyou have those routines written, the splitting of dirs to inodes is much more clean
<geist>
this is why unix fses can do hard links: a hard link is simply multiple dir entries pointing to the same inode
<heat>
what's that ext3 header there for?
<geist>
i think the code has some support for ext3, and clever was working on ext4 support (RO)
<heat>
doesn't look like its included, you should take that out for legal clarity
<geist>
legal clarity?
<heat>
yeah, it makes your whole ext driver GPL
<heat>
and if its linked with your kernel directly, then the kernel is GPL
<heat>
no?
<netbsduser>
does it have any actual code in it or just definitions?
<geist>
not really. the ext2_fs.h is also GPL derived. there's prior art that if you include a header for just structure compatibility it doesn't trip
<geist>
it's just definitions
<netbsduser>
it will be fine then
<geist>
but you're right the ext3_fs.h one isn't used and it wasn't trimmed out of function declarations like the ext2_fs.h one is
<geist>
so probably should just remove it
<heat>
maybe, IANAL
<heat>
sounds scary to me
<geist>
but honeslty i haven't touched most of that in 10 years or so
<geist>
for structure compatibiity it's basically a shortcut, since you'd end up just typing it all in the same way
<zid>
I however, *am* a lemming.
<heat>
KERNEL
<heat>
my kernel is now passing most nameitests which is good
<heat>
i have become path walking destroyer of unix
<heat>
nikolapdp, path walking trivia: given that open(broken_symlink, O_CREAT) just works, does mkdir(broken_symlink) work? if not, why?
<kof673>
"nature's god" -- thomas jefferson "god of natures (plural)" -- thomas vaughan /me points at double scales at the double hall at the double mount at the double cave at the double equinox....
<kof673>
i am not ...advocating anything, but you will never find a competent lawyer, there is 1000s of years of illiteracy at play lol
ThinkT510 has quit [Quit: WeeChat 4.2.2]
ThinkT510 has joined #osdev
<Ermine>
"onyx rocks" -- thomas jefferson
xvmt has quit [Read error: Connection reset by peer]
xvmt has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
Starfoxxes has quit [Ping timeout: 256 seconds]
Starfoxxes has joined #osdev
* mjg
burps
<mjg>
heat: check out what directory i just found on ubuntu
zetef has quit [Remote host closed the connection]
alexander has joined #osdev
mahk has quit [Ping timeout: 255 seconds]
<kof673>
> he Summit County Courthouse Lions · Ohio Outdoor Sculpture www.sculpturecenter.org oosi › items › show Two seated lions, mirror images of one another, are placed onto a Limestone slab base set into sandstone. Both lions are resting on hind legs # you can find them elsewhere too, anyways lol
netbsduser has quit [Ping timeout: 256 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
Turn_Left has quit [Read error: Connection reset by peer]
Brnocrist has quit [Ping timeout: 240 seconds]
Brnocrist has joined #osdev
<heat>
mjg, it's very possible creat isn't available on arm64 and newer archs