<ExclamationPoint>
i'm not sure if this is the right place, but anyone here try flashing a BIOS chip over SPI? I'm trying to find the details of the CH341A and whether I can just use my own SPI interface
gorgonical has joined #osdev
<gorgonical>
currently trying to decide if the hassle of implementing virtio over a channel is worth it
<gorgonical>
or if i should just roll my own, simpler system without that much abstraction
<zid>
yea you can flash bios chips with made up hw
grumbler has quit [Quit: It's time]
<zid>
(precisely because they're bios chips, the mobo needs to be able to update them, and doesn't wanna have to generate complicated voltages and properly clocked busses and stuff)
<zid>
so they're all spi, which you can bitbang
<zid>
you could technically do it with tweezers, if you had a few months
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
<ExclamationPoint>
zid, that's exactly the answer I was hoping for
<ExclamationPoint>
so I have an arm devboard with spi pins. i've also done SPI EEPROM read/writes before using a PIC16 and MircoChip's C.
GreaseMonkey has joined #osdev
<ExclamationPoint>
the EEPROM i worked with was an LC24 or some such
<ExclamationPoint>
24LC, my bad
<ExclamationPoint>
anyway, what I was hoping for is someone who knows the right datasheet or spi format and addreses, etc.
<zid>
that would depend on the chip
<ExclamationPoint>
herm, this is why I wonder how they all work with this CH341A programmer if they're all different chips
netbsduser` has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
netbsduser` has quit [Ping timeout: 245 seconds]
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
divine has quit [Ping timeout: 240 seconds]
agent314 has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
netbsduser` has quit [Ping timeout: 240 seconds]
divine has joined #osdev
rustyy has joined #osdev
netbsduser` has joined #osdev
Osmten has joined #osdev
valshaped742488 has quit [Ping timeout: 258 seconds]
netbsduser` has quit [Ping timeout: 258 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
valshaped742488 has joined #osdev
zxrom has quit [Quit: Leaving]
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
xenos1984 has joined #osdev
cloudowind has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
netbsduser` has joined #osdev
Osmten has quit [Quit: Client closed]
netbsduser` has quit [Ping timeout: 252 seconds]
danilogondolfo has joined #osdev
GeDaMo has joined #osdev
zxrom has joined #osdev
Burgundy has joined #osdev
Left_Turn has joined #osdev
tixlegeek has joined #osdev
frkzoid has quit [Ping timeout: 248 seconds]
Hammdist has quit [Quit: Client closed]
Hammdist has joined #osdev
<kof123>
> OTHER UNKNOWN KERNELS THAT MAY OR MAY NOT BE FREE LOUD NOISES </anchorman-esque>
asarandi has quit [Quit: WeeChat 4.0.4]
nuvls has quit [Ping timeout: 246 seconds]
asarandi has joined #osdev
tixlegeek has quit [Quit: tixlegeek]
Osmten has joined #osdev
netbsduser` has joined #osdev
orccoin has joined #osdev
<cloudowind>
which ones
nuvls has joined #osdev
<GeDaMo>
They are UNKNOWN! :P
gog has joined #osdev
tixlegeek has joined #osdev
asarandi2 has joined #osdev
asarandi has quit [Ping timeout: 240 seconds]
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
heat has joined #osdev
blop_ has quit [Ping timeout: 252 seconds]
rustyy has quit [Quit: leaving]
kof123 has quit [Ping timeout: 252 seconds]
<cloudowind>
at least something known about them that they are unknown
Osmten has quit [Ping timeout: 245 seconds]
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 258 seconds]
heat has quit [Ping timeout: 240 seconds]
tixlegeek has quit [Quit: tixlegeek]
Hammdist has quit [Quit: Client closed]
tixlegeek has joined #osdev
tixlegeek has quit [Remote host closed the connection]
asarandi2 has joined #osdev
Vercas2 has joined #osdev
asarandi has quit [Ping timeout: 258 seconds]
goliath has joined #osdev
gxt has quit [Ping timeout: 252 seconds]
Vercas has quit [Ping timeout: 252 seconds]
Vercas2 is now known as Vercas
cloudowind has quit [Quit: Lost terminal]
gxt has joined #osdev
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 240 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
nuvls has quit [Ping timeout: 246 seconds]
Nixkernal has quit [Quit: No Ping reply in 180 seconds.]
<heat>
netbsduser`, zid fyi that's not the BKL, but dcache_lock, which was a really big lock around the whole dcache that got torn down like 15 years ago
<zid>
oh it's fucking written on him
<zid>
bkl basically just continually split into smaller locks was my understanding
<heat>
yeah
<zid>
we now have big_kernel_dentry_inode_read_block_percpu_perbyte lock
<heat>
oh, it's worse than that
<heat>
dentry lookups are best case lockless
<heat>
using r c u
<heat>
ref-walk (the backup to the RCU walk) does use per-dentry spinlocks however
<netbsduser`>
c is a nice legacy which its authors have left the world
PublicWiFi is now known as SovereignCitizen
<ZipCPU>
What do you think, C or C++ for OS development? I might argue C++ handles classes and objects better, both of which are required for OS development. Otherwise you have a lot of C structs with function pointers in them and ... that's just not that pretty.
<heat>
they're both fine but C++ is harder to use properly
<ZipCPU>
Go on .. ?
<heat>
C is simpler hence less abusable
<ZipCPU>
Are there particular features of C++ that are harder to use properly?
SovereignCitizen is now known as PublicWiFi
<heat>
C++ has exceptions and RTTI and the C++ standard library
<heat>
which are all unusable or unadvisable to be used
<heat>
freestanding C++ headers are almost a no-show
<heat>
like If You Know What You're Doing it's not a bad choice
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
but it is tricky
<ZipCPU>
Yeah, I was wondering about how the exceptions would get handled ...
<heat>
and then the typical C++ problems "don't abuse templates" and stuff, or you suffer the consequences of 40s file compile times
<heat>
(overusing templates can also lead to code bloat, which isn't good for a kernel)
<gog>
you can use exceptions in bare metal code bt you need a lot of support code
<ZipCPU>
That's fair, but ... those templates do offer some very valuable capabilities. They'd be nice to have
<gog>
and it's not performant
<gog>
performant!!!
<heat>
the only thing I'd ever miss from C++ in C would be RAII wrappers
<heat>
because sometimes gotos get hairy and annoying
<gog>
__attribute__((cleanup))
<heat>
nothing in the C++ standard library is actually reusable in a kernel setting
<heat>
you can __attribute__((cleanup)) my ass
<gog>
fuck you heat
<heat>
OH and lambdas too, lambdas are nice
<heat>
fuck you gog
<gog>
why are you being mean to me today
<heat>
wdym
<heat>
i'm being nice to you
<gog>
:(
<heat>
i searched for react alternatives
<heat>
it's not easy
<heat>
you should realize i got way too many results
<netbsduser`>
ZipCPU: i opted for c and objective-c since message passing is integral to my kernel (e.g. in the i/o stack)
<heat>
>objective-c
<heat>
you're a funny individual
<netbsduser`>
like many people i have experimented with C++ and enjoyed the experience, but i just can't keep track of that language at all
<heat>
my C++ is very C-like anyway
<heat>
im very very picky in what i like to use for C++, particularly in a low-level setting
<ZipCPU>
netbdsuser`: Sigh. It has gone a bit off the rails with new features, now, hasn't it? I do like the basic class structure it offers though.
<heat>
userspace is whatever, i keep exceptions on and std::vector that shit and whatnot
<heat>
if it's not for its standard library i wouldn't really use it in userspace
<netbsduser`>
there are a few things i quite like the look of in C++, like the way automatic variables invoke their destructor on scope exit (good for lock scoping and such)
<ZipCPU>
I just feel that, when I develop my OS in C, I'm building C++ structures in a backwards manner
<heat>
are we just skipping over the fact that YOU'RE LITERALLY USING OBJECTIVE C
<netbsduser`>
and the coroutines would be useful (i have to hand-roll state machines for async i/o and the result is that i give up and post complicated things like disk fs reads to worker threads)
<heat>
ZipCPU, yeah and that's fine
<heat>
it also gives you *more control*
<netbsduser`>
objc was a logical choice, i know the language, i once maintained and extended a compiler for it, and it gives me the meta layer that i like
<heat>
netbsduser stole from apple which stole from netbsd
<heat>
sgtm
<heat>
ok heat@
<heat>
oh and netbsd stole lua, everything flows back to lua at some point
<Ermine>
gog: may I pet you
xenos1984 has joined #osdev
<gog>
Ermine: yes
<gog>
omg i found a way to make it work
<gog>
yes
<gog>
fuck yes
<gog>
thanks for nothing #oswebdev
Hammdist has quit [Quit: Client closed]
* Ermine
pets gog
* gog
prr
<gog>
thank you Ermine
<gog>
you've been of great help to me today with pets alone
kof123 has joined #osdev
ExclamationPoint has joined #osdev
zxrom has quit [Quit: Leaving]
<Ermine>
gog: you're welcome :)
blop_ has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Hammdist has joined #osdev
<sham1>
heat: could be worse, netbsduser` could be using swift
<ChavGPT>
bro
<ChavGPT>
netbsduser could be using netbsd
<ChavGPT>
which i suspect they don't
* ChavGPT
unpets gog
* Cindy
pets gog :3
* ChavGPT
unpets gog
<Cindy>
my pets are unpettable
<Cindy>
because my pets are owned by me
<sham1>
Stop unpetting gog
<ChavGPT>
and my pets cannot be masked
* Cindy
pets gog
<Ermine>
nodisard
* Ermine
thinks of joke with 'Lego C' and 'legacy'
<netbsduser`>
i experimented with swift but found it a bit of a hassle to figure out how to use swiftc in a sane, sensible way
gog has joined #osdev
jeaye has quit [Quit: WeeChat 3.7.1]
levitating has quit [Ping timeout: 264 seconds]
levitating has joined #osdev
jeaye has joined #osdev
tixlegeek has joined #osdev
<gorgonical>
who knew that the virtio spec was designed decently, huh
<gorgonical>
I spent all last night accidentally re-designing it while trying to avoid designing it
<gog>
oops
<ChavGPT>
:P
* ChavGPT
pets gorgonical
<gorgonical>
It happens I guess lol
<gorgonical>
My notes: "I don't have time to implement virtio so I'll hack up something simpler as a proof of concept."
<gorgonical>
oops
<netbsduser`>
gorgonical: implement a storport shim and use the windows drivers if you really want to avoid it
<geist>
yeah it's not bad
<geist>
only thing i've seen that's 1 notch slightly better in the way it deals with command buffers is nvme
<geist>
but i forget precisely what it was, but pretty similar when it comes to it
<geist>
there's only so many ways to queue up little transfer block
<gorgonical>
for now I have given up and have resorted to a 1-slot ring buffer that blocks when there's no slots left. Research :)
<geist>
all this aside i do recommend writing a virtio library or whatnot to deal with the command queues, once you get that nailed you can pretty easily build a whole pile of pretty useful drivers
<geist>
though of course only in emulators
<gorgonical>
I don't know why I started with such an aggravating driver/service first
<gorgonical>
I started with an mmap service so I have all these weird behaviors with zero-copy I'm tryign to design in from the get-go
<netbsduser`>
virtio isn't so bad
<netbsduser`>
for zero-copy it's ideal
<netbsduser`>
and geist is right
<gorgonical>
yes the scatter-gather thing is interesting
<netbsduser`>
you implement it once and, by god, you have a fast path to 25 or so different devices
<geist>
also notably vidro and nvme and whatnot are designed around having a minimum amount of doorbell writes, so the number of VM traps is at a minimum
<geist>
iirc that may be the thing that nvme does one better. maybe one less doorbell? something like that
gog` has joined #osdev
gog has quit [Killed (NickServ (GHOST command used by gog`))]
<geist>
re that fixed preemption point thing i've never really considered it, and dunno if it's more or less a good idea nowadays
<geist>
i've only ever worked with systems that are fully preemptible except where disabled
<geist>
instead of the other way around
<ChavGPT>
i think this boils down to how good your scheduler is
<geist>
i had just learned that from beos. for better or worse, really
<heat>
yeah i agree
<ChavGPT>
i'm confident linux started like this because it is the easy way out
<ChavGPT>
note same thing happened in unix
<geist>
yeah i think that was also a fairly standard way to do it back in the 90s
<geist>
being fully kernel reentrant would have been pretty edgy tech back then
<heat>
i think it makes a lot more sense to have full preemption instead of sprinkling cond_resched() fucking everywhere in a stupidly unscientific way
<geist>
*early* 90s too
Left_Turn has joined #osdev
<ChavGPT>
i also note linux injects cond_resched by hand ot this very day
<ChavGPT>
as in they keep getting reports of stalls without it
<ChavGPT>
linux devs inject*
<heat>
and for desktop, mobile, RT PREEMPT=y is freaking essential
<ChavGPT>
pretty caveman
<geist>
but i'm sure there are lots of scenarios where the full preemption is a hinderance
<ChavGPT>
again i'm confident it boils down to your scheduler settigns mate
<heat>
yeah i mean, on server workloads it's slightly worse for throughput
<ChavGPT>
then you could tweak to "this is a server bro"
<ChavGPT>
except scheduling keeps being bad
<Ermine>
Injections of cond_resched are like slapping flex tape
<geist>
you probably avoid a fair amount of lock contention which is the hidden cost
<heat>
well yes but no
<geist>
since you can hand tune exactly whre preemption happens you can avoid a fair amount of nested locks and whatnot situations
<heat>
linux is like 80% spinlocks anyway
<geist>
this is true
<ChavGPT>
this one is not a problem dawg
<Ermine>
heat: I used to run RT PREEMPT kernel with ubuntu, noted no difference
<ChavGPT>
you can /count/ held locks
<ChavGPT>
and decide whether to preempt based on it
<geist>
well, if they're spinlocks. if they're preemptable style locks you have to deal with priority inheirance or whatnot
<heat>
Ermine, probably not perceptible to a hooman no
<heat>
but there absolutely will be throughput differences
<ChavGPT>
they are all spinlocks cause it was the easy way out
<ChavGPT>
note they are defo not spinlocks when running with the rt patchset
<heat>
throughput will be ordered like: PREEMPT=n > PREEMPT=y > RT_PREEMPT
<geist>
yah for better or worse i never design systems that way, i tedn to build kernels as sort of an extension of the user space programming model
<ChavGPT>
you know who did that?
<geist>
ie, mutexes, full preemption, threads in the kernel, as if they were a user process somewhat
<ChavGPT>
SOLARIS
<heat>
mutex_enter!
<ChavGPT>
no joke, a positive remark:
<ChavGPT>
they have full prio propagation throughput userspace locks to in-kernel mutexes
<ChavGPT>
thorought
<heat>
but yeah spinnies are not spinnies in RT, raw spinnies are still spinnies though IIRC
<geist>
sure. that's not a particularly unique design
<Ermine>
and fedora's kernel is PREEMPT_DYNAMIC
<geist>
lots of systems are fully preempt like that. it's the only way i really ever do things, seems natural to me
<ChavGPT>
i have no opinion
<heat>
Ermine, that's funny, they discussed it in that thread i linked
<heat>
PREEMPT_DYNAMIC still has unconditional preempt count maintenance
<heat>
the only thing patched out by default is the actual preemption code
<ChavGPT>
linux preempt code is a total f-worded mess anyway
<ChavGPT>
they have 2 different ways to check for it and they are not compatible afaics
<ChavGPT>
also __might_sleep checks if you can sleep
<geist>
yah seems like a lot of this, and the maintenance of the 3 separate mechanisms always seemed like it works well due to sheer force of will
<ChavGPT>
but __might_resched PERFORMS THE RESCHED
<ChavGPT>
gg
<heat>
yeah thats weird
<ChavGPT>
i *suspect* this is to reduce the number of hand-rolled cond_resched's
<Ermine>
so, how desktop is supposed to benefit from rt?
<heat>
you're not
<heat>
RT isn't for desktop
<ChavGPT>
better interactivity mon
<ChavGPT>
SUPPOSEDLY
<ChavGPT>
well in this context i think the q is about preemption
<ChavGPT>
not rt guarantees
<heat>
RT is for realtime systems, industrial shit and whatnot
<Ermine>
> and for desktop, mobile, RT PREEMPT=y is freaking essential
<geist>
also very low latency stuff like this can help for things like audio mixing and whatnot
<geist>
which linux has been traditionally bad at
<heat>
Ermine, sorry, my bad
<ChavGPT>
ye i poked on linux a bit in recent days
<heat>
I meant RT/PREEMPT=y
<ChavGPT>
i'm very negtiavely surprised by the internal state
<heat>
PREEMPT=y is perfectly great for desktop and mobile
<ChavGPT>
tons of churn all over adn total crap remains intact
<ChavGPT>
DOES ONYX PREEMPT
<heat>
yes
<ChavGPT>
:O
<heat>
i picked that up from the osdev wiki/general osdev wizardry knowledge early on
<geist>
like i said it's not that weird to have a fully preemptable/reentrant kernel. if you design it that way from the get go it makes sense
<heat>
and i like it
<heat>
the only thing is that i do abuse spinlocks
<geist>
you can later on add preempt_disable/enable via some counters or whatnot to avoid some negative cases, but by default having it on is a fine solution
<geist>
also for SMP
<heat>
and i still don't have a preemptible RCU
<ChavGPT>
ya sak bro
<ChavGPT>
geist: arguably you run into the opposite case than linux
<ChavGPT>
preemptible lock have the problem of degrading into next to no throughput
<geist>
indeed
<geist>
that's the fun part
<heat>
what
<heat>
that's the unfun part
<ChavGPT>
*un*
<ChavGPT>
too much netbsd heat
<heat>
defun
* heat
turns into a legacy K&R C codebase
<ChavGPT>
noice
<heat>
or lisp
<heat>
but lisp is irrelevant
<ChavGPT>
btw do you know what one of the biggest bottlenecks is on linux
<ChavGPT>
when doing make -j $BIGNUM bzImage?
<ChavGPT>
same shit as on freebsd!
<ChavGPT>
fucking pipe poll handling
<ChavGPT>
which on freebsd gets even worse cause preemptible
<heat>
cheers geoff
<ChavGPT>
btw i figured i'm going to patch bsd make to use eventfd instead
<heat>
pipe_poll is lockless btw
<ChavGPT>
and then i figured i'm going to patch gnu make to do the same
<heat>
why eventfd?
<ChavGPT>
but then i remembered gnu make advertises "jobserver" outside of itself
<ChavGPT>
so the idea does not work
<ChavGPT>
heat: after you poll and find nothing you queue yourself up for sleep 'n shit
<heat>
just use epoll
<ChavGPT>
there is a patch to use kqueue for bsd make
<ChavGPT>
it does help but not anywhere near as much as necessary
<heat>
given the pipe_poll impl is lockless it *should* eliminate all problems
<ChavGPT>
one thing you are probably not aware of here is how stupid the make's of the world are about the pipe
<heat>
if not, you're screwed
<ChavGPT>
ultimately using pipe here is an obsolete model to begin wit
<ChavGPT>
with
<heat>
unix tradition!
<heat>
go write win32 code if you don't want pipes
<bslsk05>
github.com: src/sys/kern/kern_exec.c at trunk · NetBSD/src · GitHub
<heat>
ChavGPT: what's the problem with clone
<heat>
"it's not rfork" is not a problem btw
<ChavGPT>
it's a tumor on the old hack
<ChavGPT>
people did not have threads, only processes
<ChavGPT>
then they added threads as special-cased processes
<heat>
well, yes but no
<ChavGPT>
this is your rfork and clone
<heat>
1) it's not required
<heat>
2) i've grown to somewhat enjoy that threading model
<ChavGPT>
i am saying clone is a result of histerical problems
<heat>
even if its somewhat hacky
<netbsduser`>
threads aren't special cased on netbsd
<ChavGPT>
which went unfixed
<ChavGPT>
and are probably unfixable
<netbsduser`>
the traditional process/thread separation is implemented as proc/lwp
<ChavGPT>
netbsduser`: they are not special cased on freebsd and solareis either
<netbsduser`>
ChavGPT: it is known
<ChavGPT>
it is mostly linux which never fixed that
<netbsduser`>
they say on gnu/linux they used to have an elaborate system of tricks in glibc to implement green threads that acted as best as they could as true threads
<netbsduser`>
this solution involved much signals and other such things
<ChavGPT>
mate early linux was a clusterfuck of epic proportions
<netbsduser`>
supposedly they never solved the problem of how to make a synchronous system call without blocking the whole set of fake threads
<ChavGPT>
today it is half whiped into shape
grumbler has quit [Quit: It's time]
grumbler has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
<cloudowind>
whenever i need to turn left i will remember you Turn_Left
FreeFull has quit []
<Turn_Left>
sure thing cloudowind :) ... off to bed... night :)
Turn_Left has quit [Read error: Connection reset by peer]
<Ermine>
heat: probably, but it'll be major change to minix process model anyway