<klange>
ddevault: sounds like you're stuck in email verification? unfortunately, there's only one person who has any control over the level of things and he is... notoriously difficult to contact
netbsduser has quit [Remote host closed the connection]
nyah has quit [Ping timeout: 265 seconds]
srjek has joined #osdev
frkazoid333 has quit [Ping timeout: 244 seconds]
rpnx has quit [Remote host closed the connection]
dude12312414 has joined #osdev
rpnx has joined #osdev
ornitorrincos has quit []
ornitorrincos has joined #osdev
gog has quit [Ping timeout: 252 seconds]
Gooberpatrol66 has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
_xor has quit [Quit: bbiab]
lentement has joined #osdev
lentement has quit [Ping timeout: 268 seconds]
SpikeHeron has quit [Quit: WeeChat 3.6]
DanDan has joined #osdev
SpikeHeron has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
[itchyjunk] has quit [Read error: Connection reset by peer]
rpnx has quit [Quit: Quit]
srjek has quit [Ping timeout: 264 seconds]
zid has quit [Ping timeout: 250 seconds]
zid has joined #osdev
\Test_User has quit [Ping timeout: 252 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
twitter: <nurhussein> Calvin and Hobbes very succinctly discuss scheduling, context switching, time quantums, and timers in 4 panels and I am impressed. https://pbs.twimg.com/media/Fc_o33eaUAU23i5.jpg
epony has quit [Remote host closed the connection]
lentement has joined #osdev
<zid>
I'm a dirty weeb so I read the panels in the wrong order :(
lentement has quit [Ping timeout: 250 seconds]
[itchyjunk] has quit [Remote host closed the connection]
knusbaum has quit [Ping timeout: 255 seconds]
<ddevault>
klange: helpful.
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
GeDaMo has joined #osdev
pretty_dumm_guy has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
Ali_A has joined #osdev
gildasio has joined #osdev
MrBonkers has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
MrBonkers has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
epony has joined #osdev
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
netbsduser has joined #osdev
WaxCPU is now known as Andrew
NieDzejkob has joined #osdev
NieDzejkob has quit [Client Quit]
Maja_ has joined #osdev
Maja_ has quit [Client Quit]
Maja_ has joined #osdev
Maja_ is now known as Maja
nyah has joined #osdev
<ddevault>
what are some things you need a full blown ACPI interpreter for?
<Mutabah>
Power management mostly afaik
nyah has quit [Remote host closed the connection]
nyah has joined #osdev
lentement has joined #osdev
wootehfoot has joined #osdev
<pitust>
I think there is some PCI interrupt stuff there as well
wootehfoot has quit [Ping timeout: 252 seconds]
<geist>
some device detection, etc. depends on which tables within ACPI you are reading. a lot of he basic stuff the kernel needs to get running (APIC, etc) are all basic tables you dont need the bytecode for
<geist>
but the device descriptor tables (DSDT) are all bytecode interpreted
lentement has quit [Remote host closed the connection]
<geist>
so you have both device discovery and power management there
Ali_A has quit [Quit: Client closed]
isaacwoods has joined #osdev
\Test_User has quit [Ping timeout: 268 seconds]
\Test_User has joined #osdev
<mrvn>
Wing Commander (the movie) shows it's age. Pluto is a planet in the intro map.
[itchyjunk] has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<GeDaMo>
You never know, it might get reclassified :P
<bslsk05>
en.wikipedia.org: Charon (moon) - Wikipedia
<GeDaMo>
Oh, it has five moons :P
<mrvn>
"A planet is a large, rounded astronomical body that is neither a star nor its remnant." Do we have to round it?
<mrvn>
"a celestial body distinguished from the fixed stars by having an apparent motion of its own (including the moon and sun), especially with reference to its supposed influence on people and events." May Pluto guide you. :)
lentement has joined #osdev
zid has quit [Ping timeout: 250 seconds]
lentement has quit [Ping timeout: 248 seconds]
<geist>
indeed. the fact that the earth has one large moon is somewhat unique, in general
<geist>
(and generally considered somewhat important)
lentement has joined #osdev
<mrvn>
Supposedly it strips air from the planet so we don't have a venus situation. stabilizes the orbit. Adds some chaos to the environment with tides pushing along evolution. Lots of theories.
<mrvn>
Anything else?
<geist>
tidal stuff for sure
<geist>
though i guess a lot of it is observation bias: we know there's a bunch of positive effects to having a single large moon re: evolution, tidals, etc. what i guess is less known is what would be the effects of having a bunch of smaller moons re life on planet
<geist>
but then i'm sure there ar epeople that spend their entire academic career discussing this and i'm just some amateur so i dont really know what i'm talking about
<GeDaMo>
I wonder what impact moonlight has
<geist>
oh yeah certainly lots of animals and fish and whatnot key off the moonlight
d5k has joined #osdev
d5k has quit [Client Quit]
<mrvn>
or 2 suns
d5k has joined #osdev
lentement has quit [Remote host closed the connection]
d5k has quit [Quit: Lost terminal]
gildasio has quit [Ping timeout: 258 seconds]
lentement has joined #osdev
dude12312414 has joined #osdev
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
gildasio has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
knusbaum has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
zid has joined #osdev
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
lentement has quit [Remote host closed the connection]
gildasio has joined #osdev
lentement has joined #osdev
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
heat has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
vin has joined #osdev
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
xenos1984 has quit [Ping timeout: 250 seconds]
xenos1984 has joined #osdev
lentement has quit [Ping timeout: 264 seconds]
<Bitweasil>
I don't think "two suns" is a stable configuration unless they're really close to one another.
<zid>
the suns are stable, it's the planets you gotta worry about :P
<Bitweasil>
As far as moonlight, I can't explain the mechanism, but I sure try very hard to avoid being on the road much around a full moon.
<Bitweasil>
... OK, fair. But unless they're so far away that they act as one sun, I don't think there are stable orbits.
<Bitweasil>
It wouldn't be "two suns rising and setting separately" sort of movie-environments.
<zid>
There are, like you said, don't be mercury
<zid>
yea you're not going to have different suns in different areas of the sky
<zid>
they're going to be a few arcseconds wide, a few arcseconds apart
<Bitweasil>
*nods* That's my understanding of it.
<zid>
we already get lots of gravitational wobble from jupiter and saturn etc, it just makes the orbit wobble, it's stable enough for the girls I go out with
saltd has quit [Quit: joins libera]
<GeDaMo>
Clarke's 2010 has Jupiter being turned into a star
<zid>
for the orbit to decay you need beeg gravity, the distance just makes it non-feasible
<Bitweasil>
So many poor taste jokes one could make...
<Bitweasil>
So I think I'll just go with, "Yo Momma makes the orbit wobble!" for my 90s flashback jokes.
<clever>
Bitweasil: as a random thought, lets say jupiter started undergoing stable fusion and became a second sun, its mass hasnt changed, so the orbits of everything in the solar system should be unchanged?
<clever>
but now you have a question, why hasnt it begun fusion?
<Bitweasil>
Ok, but neither would it be particularly bright in the sky.
<zid>
unchanged yes
<zid>
same as if our sun went blackhole
<clever>
yeah, its more likely to impact the outer planets, which will get a very abnormal amount of "sunlight"
<Bitweasil>
Not most of the time.
<clever>
rather then a simple daily cycle, it would be a daily plus yearly cycle
<clever>
jupiters moons would probably benefit more
<Bitweasil>
Different orbital periods. I'm sure someone has written a paper on this. :)
<GeDaMo>
"All these planets are yours except Europa. Attempt no landing there" :P
<zid>
It basically hasn't got NEARLY enough mass to be a sun, and if it did, the center of mass between the two wouldn't be 'inside the sun'
<zid>
it'd be 'inbetween the sun and jupiter'
<zid>
which would have radically different mechanics
<clever>
zid: ah good point
<clever>
zid: and i recent heard somebody pointing out that very thing, with the pluto/charon pair
<vin>
mrvn: most intel architectures have shared L3 with seperate L1/L2. Does that mean a "core-to-core" latency measurement should at least fetch data from L2?
puck has quit [Excess Flood]
puck has joined #osdev
<mrvn>
hyperthreads always share caches. L2 is frequently shared across a socket. But as said, depends on the cpu.
<mrvn>
and you can only fetch something from L2 if it is in L2.
<mrvn>
I'm not sure how coherent x86 cores are. Would a core fetch from the write back buffer of another core?
nur has quit [Read error: Connection reset by peer]
opal has quit [Ping timeout: 258 seconds]
opal has joined #osdev
<geist>
yah i think in the generic case of core-to-core measurements, it is affected by the cache layout, but isn't testing a particular layout per se
<geist>
it's measuring the effective latency
<zid>
It's just "access on one, access from another"
<geist>
as to whether or not say in a shared L3 design the cpus are 'fetching through' an L2 or whatnot, that's up to the implementation
<zid>
and if they're close that involves one pushing it to l2 or l3, if not, possibly to ram, or if you have QPI, across that, etc
<geist>
some cache heirarchies are inclusive, some arent
<geist>
right
<zid>
doesn't matter *how* it does it, you find that out post fact
<geist>
yah
gildasio has quit [Ping timeout: 258 seconds]
frkzoid has quit [Read error: Connection reset by peer]
<mrvn>
Osn't the tool just reporting how often a certain core-to-core transfer happens?
<moon-child>
how often? Presumably it's testing how long it takes
heat has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
gildasio has joined #osdev
<dzwdz>
any tips for checking the correctness of an rw filesystem implementation?
<klange>
If it's one with an existing fsck utility, throw a bunch of operations at it and then fsck it.
<dzwdz>
is fsck reliable enough? i'd assume it was created with half-completed writes or broken disks in mind, and not broken implementations
<heat>
yes it is
<dzwdz>
great, thanks ^^
<heat>
the effects of a broken disk can equal the effects of broken implementations
<heat>
just make sure to pass -f to fsck
<heat>
-f means "ignore the dirty/clean flag of the filesystem" usually
<klange>
I recommend -n as well, to keep fsck from fixing the issues it finds
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<heat>
or | yes n for the style points
<gog>
yes n |
<heat>
fuck
<heat>
i have done the stupid
<gog>
command not found
<mrvn>
gog: you need the "no" tool, much better.
<heat>
there's no no tool
<heat>
there's a yes tool which may or may not output yes
<klange>
alias no="yes n"
<gog>
yes "yes sir"
<heat>
yes yes
<moon-child>
yes'm
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
dzwdz: My suggestion to test your FS: cd linux && while make -j16; do make clean; done
<mrvn>
if you have too much ram then add sync + drop caches
xenos1984 has joined #osdev
<klange>
that would require a lot of tools
<heat>
gog, btw that's not portable
<heat>
some yes implementations only use the first argument
<klange>
there's only one argument in `yes "yes sir"`
<mrvn>
But it's supposed to be "sir, yes sir"
<heat>
oh yes, right
<mrvn>
dzwdz: running torrents on the FS is also a good stress.
<klange>
that requires a network stack and a torrent client
<heat>
klange, those prompts are fucking traumatic
<klange>
(this is why toaruos still doesn't have a disk install option; you _can_ install it to a disk, manually, but I haven't put any effort into this ext2 driver in years)
<heat>
I've realized a good chunk of my filesystem bugs are in the vfs
<heat>
which is why I tested a whole lot with tmpfs
<heat>
memory corruption is a lot easier to diagnose than fs corruption
<clever>
i just recently implemented a `sha256sum --check` routine in little-kernel
<clever>
so rather then hard-coding the test data into the kernel, and validating it
<clever>
i can just `git clone` some random project, `find -type f -print0 | xargs -0 sha256sum > everything.sums`, and then validate it from within LK
<clever>
it already found one TODO i had forgotten about, and bumped into LK's limit of 128 bytes for a path
<heat>
128 bytes for a path isn't a lot
<clever>
yeah
<clever>
LK wasnt really meant to be a kernel, its more of a bootloader
<heat>
what's the difference? :)
<clever>
its meant to just read a few files from a simple path, and then pass control on to that
<clever>
rather then be a full os with a complex file tree
<heat>
it may be easy to get yourself into a complex file tree
<heat>
even when just using lk as a bootloader
<heat>
i had to merge symlinks support to my ext4 efi driver because some systems relied on it for systemd boot loader spec booting
<heat>
things are usually worse than they seem :P
frkzoid has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<clever>
heat: i have also seen features in nixos to deal with that, there is a copyKernels flag, that tells it to copy kernels to /boot
<clever>
so the bootloader doesnt have to traverse /nix/store, and navigate a directory with 119327 children
alpha2023 has joined #osdev
<clever>
but if /boot and /nix/store are on different mount points, copyKernels is forced on
<mrvn>
kind of required for uefi
<clever>
if your kernels are on fat32, yeah, thats a given
<mrvn>
I don't know anyone that wants their OS to run on fat32 and uefi needs that
<clever>
exactly
<gog>
my os is going to run on fat32
Gooberpatrol66 has quit [Quit: Leaving]
<mrvn>
gog: I don't know you. go away :)
<gog>
:9
<geist>
gog: not a bad idea. that's kinda what i'm doing on LK right now, to be honest
<geist>
it's not super high performance, but maximally compatible
<gog>
:D
<clever>
geist: what are your thoughts on the path limit being 128 bytes still? could it be raised? perhaps a compile-time variable?
<geist>
reminds me of the brief period there in NT 3.51 and NT 4.0 lifetime when choosing NTFS vs FAT32 was a real actual decision
<geist>
as in you got compat with win95 and it was actually faster on lower end hardware
<geist>
clever: sure
<geist>
it's fairly unaccptable on embedded systems though
<heat>
PATH_MAX = 4096 and NAME_MAX = 256 ftw
<clever>
i think it would just be a matter of moving FS_MAX_PATH_LEN from a .h file to a .mk file, and allowing it to be changed
<clever>
and as long as everybody uses the constant, it should just keep working
<geist>
well. maybe. it'd make test cases inconsistent, since they'd sometimes fail on different platforms, etc
<geist>
really the strategy is to reduce the need for buffers like that on the stack. i have a solutoin for that but involves rewriting the VFS
<geist>
which i'd like to do some day, but have about 20 other things to do
<clever>
oh, and i had a second idea, openat
<geist>
it's because the current VFS is super dumb (embedded class design) and it puts the entire path on an in-stack buffer at some point
<geist>
and thus the max path len is 128. also generally okay for embedded stuff
frkzoid has quit [Ping timeout: 244 seconds]
<clever>
if we had an openat function, then you could work around the FS_MAX_PATH_LEN being so short
<heat>
yeah but if you rewrite it won't you make it unusable for embedded?
<geist>
heat: possibly, but could change it to do a per-element walk, like a real VFS does
<heat>
I don't see how a $stupid_microcontroller will be able to use a full fledged dentry+inode-cache
<geist>
and that generally reduces the load on having to prorcess the entire path at a time like it currently does
<geist>
heat: well, notice i havent acutally *done* it
<geist>
because it's not just a weekend hack
<heat>
yeah
<clever>
geist: yeah, you could strdup() the whole path, then use strtok() to extract a single element, lookup that in a dir, repeat
<geist>
clever: what is your actual use case here?
<geist>
strdup leans on the heap, generally dont want to use the heap during these ops
<heat>
clever, parsing a path using strtok() is wrong
<clever>
geist: when i was doing the sha256sum --check, one path in the LK source exceeded the 128 byte limit
<clever>
so LK isnt capable of reading every file within its own source
<geist>
okay, well thats definitely ot worth buping the global limit
<geist>
remember most embedded builds have a 1k stack total
<clever>
yeah
<clever>
even the qemu aarch64 test is only 4k, and ive run out once already
<geist>
stack can be increased though. anyway, i'd like to think about it a bit
<clever>
ah yes, i could just request for my app to have a bigger stack, that was mentioned in #lk a few days ago
<geist>
you can do what you want, it's your tree but i'd honstly rather have a single limit. having it be a compile option just means test cases fail here or there in different ways
<geist>
and anyway that ext2 driver dumps way too much on the stack as is
<clever>
yeah
<geist>
but honestly, i just have bigger fish to fry right now, so though you have a problem, it's a synthetic problem
<clever>
yep
<geist>
you came up with a test case that fails due to a known limit
<geist>
and the limit is small, but i'd rather not bump it just to fix a test case you just added locally
<clever>
it did also catch unfinished code within my ext4 support
<geist>
sure, but you dont need long ass paths for that
<clever>
i can modify my testcase, to detect paths over FS_MAX_PATH_LEN, and just not test those
<clever>
so it wont report false errors
<geist>
openat() will be problematic
<geist>
hence why it's not implemented
<clever>
i can see it kinda needing to be done on a per-fs basis
<geist>
exactly
<geist>
what need to really do is decide the direction of the VFS and then go that way. i'd rather keep it simple for simple fses, which are used in embedded designs
<geist>
and then maybe have a more complex path for more complex fses, which can just be not built on embedded stuff
<clever>
but i can also see a way to change things
<clever>
if the path traversal is moved out of the fs implementation, and into the fs core
<geist>
so it might need to morph into some sort of two-headed thing. ie, a simple-fs api for things that sya dont support subdirs and just want the path passed
<clever>
then openat might be a better way forward
<geist>
and then a more unixy inode style fs model for more sophisticated fses
<geist>
and then make the support for either be conditional in the build system
<geist>
but expose the same user api. that lets embedded and non embedded get their own world
<heat>
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL?
<geist>
the hard part is trying to keep it from over complicating the VFS
<geist>
and making sure simple and non simple can coexist
<geist>
anyway, gotta go. meetings
<geist>
i'll think about it, but frnakly i dont have a lot of LK time in the immediate future
<geist>
so do whatcha gotta do
<geist>
also you can mahk keep tossing more and more things i should fix on top of a stack of existing things
<geist>
and i'm literally like 5 or 6 deep, so please stop.
<heat>
what if: simple api that maps to simple api for embedded, and maps on unixy api for non-embedded
<zid>
can I sign up for the double complex api for my cool hw
<geist>
heat: right. hard part is then what happens if you have both active at the same time. ie a simple fs at /simple and a more compex one like ext2 or fat on another mount point
<geist>
can do it on a per mount basis as the vfs parses the path
<geist>
and in the simple-only mode it just skips some of the up front complexity, since in that model simple fses must be mounted at /<first level entry> so it can ust do a O(N) mountpoint match and then pass the trimmed string in
<geist>
which is basically what it currently does
netbsduser has quit [Remote host closed the connection]
<geist>
or more specifically, the current FS api is basically simple mode: mounts must be at /foo /bar, and entire strings are passed off to the fs impl
<geist>
and so the fs impl can choose to support or not support subdirs or whatnot by returning errs or not
<geist>
handy for simple name-value pair style fses you can get in embedded world. even RO ones
<clever>
yeah
<clever>
the alternative i was just thinking of, is where the fs core does path traversal
<geist>
and so probably should grow a second, more complex fs api, and then move things like FAT and ext2 onto that api
<clever>
and it would opendir, and then use openat or opendirat to do traversal
<geist>
which moves to a unixy, piecemeal path parsing model
<geist>
yes.
<clever>
and something that doesnt want to support dirs, would just not have an opendirat implementation
<geist>
that's the 'rewrite the whole thing' i was talking about. move to that model. trouble is the complexity of that goes up a fair amount for simple fses, and you generally need more data in flight to pull it off
<heat>
everyone is violently agreeing and I find that beautiful
<clever>
and openat would only accept the root handle
<geist>
since you'll be creating and destroying vnodes a lot, etc
<geist>
probably inappropriate for deeply embedded stuff
<geist>
i've written both models. the newos fs was that model. more or less cribbed from BeOS
<geist>
but it may also be possible to just skip the simple model, if the regular api stays simple *enough*
<geist>
hence why it's a non trivial problem to solve, since there are multiple axis of design to explore before settling on the right compromise
<geist>
anyway gotta go. meetings
<clever>
yep, also got stuff coming up
<heat>
>looks at time
<heat>
>11:55pm
<heat>
imagine having things to do haha
<clever>
heat: 8pm here :P
<heat>
east coast?
<geist>
a few lateish meetings here, mostly with australians on the team
<clever>
heat: atlantic canada
<clever>
1h further east then usa east coast
<geist>
yah +4 from here
<heat>
4pm isn't too bad for meetings
<heat>
we had them at my CF team for the 'muricans
<heat>
that ended being like 9am for bay area people