<bslsk05>
sdf.org: SDF Public Access UNIX System - Free Shell Account and Shell Access
<Ermine>
there's ahti.space also
<geist>
CompanionCube: yeah, it's surprising (not really) how many shell accounts a modern machine can sustain at once
<geist>
simple command line stuff you probably run out of /dev/tty entries before the machine starts to show load
<geist>
unless everyones compiling at once or whatnot
<heat_>
Ermine, you have an ahti acc?
<Ermine>
I don't
<geist>
nikolapdp: is that yours?
<Ermine>
but you do I guess?
<geist>
like did you write it from scratch?
<heat_>
yeah i have one
<nikolapdp>
no, i ported it geist
<heat_>
sic is what the naz- i mean the suckless people have
<geist>
it is MIT, i might be able to port it to LK. honestly the main reason i dont do much with IRC on LK is because i really have no interest in writing an IRC client aside from the very basics
<heat_>
they think its a great great client
<geist>
oh hmm, seems to rely on select and whatnot
<CompanionCube>
the thing with irc-on-sdf is that they don't include screen/tmux in the one-time upgrade, that's part of a monthly package with mostly other stuff
<heat_>
geist, write a unix
<nikolapdp>
yeah it's waiting on stdin and socket
<heat_>
on top of lk
<Ermine>
heat_: gotta admit that the idea is ingenious, though it's not practical
<geist>
yah i've been fiddling with it fro time to time, but honestly dealing with libc is so much un-fun i just ugh
<Ermine>
like pifs
<heat_>
geist, use musl and implement the linux interface, ez
<geist>
pifs like the things in windows 3.1 to point to a program?
<heat_>
well "ez"
<geist>
heat_: i did make an attempt at it
<geist>
got it kinda compiling
<heat_>
you don't need to deal with libc is my point
<heat_>
musl even packages its own uapi headers
<geist>
i mean i have it kinda working with newlib, but only to the poit that it starts and runs a few user programs
<geist>
but then i got side tracked trying to finish the FAT implementation so i had enough FS to do something interesting with
<geist>
and clever was working on ext4 at the time, so i left that to him
<heat_>
my nvme driver was mishandling the case where i had 2 sgls instead of >= 2 or just 1, so i was writing trash to contiguous sectors when block IO plugging was happening (and i was merging requests)
asarandi has quit [Quit: WeeChat 4.1.1]
asarandi has joined #osdev
vykt has joined #osdev
asarandi has quit [Quit: WeeChat 4.2.2]
asarandi has joined #osdev
asarandi has quit [Quit: WeeChat 4.2.2]
asarandi has joined #osdev
Fingel has joined #osdev
stolen has joined #osdev
Arthuria has quit [Ping timeout: 256 seconds]
GeDaMo has joined #osdev
Fingel has quit [Quit: Fingel]
heat_ has quit [Ping timeout: 256 seconds]
nanobot567 has quit [Quit: Into the abyss I go!]
craigo has quit [Quit: Leaving]
gbowne1 has quit [Quit: Leaving]
op has joined #osdev
rustyy has quit [Quit: leaving]
stolen has quit [Quit: Connection closed for inactivity]
rustyy has joined #osdev
Gooberpatrol66 has quit [Remote host closed the connection]
SGautam has joined #osdev
Gooberpatrol66 has joined #osdev
zxrom has joined #osdev
navi has joined #osdev
leg7 has joined #osdev
leg7 has quit [Remote host closed the connection]
leg7 has joined #osdev
op has quit [Remote host closed the connection]
masoudd has quit [Ping timeout: 256 seconds]
gog has joined #osdev
Left_Turn has joined #osdev
<leg7>
btw
<leg7>
whoever told me I couldn't have the intel manual under cvs was right
<bslsk05>
www.usenix.net: USENIX | The Advanced Computing Systems Association
<bslsk05>
man.freebsd.org: polling
<kof673>
> when done properly, polling gives more control to the operating system on when and how to handle devices, with a number of advantages in terms of system respon-siveness and performance
<kof673>
in particular, it supposedly is better under "heavy load" in any case, some osen have such features
<heat>
yea
<heat>
linux also supports polling on the storage stack
<kof673>
> CompuServe was launched using 36-bit PDP-10 computers in the late 1960s. It continued using PDP-10 and DECSYSTEM-10-compatible hardware and retired the service in the late 2000s. # there is a k&r c compiler, sort of hacked to compile on dos/windows/linux/etc. i believe, and you would then transfer the output and assemble on the target :D
<kof673>
*on github kcc maybe? do not recall
<kof673>
somewhere i read that is why it exists/was "ported", because compuserve was still using it at some point lol
zxrom has quit [Read error: Connection reset by peer]
<zid>
Polling? In my kernel? It's more likely than you think!
zxrom has joined #osdev
<nikolar>
Lol
<heat>
polling is like the most micro-optimization feature one could add to a kernel
<zid>
It makes sense for certain loads
<zid>
a router maybe
<zid>
or file server
<zid>
where you'd rather not get 0 work done because you're getting 800 interrupts a second, and would rather just churn through an ever-lengthening backlog
<zid>
80000*
<heat>
like storage polling makes sense if you have 100 nvmes hooked up and at 100% usage such that hogging the CPU for an extra bit makes sense just to avoid the interrupt churn
<zid>
exactly
<zid>
if load == 100%
<zid>
then interrupts are a waste of time
<zid>
interrupts are mainly useful for wakeup
<heat>
it's basically a "i'm a hyperscaler and need this for a very very specific reason" feature
<kof673>
24-bit, 48-bit (DSPs) i guess too :D > http://chameleon.synth.net/english/developers/ the sdk has a simulator, works with wine, as does the sdk (command-line utils at least) > the only open DSP hardware in the world [*] [* around 2006] > The development tools are completely free and there are no strings attached
<bslsk05>
chameleon.synth.net: Home of the Chameleon
<kof673>
in any case, there are 2 "octal" systems with simulators :D
nanobot567 has joined #osdev
<bauen1>
can someone give me a reality check ? I have an armv7m system, and if I run
<bauen1>
can someone give me a reality check ? I have an armv7m system, and if I run 'bx r1' with r1 = 0x20003439 ; then the processor for the love of everything should NOT attempt to switch from Thumb mode to ARM mode, right ?
op has joined #osdev
craigo has joined #osdev
nanobot567 has quit [Ping timeout: 255 seconds]
CryptoDavid has quit [Quit: Connection closed for inactivity]
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
masoudd has joined #osdev
nanobot567 has joined #osdev
xFCFFDFFFFEFFFAF has quit [Remote host closed the connection]
gog has joined #osdev
xFCFFDFFFFEFFFAF has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
<heat>
is there a good term for "make something positive"
<heat>
negativize sucks, positivize also sucks
<GeDaMo>
Absolutize?
<leg7>
pessimize
<leg7>
optimize
<heat>
GeDaMo, no, this is not a number
<heat>
but negative cache dentry vs positive cache dentry
<bslsk05>
'Why Is C SO Dangerous? #programming #coding #lowcode' by Low Level Learning (00:00:51)
<zid>
heat: positive metaphrically or positive numerically?
<zid>
(close after 3 seconds)
<heat>
his explanation is wrong
<zid>
yea he's an idiot, but the first one second is great
<zid>
better comedian than anything else
<heat>
ok so basically: the directory cache has positive entries (actual files) and negative entries (not files, basically THIS NAME IS NOT HERE)
<heat>
so it's positive metaphorically
<zid>
but
<zid>
what computer wise makes them positive or negative
<heat>
the presence of a file in the filesystem with that name
<zid>
no
<zid>
not what causes it
<zid>
struct { ??? }
<heat>
oh, it's just a flag
<zid>
but it's not a sign bit?
<zid>
it's literally just a flag?
<heat>
yep
<zid>
That's weird, grats
<heat>
this has no relation with numbers at all
<zid>
red and black
<heat>
negative dentries basically just cache the absence of stuff
<zid>
black dentries.
<zid>
Rather than red dentries.
<heat>
which is the exact opposite of a normal cache entry for most caches
<GeDaMo>
"We searched but did not find"
nanobot567 has joined #osdev
<netbsduser>
they have those in dragonfly bsd
<heat>
don't they have them in every unix?
<netbsduser>
negative entries not so often
<kof673>
(paraphrase) "they were digging for the source of the water, but could not find it. they couldn't see because they were blind" [putrification is done in darkness lol]
<netbsduser>
i think the BSD VFS is quite ugly and dragonfly does a much nicer job at it because they use namecache locking to carry out e.g. the lookup-and-if-negative-create which on other BSDs is done by having a special flag to lookup VFS op that keeps the directory locked
<netbsduser>
or i might be thinking of rename
<netbsduser>
whatever be it, i don't care for the 4.4bsd vfs much, they introduced innovations which diluted the cleanness of the vfs as it was in solaris, which it's roughly copied from, but with horrible complicated new locking protocols and the use of the `lock` vnode op for kernel synchronisation purposes rather than just for file locking
nanobot567 has quit [Ping timeout: 256 seconds]
<leg7>
heat you could name the flag `cached`
<leg7>
or `treated`
<leg7>
known
<leg7>
exists
<heat>
i dont need a name for the flag, i need a name for the verb
<kazinsal>
"confirm"
<GeDaMo>
potentiate
<zid>
what action are you performing
<heat>
turning a negative dentry into a positive dentry by the means of creating something at that location
* Ermine
writes down the idea of caching absence of something
<heat>
it's super required for unix filesystem performance, cuz of all the silly queries for shit that doesn't exist
<heat>
locally other caching may somewhat save you, remotely you're dead in the water
<Ermine>
Are that many queries that get enoent response?
<heat>
yes
<heat>
for a quick test just do "command_that_totally_doesnt_exist" in your shell and watch it try to stat for it for every path in $PATH
<heat>
with strace ofc. or just compile a program in gcc and watch it access() or stat() a bunch of include paths looking for your include
<Ermine>
i saw that behaviour in musl execp*
<Ermine>
i see now
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
<kof673>
IMO at some level conceptually/metaphorically if it was memoization, say void * lookup(int a) you would surely memoize all results, not just the non-NULL ones etc.
<kof673>
i don't think it is that strange anyways, just approached from another angle may seem like it is
<heat>
well, that's exactly what you do
<heat>
you cache valid results and you cache ENOENTs (other results are tricky to cache cuz they may be transient)
<kof673>
well transience is a separate issue, but makes sense
<kof673>
was just replying to that > writes down the idea of caching absence of something
<Ermine>
so open(O_CREAT) should invalidate the cache?
<Ermine>
or the entry
<heat>
no!
<heat>
say the dentry is something like
<heat>
struct dentry {unsigned int flags; struct inode *inode;};
<heat>
O_CREAT sees the negative dentry, creates the entry in-filesystem and does "dent->inode = new_inode; dent->flags &= ~DENTRY_NEGATIVE;"
<heat>
done, converted to positive dentry, ezpz
<Ermine>
z
<heat>
it saves me a bunch of work too, cuz you had to create a positive dentry anyway
<Ermine>
ah, i see
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
devurandom has quit [Ping timeout: 264 seconds]
devurandom has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<leg7>
Can someone share their IDT ISR implementation?
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<geist>
the IDT itself, or the implementation of the handlers?
<bslsk05>
github.com: lk/arch/x86/32/exceptions.S at master · littlekernel/lk · GitHub
<leg7>
the idt itself I wrote in C earlier
<leg7>
I would like to know how to fill it up with isrs now
<geist>
then only the top part is of your concern
<geist>
that code does the standard thing: for every vector it implements a 2 or 3 instruction stub that pushes the interrupt number and then branches to a shared piece of code
xenos1984 has joined #osdev
<geist>
which pushes all the state and then calls into C code (x86_exception_handler)
<bslsk05>
github.com: lk/arch/x86/32/exceptions.S at master · littlekernel/lk · GitHub
<geist>
that repeats the stamping out of that macro 256 times
<geist>
in this case, since every entry point is 16 byte aligned, the code that later fills in the IDT can just start at the base of the vectors and add 16 for each of them
<leg7>
What macro is it repeating
<geist>
everything between rept and endr
<leg7>
ok
<geist>
sorry it's not a macro
<zid>
either push i jmp, or push 0 push i jmp
<geist>
it just stamps out that body 256 times
<zid>
for exception vs interrupt
<geist>
yep that's what that if statement at line 25 is
<zid>
push %0 rather, argument 0
<zid>
not an actual 0
<geist>
it skips pushing an extra zero. this way when you get to the C code there's a consistent iframe
<bslsk05>
github.com: lk/arch/x86/include/arch/x86.h at master · littlekernel/lk · GitHub
<geist>
is the iframe that endsup being pushed
<geist>
$ means constant
<zid>
ah okay so it is an actual 0
<zid>
so that you have a consistent frame and it's just padding, right
<geist>
and yeah the other trick as i was saying is it aligns each of those on a 16 byte boundary, so the IDT code that fills it in later can just for offset = 0, offset += 16
<geist>
i used to have the vaneers packed in but the problem is due to the codegen and whatnot they're not a consistent size
<geist>
and the amount of code later to manually fill in every vector is greater than just adding the padding
<geist>
and the padding nicely aligns things for performance purposes anyway
<zid>
I wonder if push rax would be better because smaller
<zid>
or worse because it might stall a bit sometimes
<geist>
cant because we haven't saved rax at this point
<geist>
so can't use any registers
<zid>
you're only pushing it, as a dummy value, it doesn't 'use' it
<geist>
ah i see what you mean. nah i think the push 0 is pretty small
<geist>
anything < 0x80 ends up being like a 2 byte instruction i think
<geist>
it's when it goes over 0x80 that it switches to a 4 byte constant
<geist>
there's a push imm8 form
<geist>
this was a bug that heat hadn pointed out to me a few months ago, because the vaneers for vectors >= 0x80 were 4 bytes longer and i hadn't reserved enough space in the alignment
<zid>
oh yea it's literally 6A
<zid>
pushsx :P
<leg7>
I need to handle interrupts to get PS/2 kb input right?
<zid>
not if you don't use interrupts, yes if yes
<geist>
if you're willing to poll, no
<zid>
no if no
<geist>
but you'll want interrupts soon enough for timers too
<zid>
I still don't have timers, cus I don't have that kind of task switching
<leg7>
wouldn't polling involve a timer that uses interrupts?
<geist>
generally getting interrupts working, at least trapping things and dumping a "i fucked up heres the regs" is about the second thing i'd do
<geist>
which is about where you're at
<zid>
leg7: insteadof while(1) hlt();
<zid>
you do while(1) { check_keyboard(); check_ethernet(); check_...(); }
<zid>
a timer interrupt would stop it catching fire, but isn't needed
<zid>
not that we're recommending it
<zid>
just add interrupts
<geist>
but like i said at least catching all the exceptions and halting the system is pretty good at this point
<zid>
It's actually really eas
<geist>
since you'll be able to debug other failures
<Ermine>
geist: I guess you can't make IDT in C like you did arm vectab?
<zid>
You do 11 magic outbs, and fill out a table and execute lidt
<zid>
done
<zid>
The table is like the gdt but way way simpler
<leg7>
yeah I didn't plan to skip interrupts I was just reading the osdev wiki and it didn' really mention you need interrupts for ps/2
<geist>
Ermine: I could. i did it in asm because it branches to it very very early before C is even ready
<zid>
I mean, you don't, unless you want interrupt driven ps/2
<geist>
really i wish i could hard code it, but that's a limitation of ELF and whatnot
<geist>
since the base address is split across two fields, the linker can't handle that
<geist>
in both asm and C you can't do something like
<zid>
can you not add a relocation type for it? :D
<zid>
HI() and LO() and stuff sometimes exist to generate those etc
<geist>
yeah but they dont exist for x86
<zid>
rip
<zid>
time to port binutils and add a custom reloc
<geist>
wel, ctualy one of the issues is LK also compiles with clang and links with lld, and those tend to be a bit pickier
<geist>
a bit less easy to badger those tools to weird places
<geist>
they'r emore by the book
<zid>
I just use attribute__((interrupt)) which actually works on x86 now!
<geist>
i do that for a few of the arches i haven't put much time into, but they all have a fatal flaw
<geist>
you can't get an iframe from then, because they just pushed whatever on the stack it needs
<geist>
it's nice for quick n dirty ports, but it falls apart super fast
<zid>
it'd work if you had a kernel stack per thing that could interrupt though right? just put away the stack page along with the stack pointer etc. I assume the reason you want to know how much of the stack is used etc is so you can inspect it
<geist>
it's all about having a consistent frame so you can dump the state on error
<zid>
disregard errors
<geist>
it's per arch, but the arches where the compiler has it they just dump what they need to
<geist>
it's true if you disregard errors it's a convenient and probably fairly efficient way to handle the state dump
<zid>
the amd64 one at least is hardcoded and I know what it does.. I could cheat that way
<zid>
it always pushes r11, r10, r9, r8, rdi, rsi, rcx, rdx, rax in that order
<zid>
oh right, boo
<geist>
but at this point i actually want to really press upon leg7 the notion that they (preferred pronoun?) need to build up the debuggability so it can accellerate future development
<zid>
It *doesn't* push r15, because it wasn't used in what was called-into, as as 'optimization'
<zid>
I see exactly what you mean now
<zid>
It'd be nice if there was an option for that
<geist>
yah i think it basically pushes the temp registers, and then the rest as needed
<zid>
yea it just pushes the sysv-abi regs
<zid>
oh wait, no
<zid>
r15 is callee saved, so they *won't* corrupt it
<zid>
this should be fine in all cases
<geist>
indede. though of course depending on that layout is a Bad Idea
<heat_>
yeah when doing an arch port trap handling is like... the second thing i deal with, right after getting a bare bones boot environment
<zid>
yea it's not.. ideal
<zid>
but it should be so robust that most other things will break before it tbh
<geist>
also its per arch and per compiler. no idea if clang or whatnot implements that yet
<zid>
amd64 attribute interrupt isn't exactly getting a lot of churn
<zid>
yea the main issue is wtf do you do on other compilers
<geist>
well, except AFAIK it wasn't implemented a few years ago
<zid>
buut you might end up with 'other assemblers' in the case, so it's not like doing it in inline assembly is going to work either
<heat_>
i do roughly early mmu -> early boot env -> traps -> actual mmu and then add things as the need arises
<geist>
sort of. on arches that implement attribute((naked)) you can do it in C
<zid>
so imo interrupt entry code is probably pretty heavily tied to compiler/assembler/binutils combo enough that you could probably just rely on this *in the gcc case*
<heat_>
eventually jumping to interrupts for scheduling and/or userspace
<geist>
but in that case you're just using inline asm instead of putting it in an .S file
<zid>
yea this is just "my inline asm impl. is attribute interrupt"
<geist>
heat_: yah asically
<geist>
i should formally name it like stage 1 stage 2 stage 3 or something, since various ports in LK are in various places
<zid>
if clang doesn't support it then clang can get its own inline for its weird plan9 syntax
<geist>
like for example, microblaze (i'm thtinking about deleting it since its not really used anywhere) uses the attribute interrupt
<heat_>
i oopsied my namei code into creating a file with a / in it
<nikolapdp>
lol
<gog>
oopsie doodle
<heat_>
anyway NEGATIVE DENTRIES!
<nikolapdp>
does it show up when you ls or something
<heat_>
and refactored a bunch of shit and i think i fixed some more namei tests
<heat_>
nikolapdp, yep
<nikolapdp>
lol nice
<wantyapps>
Yay I got a shell working :)
<geist>
i've neer completely figured it out but i think some shells prune things out of the path too
<geist>
i've seen situations where a path comes into existance where PATH points, and the shell wont pick it up
<geist>
so presumably it keeps a list of dirs that it wont even try next time
<heat_>
there's a cache in most shells, but it's a positive cache only
<nikolapdp>
you need to hash -r to update usually
<geist>
ah, TIL!
<heat_>
but this does mean that if it gets a hit and then you change PATH, it probably won't pick it up
<heat_>
unless you hash -r
<geist>
yah actuall i think it happens when you add some sort of overriding thing in /usr/local/bin or something, and it doesn't pick up the new one
<geist>
hash -r, that's useful. i aways just restart the shell
<clever>
bash will also rehash if you `export PATH=$PATH`
<clever>
even though its a no-op, bash still considers it a change
<nikolapdp>
you're welcome geist :)
<heat_>
iirc hash -r can take an optional argument just to invalidate a single command
<geist>
i've seen hash -r before, i just never bothered to look at what it does
<heat_>
doing just 'hash' prints the hash table
<geist-sdf>
pretty neat
<clever>
oh, neat!
<heat_>
shellz
op has quit [Remote host closed the connection]
<heat_>
i hate unix so so so fucking much jesus
<nikolapdp>
why are you writing one then
<heat_>
i have 2000 lines of confusing path walking
<heat_>
stockholm syndrome at&t version
<nikolapdp>
lol
<kof673>
1) csh i think has "rehash" 2) Bill Gates and Paul Allen originally wrote Altair BASIC using an Intel 8080 simulator running on a PDP-10 at Harvard University. Allen repurposed the PDP-10 assembler as a cross assembler for the 8080 chip.
<kof673>
anyway, i think kcc sort of works to output assembly...but not sure if cross-assembler + linker exist or not...
<kof673>
found that when looking lol
<heat_>
nikolapdp, if you ever want to find out horrible corner cases in path walking just see my namei.c
<heat_>
it found problems in every UNIX
<kof673>
> the cancellation of the PDP-10 line was announced in 1983 compuserve kept going another 20 years or so lol
<geist>
note there's a new rpi based pdp-10 emulator nearly ready for mass consumption