channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=4&d=17
00:00:00 <heat> distrotools? something like that
02:50:00 <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.
02:50:00 <bslsk05> pastebin.com: /* * Boot loader written using gnu-efi. */#include <efi.h>#include <efil - Pastebin.com
03:58:00 <rustyy> hey guys, how i do view the kernel stack of a user-space process in Windows? something like /proce/PID/stack in Linux
04:00:00 <Mutabah> For what purpose?
04:00:00 <Mutabah> also, is that file the kernel stack or the userland stack? exposing kernel stack (even read-only) seems very strange
04:00:00 <rustyy> the frikking WriteFile() hangs indefinetly
04:00:00 <rustyy> in the Windows kernel
04:01:00 <Mutabah> Doesn't windows have debugging tools that can check the cause of those?
04:10:00 <kazinsal> yeah you should be able to just examine the wait chain
04:11:00 <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
04:12:00 <kazinsal> you do need root to read it but still
04:14:00 <rustyy> kazinsal: it is enabled by default in Debian and Arch and probably other distros
04:15:00 <rustyy> apparently you can do a similar thing in Windows, Process Explorer can show a kernel part of the stack for the thread
04:17:00 <rustyy> GetThreadContext() is the api, right?
04:18:00 <rustyy> and StackWalk64() right?
09:29:00 <heat> gog
09:32:00 <gog> heat
09:34:00 <heat> good mornen
09:34:00 <kazinsal> gog
09:36:00 <heat> btw kazinsal /proc/pid/stack is totally okay in prod
09:36:00 <heat> it gets auto-enabled if you turn on any sort of stack tracing
09:39:00 <mjg> i don't understand how proc stack is supposed to be unsafe
09:40:00 <mjg> and i don't recall any distro which does not have it
09:40:00 <heat> you can't actually enable stack tracing without linux auto-enabling proc/pid/stack for you
09:42:00 <mjg> https://elixir.bootlin.com/linux/latest/source/lib/Kconfig.debug#L1618
09:42:00 <bslsk05> elixir.bootlin.com: Kconfig.debug - lib/Kconfig.debug - Linux source code (v6.8.6) - Bootlin
09:42:00 <mjg> i don't see any warnings about it either
09:42:00 <mjg> i did not even know this is optional
09:42:00 <mjg> does arch btw have it enabled
09:42:00 <heat> yes
09:42:00 <heat> see all the things that select it too
09:42:00 <heat> like all of tracing selects STACKTRACE
09:45:00 <mjg> i would argue most of these options should get whacked
09:45:00 <mjg> as in make it non-optional
09:45:00 <mjg> how many people even build test all the whacky combinations
09:46:00 <pog> kazinsal
09:46:00 <heat> mjg, maintainers like randconfig, intel ci also builds randconfig
09:47:00 <heat> some arm people might have it off
09:47:00 <heat> the small 32-bit arm
09:47:00 <mjg> fucken' stack traces?
09:47:00 <heat> and so on for all the other shitty embedded stuff
09:47:00 <mjg> i don't think whacking basic debug facilities like this one makes any sense
09:47:00 <mjg> especially for production
09:48:00 <heat> i mean yeah totally, but someone has done it before
09:49:00 <heat> they're probably doing it now
09:49:00 <heat> we need to stop them
09:49:00 <mjg> have you removed latencytop yet
09:49:00 <heat> oh thanks for reminding me
09:49:00 <heat> totally forgot about that
09:50:00 <mjg> maintain a TODO list
09:50:00 <heat> 0. get a girlfriend
09:50:00 <heat> 1. remove latencytop
09:50:00 <heat> though i guess to submit patchen you can't have 0.
09:51:00 <mjg> that's if you submit from arch
09:51:00 <heat> OH
09:51:00 <heat> do you use oracle linux?
09:51:00 <mjg> the L man himself is married
09:51:00 <mjg> but then again, he is not using arch, is he
10:04:00 <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.
10:04:00 * kof673 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
10:04:00 <kof673> that [...] kind of changed the meaning of that excerpt lol
18:19:00 <zid> Good news, my egg noodles are apparently free-range
18:21:00 <GeDaMo> Free range noodles? :|
18:22:00 <zid> Well you wouldn't want them raised in cages would you
18:24:00 <GeDaMo> https://www.youtube.com/watch?v=8scpGwbvxvI
18:24:00 <bslsk05> '1957: The SPAGHETTI HARVEST | Panorama | Classic BBC clips | BBC Archive' by BBC Archive (00:02:45)
19:25:00 <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.
19:26:00 <netbsduser> you must be joking chibill
19:27:00 <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
19:28:00 <heat> yes
19:28:00 <heat> ext4 is the amish filesystem
19:29:00 <heat> not too old, not too modern, not too simple, not too complex
19:29:00 <heat> just right
19:31:00 <heat> ext2 is also good but it has aged a good bit from having linear dirs, not having extents and not having journalling
19:31:00 <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
19:31:00 <chibill> Going to say FAT32 is fairly simple, compared to to everything going on in EXT3, with Inodes, journalling and everything else.
19:31:00 <heat> FAT is simple but it's awkwardly simple
19:31:00 <geist> also supporting all 3 variants is annoying
19:32:00 <heat> like, if you're designing a VFS around FAT you'll end up with an awful awful VFS
19:32:00 <geist> thats' the big issue
19:32:00 <sham1> ext4 is a nice root fs
19:32:00 <sham1> FAAAAAST
19:32:00 <heat> ext4 is reasonably fast and very stable
19:32:00 <heat> xfs is super fast
19:33:00 <heat> zfs is
19:33:00 <heat> fat is bad
19:33:00 <heat> but sadly you need FAT anyway
19:33:00 <sham1> lolefi
19:33:00 <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.
19:33:00 <heat> efi, sd cards, usb drives, etc
19:33:00 <geist> yah keep in mind implementing a full ext4 involves some btrees and journalling
19:33:00 <netbsduser> the principle merit of FAT today is making for an interesting exercise in implementing it in an optimal way
19:34:00 <sham1> EFI_MJG_PROTOCOL_LOLLER
19:34:00 <geist> those two components will probably swamp most of the development effort
19:34:00 <chibill> Currently also stuck in ASM till I finish writing my C Compiler for my system
19:34:00 <netbsduser> ext4 i think it's understandable for people to recoil from a little because of the HTrees and such
19:34:00 <heat> you're writing a BIOS?
19:34:00 <netbsduser> very competent FS though and quite bulletproof
19:35:00 <heat> geist, the journalling is not actually that hard
19:35:00 <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.
19:35:00 <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
19:35:00 <geist> yep. i've generally moved my machines to btrfs over time, but i also like to utilize the snapshotting stuff
19:35:00 <geist> heat: yeah i kow, but it's compared to a lot of other things fairly complex
19:35:00 <geist> the btrees in the dirs are probably most of the effort
19:35:00 <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
19:36:00 <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
19:36:00 <heat> oh yeah totally
19:36:00 <heat> probably not the greatest choice if its your first fs ever
19:36:00 <chibill> Even EXT2 has a log of moving parts compared to FAT32.
19:36:00 <heat> no it doesnt
19:37:00 <geist> the split superblocks and allocation groups and whatnot is pretty annoying
19:37:00 <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
19:37:00 <heat> yeah but then it'd be PESSIMAL
19:37:00 <geist> not for SSDs. that was totally built around spinning media
19:38:00 <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.
19:38:00 <heat> yes, really
19:38:00 <geist> chibill: the big difference is that dirs and inodes are different in ext2 (and pretty much all unix fses)
19:38:00 <geist> which though sounds more complicated, makes things much more straightforward
19:38:00 <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)
19:38:00 <geist> 2 smaller layers in the FS code instead of it mashed together
19:39:00 <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
19:39:00 <geist> most of the complexitiesof FAT and unix vfs is because the dir entry is the inode
19:39:00 <geist> right. dir entries are basically { name, inode # }
19:40:00 <heat> netbsduser, i'm pretty sure a lot of the xfs speed advantages have been attributed to their aggressive use of allocation groups
19:40:00 <geist> and then you have a straightforward way to go from inode # -> inode
19:40:00 <heat> it SCALEZ!!
19:40:00 <geist> heat: sure but you could do the same thing even if they were all in one place
19:40:00 <netbsduser> heat: that would accord well with it being developed, i think, as part of cellular IRIX
19:40:00 <netbsduser> their solution to the scale problem was extreme replication
19:41:00 <heat> geist, in the xfs case they have per-AG btrees so it really wouldn't in their case
19:41:00 <geist> i posit except for the indexing stuff, beos's BFS is actually a pretty good middle ground
19:41:00 <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?
19:41:00 <netbsduser> cellular IRIX is like one IRIX per NUMA domain with interaction governed by something that resembles a distributed system
19:41:00 <geist> approximately ext3 class (journalling) with some ext4 bits (extent based stuff) with extended attributes
19:41:00 <heat> ext4 is basically ext3 with extents
19:41:00 <heat> ext3 is ext2 with journalling and hashed dirs
19:42:00 <zid> where did they add the ENTERPRISE
19:42:00 <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)
19:42:00 <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
19:42:00 <heat> chibill, what bullet point?
19:43:00 <chibill> On https://wiki.osdev.org/Ext2
19:43:00 <bslsk05> wiki.osdev.org: Ext2 - OSDev Wiki
19:43:00 <zid> quick summaries?
19:43:00 <heat> which ones?
19:43:00 <chibill> The ones at the end that says how to read an inode :/
19:43:00 <zid> read the superblock, look up your inode, read the block group to get the inode, read the inode table entry
19:43:00 <zid> doesn't seem much if any more complicated than fat32 to me?
19:44:00 <heat> that looks insanely stupid given that like 2 or 3 steps there are just divisions
19:44:00 <geist> there's a formula to convert inode # to allocation group to physical block #
19:44:00 <geist> it sounds complicated, but really it's just divide inode # by number of inodes per group -> allocation group
19:44:00 <geist> then there's a formula to calculate where each AG starts, and then there's an inode table offset, etc
19:45:00 <heat> ext uses block group, not AG
19:45:00 <heat> basically the same thing, just want to clarify
19:45:00 <netbsduser> allocation group, block group, cylinder group
19:45:00 <heat> cylinder groups are for BSD smellies
19:45:00 <netbsduser> they all mix together in my memory
19:45:00 <netbsduser> the a b and c of grouping
19:45:00 <geist> basically you end up with https://github.com/littlekernel/lk/blob/master/lib/fs/ext2/ext2.c#L199
19:45:00 <heat> block groups are for freedom lovers
19:45:00 <bslsk05> github.com: lk/lib/fs/ext2/ext2.c at master · littlekernel/lk · GitHub
19:46:00 <geist> but point is onc eyou have those routines written, the splitting of dirs to inodes is much more clean
19:46:00 <geist> this is why unix fses can do hard links: a hard link is simply multiple dir entries pointing to the same inode
19:46:00 <heat> what's that ext3 header there for?
19:47:00 <geist> i think the code has some support for ext3, and clever was working on ext4 support (RO)
19:47:00 <heat> doesn't look like its included, you should take that out for legal clarity
19:47:00 <geist> legal clarity?
19:48:00 <heat> yeah, it makes your whole ext driver GPL
19:48:00 <heat> and if its linked with your kernel directly, then the kernel is GPL
19:48:00 <heat> no?
19:48:00 <netbsduser> does it have any actual code in it or just definitions?
19:49:00 <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
19:49:00 <geist> it's just definitions
19:49:00 <netbsduser> it will be fine then
19:49:00 <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
19:49:00 <geist> so probably should just remove it
19:49:00 <heat> maybe, IANAL
19:49:00 <heat> sounds scary to me
19:50:00 <geist> but honeslty i haven't touched most of that in 10 years or so
19:50:00 <geist> for structure compatibiity it's basically a shortcut, since you'd end up just typing it all in the same way
19:52:00 <zid> I however, *am* a lemming.
19:53:00 <heat> KERNEL
19:53:00 <heat> my kernel is now passing most nameitests which is good
19:53:00 <heat> i have become path walking destroyer of unix
19:55:00 <heat> nikolapdp, path walking trivia: given that open(broken_symlink, O_CREAT) just works, does mkdir(broken_symlink) work? if not, why?
19:58:00 <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....
19:58:00 <kof673> i am not ...advocating anything, but you will never find a competent lawyer, there is 1000s of years of illiteracy at play lol
20:12:00 <Ermine> "onyx rocks" -- thomas jefferson
21:31:00 * mjg burps
21:34:00 <mjg> heat: check out what directory i just found on ubuntu
21:34:00 <mjg> heat: /var/lib/emacsen-common
21:34:00 <mjg> :S
21:35:00 <mjg> https://packages.ubuntu.com/focal/emacsen
21:35:00 <bslsk05> packages.ubuntu.com: Ubuntu – Details of package emacsen in focal
21:52:00 <Ermine> mjg naming stylen!
21:55:00 <heat> mjg, poggersen
22:25:00 <nikolapdp> heat, erm
22:25:00 <nikolapdp> i am going to say no
22:25:00 <nikolapdp> why, no clue
22:29:00 <heat> correct
22:30:00 <heat> why would i ask you otherwise
22:30:00 <zid> how do I create symlinks
22:31:00 <Mondenkind> ln(1)
22:34:00 <nikolapdp> zid: ln -s
22:35:00 <zid> in posiik syskallen
22:35:00 <zid> can creat?
22:36:00 <Ermine> symlink
22:36:00 <Ermine> symlink(2) even
22:37:00 <Mondenkind> use system(3) to call ln(1) 4head
22:37:00 <Mondenkind> head(4) even
22:38:00 <zid> but can I with creat
22:38:00 <nikolapdp> i don't think you can
22:38:00 <zid> fake news files :(
22:39:00 <nikolapdp> :(
22:39:00 <Ermine> why would you use creat
22:39:00 <Mondenkind> createn
22:39:00 <zid> creat stronk
22:39:00 <zid> good strong syscall
22:39:00 <zid> make many baby
22:39:00 <Ermine> but it doesn't do symlinks
22:39:00 <nikolapdp> open( , O_CREAT)
22:41:00 <Ermine> I wonder if everyone implement creat through open
22:41:00 <nikolapdp> check sources
22:41:00 <Ermine> i'm lazy
22:41:00 <mjg> i have hard time imaginging why anyone would not
22:42:00 <mjg> if anything why tf is creat available for new programs
22:44:00 <nikolapdp> Ermine, musl:
22:44:00 <nikolapdp> int creat(const char *filename, mode_t mode)
22:44:00 <nikolapdp> {
22:44:00 <nikolapdp> return open(filename, O_CREAT|O_WRONLY|O_TRUNC, mode);
22:44:00 <nikolapdp> }
22:44:00 <mjg> there is still the syscall tho
23:01:00 <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
23:59:00 <heat> mjg, it's very possible creat isn't available on arm64 and newer archs