<epony>
and theeen.. there are "in progress" networked operating systems behaving like a large operating system "environment" emulating parts of an operating system with a cluster of computers (high performance large scale web application systems)
<epony>
not a hobby project, but development work is happening there and likely not propagating back, or even applicable or anyway nearly as defined as the elements of standards "approaching" operating system
<epony>
the AWS and GCP and portal web services the likes of Wikipedia or Youtube / Facebook could be examples of such
<gog>
we use a few amazon services
<epony>
so, there are much bigger projects than an micro-computer operating system "kernel" to get lost into ;-)
<gog>
aws, s3 and dynamodb namely
<gog>
i like dynamodb a lot
<gog>
i think we should rely less on our rdb and more on dynamodb
<epony>
but Linux has grown a lot.. mostly on drivers, should not be "that" complex compared to another UNIX-like system the likes of the more "progressive" say FreeBSD
<gog>
but currently we only use it for caching live service stuff
<epony>
I wonder how realistic of a "usable" system that Redox thing is..
<epony>
cause merely on 'safety' features, makes no sense.. supposedly it's in the mini-kernel type and that's about as much.. having exbloating applciations "with safety"
<epony>
probably it would be work porting a mini-variants of the AWS services as applications
<epony>
"worth"
<epony>
would probably make sense having that standard apps to do distributed computing part of a POSIX-like / UNIX-like system
<epony>
GOOG supposedly does interesting things with the kernel setups too, and their 'database sharding' stuff
<epony>
a mini Google applications (open) for UNIX as server-client model would be nice to have too.. so much options to up-up the current userspace application servers
<epony>
and then, the portable langua-to-language tooling to facilitate prototype to high performance application refactoring (and application / server-client construction modular toolkits, will fix the browsers and office suites and integrated development and cad/cam systems once and for all)
<epony>
to become throughput sustainable load capable application suites like email and other application servers
<epony>
at some point soon all of these progresses should come up aligned and open up and compete and standardise, cause as it is now.. is a largely incompatible jungle-adhocs
<epony>
shoould be quite interesting times to see these become approachable and availble for public groups (or get re-implemented as constructors' tooling0
<epony>
I think there is value and points making it worthwhile re-implementing parts of or entire systems.. with extra "optimisations" or meaningful changes.. even on hobby projects and individual scale (but it's just a lot of work without construction toolkits, so the OS constructors workbench is the project to work on too)
<epony>
as in kernel compilers collection ;-)
<epony>
can't be bad to have modularity, interchangeable systems components and standardisation on these parts.. that'd fix applications in general
<epony>
and "allow" for the run to the optimums for local and distributed as cliend-server / grid-parallel compute toolkits
<epony>
might as well give it the nudge (coinciding with parallel and many-core CPUs access for general computers) to go beyond monolithic kernels into well defined and high performance modular kernels too
dude12312414 has joined #osdev
* epony
pulls hard on the air brake: "SOON" and "TODO"...
<geist>
oh wow, i look away and there's a wall of epony
<geist>
just ran into more verification that MSR access to FS_BASE and GS_BASE is slow as hell, and how much faster fsgsbase instructions are
<geist>
like in the range of hundreds of cycles on a modern intel machine
<qookie>
makes me wonder how those compare to having a self pointer at offset 0 from gs/fs
<geist>
well accessing *through* fs/gs i dunno
<kazinsal>
geist: I've been used to the ignore feature on chat clients just going "HORRIBLE JERK DETECTED CLICK HERE TO READ THEIR MESSAGE" so irccloud just making the messages disappear and leaving a wall of bslsk05 barfing out wikipedia links seemingly at random is pretty funny
<geist>
pbx: so here's my obvious beef with intel: when they added fsgsbase instructions, they didn't add a third supervisor only one that accesses the alternate gs register
\Test_User has quit [Ping timeout: 252 seconds]
<geist>
if yuo are in supervisor mode and want to save the user gsbase you have basically no choice but to disable ints, swapgs, rd/wrgsbase, swapgs, restore ints
<geist>
and you still have the NMI problem in the middle of that sequence
\Test_User has joined #osdev
<geist>
but since the fsgsbase instructions are *that* much faster than using the MSRs it's worth it
Test_User has quit [Client Quit]
<pbx>
like i said, can't comment much, because work
<geist>
heh
<geist>
though really it's AMDs fault in this case for adding the horrible banked gs with swapgs nonsense
<geist>
should have at least had a `setgs #0` `setgs #1` solution which would have solved a bunch of stuff
hellstabber5 has joined #osdev
<geist>
toggle based things are always a huge source of problems
<kazinsal>
yeah, a `setgs imm8` would have been nice
<geist>
i can't possibly imgine any advantage of swapgs over a setgs *except* it's one less instruction and/or easier to decode because no imm
<zid>
FRED is the solution to all problems, we just need to wait until 2045 until it can be loosely relied on
<geist>
exactly
<heat_>
sup
heat_ is now known as heat
gog has quit [Ping timeout: 268 seconds]
<heat>
re fsgsbase
<heat>
idk what took linux so long to get support for it
<heat>
there were apparently a bunch of edgecases
<heat>
they took like what, 6 years? something ridiculous like that
nvmd has quit [Quit: WeeChat 3.6]
maxdev has quit [Remote host closed the connection]
<geist>
you mean user space support or kernel support?
<geist>
user support i think has a bunch of edge cases yeah, since it now allows the changing of it to exist outside of kernels control
<heat>
kernel
<heat>
I don't particularly understand *why*
<geist>
yeah probably some good reason though
<heat>
it took 5 years from the first posted patches to LKML to merging
<heat>
13 versions...
<heat>
yeah for sure
<geist>
it sees to have the general same restriction as the MSR stuff though: you must always load a canonical address
<geist>
or #GP land
<geist>
so it doesn't seem to be intrinsically more dangerous
<geist>
except or the swapgs;rdgsbase;swapgs problem. that may be part of it
<geist>
depending on how NMIs are handled
<epony>
there is nothing wrong with reading other people's texts, what you do not like is tone and attitude, and that's because yours is getting in the way, just keep skipping anything you disagree with, might one day lead you to democracy and education ;-) just a joke.. it won't
<heat>
do you guys properly handle NMIs in zircon?
<heat>
AHA
<heat>
this makes sense
<heat>
reading the osdev wiki
<heat>
"In this situation, there is another method to determine whether GS needs to be swapped -- by reading the value of GSBase from the MSR. Note that this is a slower process, and it is advisable to only do this method of checking "in an NMI/MCE/DEBUG/whatever super-atomic entry context". (according to Linux) "
<heat>
I know they had issues sanitizing the gs base value since now userspace can write whatever
<heat>
they used to assume negative = kernel, positive = user
<geist>
and yeah we added an nmi handler that does not assume the gs is in a particular state
<geist>
it's only really for extreme debugging so it's going to fail
<heat>
that reminds me
<heat>
i was going to check if the lapic timer could trigger NMIs
<heat>
I vaguely remember something similar
<geist>
oh yeah that's right: re used writing it. the hardware only checks that it's canonical, not that it's user space only
<heat>
ah yes, this is funny
<heat>
you can configure timer irqs with all sorts of delivery modes
<heat>
you could even configure it to trigger INITs lmao
<geist>
yah would be slightly interesting to see if that is bothered to be emulated now. in the original APIC that would have been no big deal because the INIT line was just a pin on a chip
<geist>
reading and grokking the original APIC chip docs is kinda interesting, since it gives a back history as to why a bunch of that stuff is arcane and weird
<heat>
if amd is allowed to fuck up zen2's rdrand like 3 times, intel can fuck up exotic apic delivery modes
<heat>
if you're talking about the IO APIC, you still need those docs
<heat>
they aren't described in the SDM
<geist>
or at least not so much weird as ananchronistic
<heat>
the APIC is pretty sane
<geist>
possibly, though it should be at this point, there being an ioapic in every intel and amd soc at this point
<heat>
the PIC is very basic though
<heat>
the PIC smells like early electronic engineering
<heat>
with all the latches and shit
<geist>
yeah it's the weird parts bout INIT/STARTUP/etc that seem strange, but make sense when you understand the original APIC
<geist>
yah it's just late 70s era tech
<pbx>
i mean, the PIC used to just be a seperate chip
<bslsk05>
cleverca22/3D - A 3D renderer written in QBasic that I wrote around 2003-2004, when I was 16. It renders XYZ triplets and wireframes to the screen. (1 forks/2 stargazers)
<clever>
pbx: the most crazy thing i did when i was a teen (and still have records of), is this 3d rendering engine
Ram-Z has joined #osdev
SGautam has joined #osdev
<epony>
clever, I did a similar thing for plotting math functions on my luggable 80286+80287 12/20MHz 1024KB RAM with ST-225 20MB half-height and 1.2MB both 5.25" FDD and built-in amber CRT monitor driven by a CGA card.. during the early 90ies with Turbo C
<epony>
and a wireframe floor plan & walls in 3D slow scan render
<epony>
and a serial console program, of course
<epony>
was in high language school then, grades 8-9
<epony>
which is about similar age maybe 1-2 years earlier
<epony>
the QBasic really sucked, you could not compile it out
<epony>
and Turbo Pascal was not producing efficient enough binaries in my case
<epony>
so the system could only fit the two compiler toolkits and my programs and the DOS utils
<epony>
I liked it a lot and used it with an external monitor (colour) on top of the case
<epony>
it's funny how people try out same things in similar ages ;-)
<epony>
different machines / gens
<epony>
there was no internet, and I also did not have C programming books and the Pascal books I got were for 8bit machines (UCSD)
<epony>
but I had the 8086/8088 and 80186 system programming books.. and got one for 286/287 assembler ;-)
<epony>
and an year later a C textbook
<epony>
I still remember the sounds of the drives of the machine and its fan and FBT noise pattern.. and I could power it off when I went on transmit on my handheld 2m 5W porable radio transceiver
<epony>
it was a decent machine for it's day.. a later improved compaq ii clone.. branded 3C
<epony>
horizontal drive arrangement and front panel detachable keyboard, with side cover slides for the ports and the expansion cards
<epony>
and a big luggable handle on the case and prop-up feet-stands
[itchyjunk] has joined #osdev
<epony>
that box for following me around the house until I built my first 200 MHz p55c (Pentium MMX)
<epony>
the luggable is in the attic, the p5 still runs (in working order and fully populated and recent software
<epony>
before that I played with a couple of PDP-11s with specialised HDD controller arrays and 8" floppies (keeping some parts of all of these and later machines), two different teletypes one of them model 33 with a tape punch & reader, several RTTY modems and big military transceiers amplifiers, a couple of DEC terminals 50 and 100/220 series, a few local made 6502 clones with dual floppies and RTTY modems, all the IBM PCs models original with HDDs and local clones
<epony>
in the 8086/80186+7 variants, a couple of HP9K machines, and this luggable priceless 80286+7
<epony>
and an assortment of matrix and impact printers and PCB functional testing machinery..
<epony>
up to the laser printer and inernet years ;-) a fantastic really fun and very lucky ride in industrial environment at parents workplace
Ram-Z has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.6]
<epony>
what I really missed were i386/i486 at home and low speed dial-up modems before v34 (if that can be a real miss of any sort, had such at school and work)
ThinkT510 has joined #osdev
<epony>
I also had an IBM Selectric type machine at one point and used it to type out some short texts.. bore its ribbon head drivetrain malfunctioned (had a cople of steel spring lines that were "delicate" apparently)
<epony>
so the two fuck-up failures I've experienced in all of these 40+ years of compute (got a lot more after the p5) were the FBT on that amber CRT monitor and that IBM type machine.. that Teac 1.2MB FDD from 1988 still works today too.. the optical drives are not so fancy-durable though, got one of those CDR and one DVDR fade in time.. a lot more other optical and HDD drives, never had a single failure since 1996..
<epony>
by some interesting coincidence, all of the HDDs I ever used were Seagate, and I got one failing to meed RAID controller timings in the "enterprise" series, and one other with a BIOS reflash fix-up in the 1TB years.
<epony>
the rest is all good and works fine from the 20MB model, through the 3.4-4.3-5.4-6.2-8.4-12.3-20-80-200GB-1TB-2TB models to the recent 4 and 8 TB models
<epony>
of all these years.. only 1 WD blue 160GB for a legacy industrial machine
<epony>
and I've seen other people cry a lot with 20x and 50x batches of Maxtor slim drives ;-) and IBM Caviars and WD all series, lots of tears of those "unlucky folk"
<epony>
never had a single HDD die on me ;-) ever since the 80ies to now
<epony>
the most fun was quad-booting on two machines with serial and parallel networking and later re-using them as Inernet servers in an ISP setup
<epony>
the worst fun was 3Mbps FHSS wireless longhaul link before 802.11b and focking RedHat malware
<epony>
The stupidest OS of all is Windows ME, as stupid as Win 3.1 and the other very stupid and useless OS was.. OS/2 and CP/M these hold the title for stupidity all around
<epony>
the best OS experience I've had so far is.. surprise, OpenBSD and FreeBSD and Linux in the desktoy early Slackware 1996-1998 years
<mjg>
wut
<epony>
after that, Linux was obsolete for me.. the 2.2 kernel was alright, 2.4 kind of fine, 2.6 I liked too, and after that I have not used any Linux on my desktops and infrastructure machinery, just at work and remote premises
<kazinsal>
mjg: the ignore mask you are looking for is *!epony@user/epony
<epony>
kazinsal, eat shit dickhead ;-)
<kazinsal>
(presumably I have now been insulted in some manner)
<epony>
of course, what else do you expect, Xmass gifts
<epony>
the expletive was probably about the dissing of OS/2 and CP/M which have a high following, but for me and for a large group of "gneral application, provisioning and professional use" these systems make no sense, CP/M required and Z80 co-processor board in both the 8bit and 16bit machines we were using.. and the particular "variant of CP/M" we had acquired, remember, we do not live in the excess abundance of your 20 year delayed post-market requisite stores (it
<epony>
was what could travel through the iron curtain and reach this area)
<epony>
and OS/2 had no applications and looked like a failed Windows95
<epony>
(probably only BeOS was less useful at that time)
<ThinkT510>
maybe start a blog?
carbonfiber has quit [Quit: Connection closed for inactivity]
<epony>
maybe not ;-)
<epony>
remember amateur radio, there are some principles about radio comms that apply on any discussion form
<epony>
when you're not talking some else is..
<epony>
just join / enter at any point
<epony>
also people can't talk too much, so it goes out a while / quickly typically after some data session has completed ;-) so there you go, you start your whatever talk you like, and I'll keep reading / listening
<ThinkT510>
either everyone here is ignoring you or nobody wants to join in. seems a waste of all your typing in a medium such as irc
<epony>
it's like air..
<epony>
if you want to make contact you just do, if you dan't.. interrupt or proceed as you see it
xenos1984 has quit [Read error: Connection reset by peer]
<ThinkT510>
as long as you don't mind that nobody might be paying attention to you then great
<epony>
that's how it goes
* epony
makes a mental not to congratulate non-Europeans on all the European festive dates to rub in the CISC architectures good and deep (just joking, it's because RISC was expensive and under embargo and really useless for applied computing in the 1980-2020 period)
<epony>
:note:
<epony>
note, I did at the time like CP/M ;-)
<epony>
but on the bigger outline of system software, it just fell short and was not portable and compatible with either the 6502 and 8086 series of processors as it was gotten here
xenos1984 has joined #osdev
<epony>
the main problem was lack of applications and not enough resources to get that up.. and historically it waned in adoption too, despite the active suppression attempts by Microsoft, it did have a good chance and a shot with the PCs
<epony>
(resources locally to make up for the application shortage)
<epony>
it was a main problem with all systems from the mini to the micro-computers, and it's recurring, we even see it nowadays on the mobiles and tablets
<epony>
the result of.. complex development methodology (non-hosted / emulated / cross-compiled on larger machines, and lower level programming languages needed to create applciations, Java / *droid SDK etc)
<epony>
if there is one thing to learn from the 8bit micro-computer epoch, it's internal storage and native compilation in a high level language.. and documentation
<epony>
all points failed, by vendor-control-inhouse system development tight seal and under strict concession on app development tooling
<epony>
of course, people would mention, but there are SDK boards and.. hobby kit SBC systems and that's just not enough, because the systems are too small and you cross-compile for them (and the majority of devices in the hands of people are mobiles and tablets and ultrabooks and they are all locked and incompatible / non-portable)
<epony>
that's not the premises of a flourishing application and utility eco-system, more like a reseller-affiliate product branding segmentation-mall-stalls / vending automats
<epony>
in that regard, the sub-computer (embedded) handheld and portable operating systems are a huge failure, despite their multi-billion HW+FW+SW+SVC sales unit-assemblies, the applications are missing or faulty or merely useless and the devices are, reduced to a couple of interesting programs-as-a-platform and.. fail to impress
<epony>
that's a serious difference between the mini and micro computers
<epony>
the mini's did not have enough engineers / developers, the micro's did not have enough compute functionality and developer tools, the pc's had that and the internet extra boos, the handhelds embeds.. are like a failed reboot (who was requesting a reset vector, there it is)
<epony>
"boost"
<epony>
now, let's think about the future.. well, if the early micro's were indecently small and inadequate compared to the mini's who had concurrency in the rates of 20-50-100 users..
<epony>
the PCs got that.. in the 1980-2000 period with.. better software, and a couple of orders of magnitude hardware
<epony>
that same hardware is on embedded handhelds.. and they peforform with 0.1 user ratio (you need 10 devices to get work done in the scope of a 1 previous form factor mchine, that's the mini to micro comparison)
<epony>
yet.. the machines are already decent enough to run that workload.. why is that their software is so fucked up??? ;-)
<epony>
think about it, and then let me know which "elegeance" and "superiority" feature is holding this back..
wootehfoot has joined #osdev
<epony>
alright, no time to wait for victorious replies.. it's the virtual runtime which is inefficient / incompatible with the previous generation of applications
<epony>
that is your real target, the virtual machine of the runtime that you're compiling for, not the actual processor of the small computer on device, it's a virtual system, on a battery ;-)
<epony>
and the tools used are.. legacy
<epony>
that right there is your "RISC workstation obsoletion" moment
<epony>
you paid for it, enjoy it while it lasts, the buble has burst, and the fallout would be small, but solid felt in overpriiced overinflated overevaluated fake-market-bond-share capital-investment markets.. someone rememers the investment bubble of Sunmicro?
<epony>
so much of a platform elegance, so crudely wasted on a 2 year product cycle run with inability to emulate applications of the previous generation
<epony>
we call that demented fail-stale-mate, chaps.
<epony>
it would have been great if the RISC machines in the handhelds could emulate the CISC applications from the micro's.. but they can't
<epony>
cause 1) they are from the past of CPU designs and are inefficient 2) they are not in the future of CPU designs because they can't port apps and fail on thermal ratings on general business ready compute 3) there is NO TIME, we're 10 years on machine cycle delay and 15 years after machine miniaturisation and reintroduction, that's a complete 25 year summer sault face-fall 4) there are no more things to lose
<epony>
the solutions are obvious
<epony>
a) kill java b) kill application level virtualisation c) native compile d) throughput e) fix thermal design f) use a better effiiency arch g) get apps for free
* epony
raises the mental temperature by 3 degrees, hm how is that, you like it? that's jave to you
<epony>
points a) and b) is why you have platform failure
<epony>
(it's going to resolve itself after the patents and copyrights expire, which would be a half-term for such a weak and useless platform)
<epony>
the rewards have been reaped, the market is saturated, the applications are not there, the CP/M lessons are not learned, the mobiles are a flop like 3D TVs and VR goggles, and there is only one logical choice, fix the faults (which were on purpose to get you to pay up more)
* raggi
facepalms
[itchyjunk] has quit [Remote host closed the connection]
GeDaMo has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
<ddevault>
hrm, cpuid in qemu (without KVM) reports the host CPU, not TCGTCGTCGTCG
<ddevault>
anyone else seen this?
<ddevault>
with -cpu qemu64,fsgsbase
<ddevault>
looks like it was removed, but you can cpuid 0x40000000 instead to get it
<ddevault>
if only my wiki account was working I could update the page, hint hint
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
epony has quit [Ping timeout: 252 seconds]
<klange>
ddevault: If you have a forum account that is stuck in email validation, no one can fix that.
<ddevault>
whelp
<klange>
osdev.org has neither SPF entries nor DKIM signing, so if you're being picky about either of those, I suggest either using a more mundane mail service or adding some whitelists and trying again. I don't know if this version of phpBB offers you some option to resend yourself, or if you'll need to try making another account...
<ddevault>
my mail server should let it through
<klange>
Outside of the lack of modern validation, in my experience the forum has been pretty consistent in sending - phpBB sends emails for private messages, so I regularly get fresh signals that it's still working. And I don't think it's on any common blocklists, but my spamassassin has been over-quota for all of them for months now, so who knows...
<ddevault>
I whitelisted *@osdev.org and *@*.osdev.org
<ddevault>
still, no luck
<ddevault>
would be helpful if someone with appropriate access could go fiddle the database
<klange>
It sure would :(
<klange>
To my knowledge, only one person actually has that sort of access, and they are 1) not here, and 2) not responsive by any means they have provided in the past to contact them.
<ddevault>
who is it? I can give it a shot
<kazinsal>
godspeed
<klange>
The dirty little secret of osdev.org is that the only people around with any access have at most basic phpBB and mediawiki moderator rights and it's a miracle the hosting and domains remain in service.
<kazinsal>
chase has been checked out of osdev for well over a decade
<klange>
chase actually signed into the forum in February of this year, so he does seem to check in every so often of his own accord, but never when summoned.
<kazinsal>
imo it's fine to not give a shit about a greater group community but when hundreds or more are relying on you giving a shit, you need to pass on your buttons before you fuck off
<klange>
One day someone will drop some vulns for the old versions of phpBB or mediawiki we're running and we'll just take things by force ;)
<ddevault>
anyone know how to reach chase? any accounts on github or gitlab or such?
<kazinsal>
I know I've dropped out and fucked off from places before but at least I had the decency to hand things off
<pbx>
clever: yep :)
<ddevault>
yeah lol tbh I was just browing phpbb CVEs
<pbx>
please don't :(
<klange>
ddevault: I will PM you an email address, but no promises he even reads it.
<ddevault>
ack
klange has quit [Remote host closed the connection]
klange has joined #osdev
klange has quit [Client Quit]
<pbx>
nice :) pinged my OS at 0.01 interval all night and more lockups or freezes :) finally got that locking problem dealt with
klange has joined #osdev
<klange>
okay so iterm2's bracketed paste is apparently not great for this irssi build... good to know...
<ddevault>
found his email address(es) anyway
<ddevault>
thanks though
<klange>
presuming the two are the obvious-but-ironic-in-this-case one and his gmail with his actual name, and in either case I have sent several emails over the years to those but never actually received a reply
<ddevault>
I also found one @oracle.com which appears to have been used as recently as 2021
<pbx>
(ignore the drops, this was ran across multiple reboots and code changes) 1826560 packets transmitted, 1790428 received, +34040 errors, 1.97814% packet loss, time 38681477ms
dutch has joined #osdev
<pbx>
time to start implementing socket() and friends
<ddevault>
email sent, fingers crossed
<klange>
I think I have a phone number for him, as well, never tried that one... would be hilarious to eat the long distance bill and call him from my non-voip line...
<pbx>
klange: you still working on toaruos?
elderK has joined #osdev
<klange>
am I dead?
SpikeHeron has quit [Quit: WeeChat 3.6]
<pbx>
lol, just wondering as i've kinda checked out of this stuff for several years. used to be active on here and forms 2013-2017 so was just curios
<pbx>
s/forms/forums/
<klange>
(I am presumably not dead, on account of the IRCing, thus I must still be working on my OS, as surely death is the only thing that will separate me from it...)
<klange>
I haven't done much directly recently, mostly working on some offshoot projects that are more generally useful.
<pbx>
ah, did see your text editor. pretty cool.
<klange>
If I weren't 500km from home and didn't need to be up at 4am for the event that has me 500km from home, I would be working on the editor right now...
<mjg>
:)
<klange>
I built an entire Python clone specifically because I wanted a language to use to extend the editor, and then went and only really half-assed integrating it with the editor.
<klange>
Last week at work I had a dumb little QoL issue, I wanted to bind a key in command mode to insert the dirname of the open file... only to discover I hadn't actually made it possible to bind a key to such a function
<mjg>
wait, you are using your custom editor for your dayjob?
<klange>
I have been using my editor for my dayjob long enough I have never used any other editor for this particular dayjob.
<mjg>
solid
<mjg>
9/10
<mjg>
i hope it is not emacs-inspired
<klange>
It's a knock-off vim.
<mjg>
10/10
<ddevault>
I'm a bit divided on whether or not I should port vi or write my own editor
<ddevault>
or just start with ed and call it a day
<klange>
Circa 2018 I put in a lot of work on it, then I started dogfooding it while writing it, then vim started to feel weird...
<mjg>
if you are not passionate about the subject just get vim
<kazinsal>
port kuroko and bim
<klange>
^ Kuroko being the aforementioned Python clone, and bim being the editor.
<mjg>
an editor is something i would never want to write myself, for example
<kazinsal>
the average unix enjoyer will not grok the difference between bim and a nicely customized baseline vim
<mjg>
is kuroko japanese for python?
<mjg>
or something else to that extent
<klange>
No, it's a character from the series the OS is named for.
<ddevault>
well, my OS is not very POSIX and a POSIX compatibility layer is a ways off
<mjg>
ddevault: +1
<ddevault>
most likely outcome is to write something resembling ed then port vim as a means to forward the POSIX layer development
<mjg>
not posix per se, but realiteis of messing with unix
<ddevault>
*cough* ioctl
<mjg>
ddevault: you know the worst thing about job control?
<mjg>
ddevault: it jus does not work
<ddevault>
I would find it hard to identify the "worst" thing about job control
<mjg>
ddevault: as in everyone has it implemented in a super buggy way and nobody is using it
<mjg>
it's there to be exploited basically
<mjg>
also ptrace
<ddevault>
also the fundamental design of unix leaves a lot to be desired, even if POSIX is set aside
<klange>
ptrace isn't in posix
<mjg>
klange: no, but it is the unix breakage
<ddevault>
still upset that acid didn't catch on
<mjg>
see realities of messing with unix
<mjg>
my fav bit is repareting the tracee
<mjg>
which everyone but solaris is doing
<mjg>
and then you have funny games to play for example with waitpid
gog has joined #osdev
<gog>
hi
<pbx>
meh, BSD sockets are in every OS nowadays
<pbx>
and ioctl is hardly a purely unix thing
<ddevault>
being in every OS does not make something good
<pbx>
DeviceIoControl(), anyone?
<ddevault>
and a bad feature does not have to be unique to unix to be bad
<ddevault>
s/feature/design/
<pbx>
both true, but to use those two near universal features to detract from unix is a bit uncreative
<ddevault>
they originated in Unix
<ddevault>
¯\_(ツ)_/¯
<ddevault>
and in any case I don't consider proprietary operating systems valid
<ddevault>
so whatever Windows has is not really a concern of mine
vdamewood has joined #osdev
<mrvn>
kazinsal: try using vi, an actual vi from some commercial unix.
<mrvn>
No pressing ESC too often or you get into some wiered mode. No :x to save and exit, bad things will happen instead.
<mrvn>
No cursor keys, no backspace. They just insert the respective ESC sequences. Now that is fun.
<gog>
kinda like elvis
<zid>
elvis is my favourite text editor slash musician
<zid>
until someone makes a text editor called Doors anyway
dude12312414 has joined #osdev
<j`ey>
zid: you're a Doors fan?
<zid>
A bit, I just couldn't think of many other artists
<zid>
It was like that "NAME A WOMAN FOR A DOLLAR" video
<j`ey>
o
<gog>
gog
<zid>
zid
<Ermine>
gog: may I pet you?
<gog>
yes
<zid>
I want a pet stoat :(
* Ermine
pets gog
<gog>
were you watching the youtube guy that rescues stoats
<gog>
they're p cute
<zid>
no, ermine is another woord for stoat
<gog>
o
<zid>
The stoat has a circumboreal range throughout North America, Europe, and Asia. The stoat in Europe is found as far south as 41ºN in Portugal, and inhabits most islands with the exception of Iceland
<zid>
I have it, heat has it if he goes north enough, GOG DOES NOT HAS IT
<gog>
the only land mammal indigenous to iceland is the arctic fox
<zid>
is it actually idigenous
<gog>
yes
<zid>
or just introduced so long ago nobody remembers
<gog>
remains have been found in geological strata afaik
<gog>
hard to say how they got here
<gog>
sometimes polar bears get here adrift on ice floes
<gog>
i think the logic is that they're dangerous if they make it to shore here because they're undoubtedly starving and may not think twice about huting a human
<zid>
tranq them, give them a rabbit or two, push them back out to sea
<gog>
very unlikely on this side of the island though, more likely in the westfjords and the north coast
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #osdev
dude12312414 has quit [Remote host closed the connection]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #osdev
heat has joined #osdev
<heat>
>you're a Doors fan?
<zid>
I knew you'd like that heat
<zid>
heat is the #1 doors groupie
<zid>
afterall
dude12312414 has joined #osdev
<heat>
ewontfix is a big musl-biased
<heat>
being written by rich himself afterall
<zid>
is a what
<heat>
bit*
elderK has quit [Quit: Connection closed for inactivity]
<bslsk05>
ewontfix.com: EWONTFIX - Multi-threaded setxid on Linux
* zid
backs away slowly
<heat>
i love this btw
<zid>
oh it's a blog, not a return code
<heat>
in linux a setgid or setuid, etc need to use signals to get every single thread to call that syscall
<heat>
because threads aren't real
isaacwoods has joined #osdev
<zid>
You'd think they'd just add a setgid_group syscall or something
<zid>
and made the kernel handle it
<heat>
that would make too much sense
<zid>
good point
<heat>
they have exit_group(2) for exit()
<heat>
but setgid_group really is taking it too far
<zid>
clearly
<zid>
I’d Rather Have a Cat than a Harem! Reincarnated into the World of an Otome Game as a Cat-loving Villainess
<zid>
k found what I am reading today
rurtty has joined #osdev
epony has joined #osdev
dude12312414 has quit [Ping timeout: 258 seconds]
ss4 has joined #osdev
ss4 has quit [Remote host closed the connection]
wootehfoot has quit [Ping timeout: 265 seconds]
[itchyjunk] has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
wootehfoot has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
carbonfiber has joined #osdev
<dzwdz>
how bad of an idea is it to assume that programs will always use my syscall wrappers instead of syscalling directly
<dzwdz>
i'm considering moving some output sanitization code from the kernel into my libc
<GeDaMo>
Isn't that essentially what Windows does?
Raito_Bezarius has quit [Quit: free()]
Raito_Bezarius has joined #osdev
<Ermine>
dzwdz: since you want to move sanitization code, those who use syscalls directly will be able to abuse your system
<dzwdz>
output sanitization, not input
<Ermine>
Ah, okay.
<dzwdz>
if you syscall directly you'll just risk making your own program vulnerable
Raito_Bezarius has quit [Max SendQ exceeded]
<mjg>
dzwdz: why though
<mjg>
sounds like a layering violation
Raito_Bezarius has joined #osdev
<dzwdz>
actually yeah you're right
<dzwdz>
i'll keep it in the kernel
<heat>
it's possible
<heat>
zircon can do that
<heat>
I don't think they do though
<heat>
zircon blows up your program with highly explosive TNT if you try to syscall outside the vdso
<dzwdz>
for context, "it" being ensuring that paths passed to filesystem implementations in userland don't contain .. and NUL
<heat>
ah wait, I remember why you can't
<heat>
you can jump to "just before syscall"
Raito_Bezarius has quit [Max SendQ exceeded]
<heat>
anyway using a vdso or so is a good idea
<heat>
for compatibility purposes, you'll never need to carry old syscalls if your syscall boundary is the libc
<heat>
which I think it's what the freebsd people do
<dzwdz>
does that mean freebsd doesn't have statically linking binaries?
<dzwdz>
or am i misunderstanding this
<heat>
it probably has but in a "if it breaks it breaks" way
<heat>
i know that freebsd is one of the golang platforms that always links with the libc instead of shitting out syscalls directly
<heat>
but i may also be talking out my ass here so cc mjg
<mjg>
static binaries are supposed to keep being operational, modulo static made against the dev branch, in which case all bets are off re binary compat
<dzwdz>
so they do need to keep supporting old syscalls?
<mjg>
yes
<dzwdz>
aight
<mjg>
there is a slew of COMPAT_FREESBSD${RELEASE} opts
FreeFull has joined #osdev
<heat>
BAD MOVE HOMIE
<mjg>
which keep syscalls, ioctls and other crap needed by binaries compiled against a sepcific branch
<mjg>
afair work was done for lulz to make binaries compiled against the oldest release ever also work
<heat>
what's the point of the libc as the compatibility layer then?
<mjg>
for one you still have one obj, so most of the userspace text remains shared
<dzwdz>
i assume that libc could just emulate the old syscals for dynamic binaries, so if you're only running dynamically linked stuff you wouldn't need the compat options in the kernel
<zid>
wow heat, don't make me call the pólícíú
<dzwdz>
i don't know how common static libraries are in bsd land
<mjg>
dzwdz: there are in-kernel semantic changes
<mjg>
dzwdz: well all freebsd installs come with a set of static binaries in /rescue
<heat>
zid, call the who
<mjg>
albeit you are only supposed to use them for your *current* release
<mjg>
lemme grep real quick for an example
<heat>
ohhh new mount api btw
<heat>
i missed this completely
<dzwdz>
oh hey, everything in /rescue is the same binary, busybox-style
<dzwdz>
that's nice
<heat>
that sounds like a nightmare
<dzwdz>
a good one
<mjg>
crunchgen
<heat>
you can't easily integrate utils
<mjg>
i just rememberd the compiler used to be statically linked until very recently
<heat>
except with that utility yeah
<dzwdz>
wdym "integrate"?
<mjg>
slap different binaries into one file
<heat>
yeah
<heat>
or different codebases really
<heat>
int a; in mke2fs.c int a; in tr.c does the fuck up
<heat>
int main() in a.c, int main() in b.c also does the fuck up
<heat>
etc
* mjg
burps
<mjg>
i wonder though how gettimeofday and other vdso uesrs are handled in static binaries
<bslsk05>
www.youtube.com: РЕПЕР СЯВА - ОТДЫХАЕМ ХОРОШО - YouTube
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #osdev
moberg1 has joined #osdev
moberg has quit [Ping timeout: 246 seconds]
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #osdev
<dzwdz>
any resources about alternatives to unix signals? i know about plan9 notes but i can't find much else
<heat>
alternatives?
<heat>
what about a "no"
<heat>
what do you need signal-like behavior for?
<heat>
and if so, why not signals?
<dzwdz>
because i haven't explored the alternatives yet
<dzwdz>
cleanly killing processes, mostly
<heat>
you can just not have any signal behavior
<heat>
message loop with messages?
<heat>
that's how the windoze would do it
<dzwdz>
wouldn't that break a lot of software
<heat>
if you're exploring alternatives you're not thinking about compatibility are you?
<dzwdz>
if i went with plan9-style notes i could still probably emulate unix-style signals
<heat>
but why?
<heat>
signals were a bad idea? yes
<heat>
so lets emulate it?
<dzwdz>
basically, yeah
<heat>
the idea is still there, but worse because it's emulated
<dzwdz>
because there's software out there that already use them
<heat>
if you want compatibility, implement signals
<heat>
natively
<heat>
if you don't care about it, you're free to explore kooky solutions
<heat>
it's like fork, if you emulate it, you get a slower fork and all the downsides of having to care about fork
<heat>
if you natively implement, you get the downsides of fork but at least it fits well with the system and can be performant
gog has quit [Ping timeout: 260 seconds]
<dzwdz>
are efficient signals really that important, though
<heat>
yeah
<heat>
SIGCHLD, SIGSEGV, SIGIO, and all the rt signals can be really performance important
<dzwdz>
ah, right
<heat>
SIGCHLD less so unless you're dispatching a shit ton of processes
<dzwdz>
still, > you're free to explore kooky solutions
<dzwdz>
that's why i asked for resources :p
wootehfoot has quit [Read error: Connection reset by peer]
<heat>
but if you're worried about posix, why?
<heat>
something I've realised over time is that adding crazy interfaces with "better semantics" is useless if you're posix/unix
<heat>
unless you're willing to force it to people
gog has joined #osdev
<heat>
or if it's /that much better/
<dzwdz>
i'm not posix anyways, i'm doing some core things differently
<dzwdz>
but being kinda posix-y makes porting software easier
<mrvn>
heat: SIGSEV is usually the death of the program. How is that performance important?
<mrvn>
SIGIO also seem to be one of those things you aren't going to use (much) on bsd/linux. When it matters there are better ways and when it doesn't signals are to hart to use.
<mrvn>
dzwdz: have you looked at signalfd/eventfd?
<dzwdz>
nope
<mrvn>
dzwdz: signals are so bad linux added a way to poll them via file descriptors instead.
<mrvn>
When I looked into signals first my idea was to have the kernel start up threads for signals instead of interrupting an existing thread.
<mrvn>
Avoid all those restrictions of what you may or may not do inside a signal handler.
<dh`>
yeah I tried that once
<dh`>
works ok with ordinary code, not quite good enough for compliance
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #osdev
lkurusa has joined #osdev
lkurusa has quit [Ping timeout: 260 seconds]
<mrvn>
And pretty much useless for SIGALARM
<mrvn>
as in with syscalls that abort on signals and setting a timer as timeout.
wootehfoot has joined #osdev
<dh`>
can't remember what I did about that
<mrvn>
I just don't have any syscalls that block
<dh`>
you gotta have one for idle waiting, no? but it can be magic
<raggi>
You could have a yield that doesn't preserve any stack - that's terminal. Most language runtimes would hate it, but it could be better
<raggi>
But then it's not blocking, it's terminal instead
<dh`>
I guess, but only if a lot more things than signals spontaneously spawn new threads
<dh`>
hard to support C code in such an environment, too
<raggi>
Sorta, you'd just have to wrap it in some runtime, but that could be unique to your libc rather than baked in to kernel ABI
<dh`>
you'd need to play significant games with stacks
<raggi>
Most people do that anyway
<dh`>
but maybe it's workable, you allocate a permanent stack for each C-level thread and latch onto it with the transient threads every time it becomes runnable
<raggi>
Either for signals or for async runtimes, etc
<dh`>
sort of an interesting structural proposition
<dh`>
well, on reflection I expect it ends up looking like blocking syscalls where you save a few extra things before entry
<dh`>
that is, say you want to read something; instead of calling read() you save your callee-save registers, then call start_read_and_exit() and pass some kind of completion record that tells the system to start a "new" thread at the next instruction and to pass the current stack pointer as its argument
<dh`>
so you continue when the read is done, with perhaps a different internal thread id but everything else is as usual
<raggi>
right, though it might also encourage other memory arrangements than so much stack storage
<dh`>
not unless you rewrite all of userland and apps to use a different model
<raggi>
sure, that doesn't concern me in the wonderful imaginary world of perfection
<dh`>
hmm
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
maxdev has joined #osdev
<maxdev>
anyone know how the performance of EFI GOP is compared to VESA framebuffers? is it faster?
<clever>
maxdev: i would assume its the same, different api to configure the hw, but the same hw framebuffer in the end
<maxdev>
clever: i guess so
<maxdev>
hey klange, I can't click in the latest ToaruOS iso :( hw cursor is really nice but no clicky.. is there a trick?
<maxdev>
... in VirtualBox
<geist>
hmm, does the GOP get you a pointer to the framebuffer so you can do what you want?
<geist>
or is it a series of draw calls?
<geist>
if it had some blit routines you could hypothetically use some of the accelleration of the hardware if available
nyah has joined #osdev
<maxdev>
afaik you just get a framebuffer.. acceleration would be cool
<geist>
yah if it gave you accelleration then i think the perf could hypothetically be better. otherwise if it just gets you a pointer to the framebuffer, it shouldn't really be any different from a VESA framebuffer
<clever>
there it is, you have 4 fields in a struct, query-mode, set-mode, blt, and mode
<geist>
yah so the blt might be useful. you could, for exmaple, load up a font offscreen and then blit characters in. and hypothetically that's faster
<XgF>
the blit function goes away when you call ExitBootServices though
<clever>
> Blt a rectangle of pixels on the graphics screen. Blt stands for BLock Transfer.
<heat>
mrvn, SIGSEGV can be handled and some programs take advantage of that
<heat>
the funny bit is that (according to the osdev wiki) the Blt calls were slower
<clever>
geist: but if you just want text, there is also a console api, which does text for you
<geist>
yah that's why i say hypothetically. it's also possible it's some shitty byte by byte copy that's worse than what you could do
<clever>
and console could also reroute to uart silently
<heat>
that has nothing to do with the GOP
<clever>
yeah
<clever>
but if your rendering fonts onto GOP, you could just use the console api and let the firmware render for you
<clever>
it could map to the old vesa text framebuffer, and do it all in hw
<heat>
but consoles are way less trivial than "rendering fonts"
<heat>
and the uefi font is ugly af, and that wouldn't work after boot services, yadda yadda
<clever>
depends on what your needs are in the end
<clever>
yeah
<heat>
s/uefi/tianocore/
<geist>
yeah
<heat>
no. that's just objective, writing to a console is not just "Drawing text"
<heat>
it envolves doing a full VT100 emulation at the very least because
<heat>
l e g a c y
<heat>
for OVMF it also envolves mirroring everything to the UART
<heat>
and some real platforms too
<CompanionCube>
vt100 emulation in firmware would be weird but unlikely
<heat>
it's not unlikely
<heat>
it's there
<CompanionCube>
oh, huh
<clever>
CompanionCube: i dont see the uefi specs saying its needed
<heat>
you are underestimating the tianocore
<clever>
ah there it is
<clever>
page 2180 mentions vt100+
<geist>
yeah that's i guess fundamentally it. does it handle vt100 codes or not. if not i guess maybe it would just silently ignore the codes and print nothing
<clever>
ah, this region is how vt100 input codes map to efi codes
<clever>
so f1 is just 0xb, not escale 1
<clever>
escape*
<clever>
but there is also a sub-type elsewhere, that says something can be vt100 or vt100+
<heat>
CompanionCube, what else do you think is not there so I can break your heart
<CompanionCube>
nothing in particular comes to mind
<heat>
lmao
<clever>
heat: i would expect ntfs and ext4 to not be there!
<clever>
come on, break my expectations! :D
<CompanionCube>
i actually would expect an ntfs driver
<CompanionCube>
because microsoft
<heat>
ext4 is there in a lot of platforms already
<heat>
ntfs is NOT
<heat>
OpenCore has an ntfs driver, i know some of those guys
<heat>
(note: "a lot" is defined very loosely because I generally can't have much of an idea)
<heat>
microsoft is definitely not the worse in fw bloat
<heat>
worst even
<heat>
they are generally very competent people
<CompanionCube>
any features you think are surprising/unusual such as random support for non-PE executable formats?
<heat>
oh sure, you have terse executables, TE for a whole part of the boot process (PEI)
<maxdev>
i wonder if it's even possible to draw a 1 pixel rectangle in cairo lol
<heat>
tianocore indirectly supports Mach-O and ELF so it can objcopy the binaries into PE/TE (It does not use a cross compiler!)
<heat>
most firmware out there has openssl embedded
<heat>
(as part of edk2)
<heat>
also a full network stack, and wifi
<clever>
wifi i'm surprised about
<CompanionCube>
yeah i knew about the network stack already
<CompanionCube>
the utility of objcopy seems limited given the difference between sysv and ms abis, though?
<heat>
no
<heat>
only EFIAPI functions are interoperable
<CompanionCube>
isn't that a different library
<heat>
library?
<heat>
this is part of the UEFI spec
<clever>
i think most efi examples i see, include an asm wrapper, to convert the abi when calling things
<heat>
every callback, function is defined with EFIAPI attached
<heat>
cuz they're wrong clever
<CompanionCube>
ah, i associated it with gnu-efi
<clever>
and they arent using an attribute tag on the functions? to tell gcc to use the right abi?
<heat>
EFIAPI is defined in GNU/Clang as __attribute__((ms_abi))
<clever>
ahhh
<heat>
naturally empty in msvc
<clever>
can that also be slapped on function pointers?
<heat>
yup, absolutely
wootehfoot has quit [Read error: Connection reset by peer]
<clever>
perfect
<heat>
and if you assign a normal funcptr to an EFIAPI funcptr, you get a warning
<clever>
so all of the structs from efi, and main() should have that tag, along with my callbacks i pass to efi
<clever>
and internal functions can just use the default abi, and gcc uses the right one everywhere?
<heat>
yes
<heat>
you'll notice in my Ext4Dxe that only functions I need for interop are EFIAPI tagged
<heat>
the rest use whatever the compiler uses by default
<heat>
anyway, SMM is also fully modular
<heat>
and has a protocol to call it with particular stuff
<heat>
there's also a libc implementation, a cpython port
<heat>
and this stuff I'm listing is *just* upstream stuff
FreeFull has quit []
<heat>
the real warcrimes happen in the blobs and bios vendor code
<clever>
about the only big complaint i can really say about how tianocore is designed, is how it seems to load/execute every PE in the rom
<clever>
i would want some kind of index, that defines what protocols each PE handles, or a header that can be parsed without doing relocation/execution
<heat>
hehehehehehehe
<clever>
like depmod
<heat>
we talked about that a few days ago
<clever>
yeah
<clever>
thats the only big complaint that comes to mind
<heat>
there's also a lot of bad code
<heat>
i would trust lk 100000000x more than a random improvised edk2 platform build
<clever>
the static vs dynamic thing is also a bit of a waste
<clever>
heat: ah, and what you said about EFIAPI also means implementing efi with LK even simpler
<heat>
everything is also very single threaded btw
<clever>
all i really have to do then is implement pe loading/relocation, and EFIAPI every func in the api
<heat>
you can't safely call into EFI code in an AP
<heat>
yeah
<heat>
also, for some reason, no interruptz
<heat>
except the timer
<heat>
#consistency
<clever>
so if i was to load an efi binary with LK, and call its main(), i would expect that binary to behave in a single-threaded manner, and only call one api at a time?
<clever>
but i could context switch without it noticing, and probably not break things?
<heat>
yes you can
<clever>
a much more impossible task, would be to have full LK in an efi binary, but remain in boot services mode
<heat>
for the second thing, I don't know
<heat>
ah no that's impossible
<clever>
interrupts and context switching may clash too much with the intended usage
<clever>
yeah
<heat>
at the very least you'll be breaking the efi spec
<clever>
i would have to ExitBootServices first
<clever>
but i like how you can `exit` in grub, and it returns back to the firmware
<clever>
and i kinda want that :P
<heat>
the osdev wiki is full of shitty "you can tots stay in boot services in your kernel queeeennnnnnnn!!!!!" advice
<heat>
ah you can still do it
<heat>
just reboot
<heat>
ez
<clever>
but then the bios wont consider that boot entry as failed, and try another
<heat>
(this is not a joke)
<heat>
set the next boot entry
<clever>
even on legacy bios, you can do that
<clever>
ah, that could work
<heat>
that's how "boot to X entry" works
<clever>
but then you cant do other fun things
<clever>
somebody packaged all of grub's FS drivers into an efi app
<clever>
which will return control back to the firmware, but not unload
<clever>
and registers all of the fs handlers
<clever>
if you reboot to entry X, you cant do that
<heat>
wdym "control back to the firmware, but not unload"
<clever>
i dont know the exact details, but you can execute that .efi binary, it wont load a kernel, and the efi firmware remains running
<clever>
but has magically gained support for more FS's
<heat>
yeah it's a uefi driver
<heat>
that's how they work
<heat>
execute -> it registers itself -> exit
<clever>
yep
<clever>
but is it basically the same api as an efi application?
<heat>
then "connect" or "reconnect" in the efi shell and everything is hooked up
<heat>
no, not quite
<heat>
but similarish
<clever>
and using LK for that, would be difficult to impossible
<heat>
i think most of the changes are in tianocore internal APIs
<heat>
UEFI should be the same
<maxdev>
reading the IOAPIC id giving me a GPF in HyperV while it works in VBox hmm..
<heat>
that's an MSR right?
<maxdev>
no, memory-mapped
<maxdev>
acpi tables tell me it's there and should be fine but reading it gpfs, in vbox and qemu its fine though
<heat>
what address are you getting?
<maxdev>
0xFEC00000, same as in the others
<heat>
huh
<heat>
and you're addressing that directly?
<heat>
(with that properly mapped)
<heat>
i would also check what instruction it's using to poke it
xenos1984 has quit [Read error: Connection reset by peer]
<maxdev>
i'll check that, yes it's mapped and i just try to write to the regsel and then read from the regwin
<heat>
is it mapped to the right place?
<heat>
i know these seem like stupid questions
<heat>
but the stupid checklist is important :P
<maxdev>
i'm pretty sure
<heat>
c h e c k
<maxdev>
:))
<heat>
is this user code or kernel code?
<heat>
i vaguely remember you were doing a ukernel
<maxdev>
kernel code, its on the bsp before anything else is set up
<maxdev>
mostly µ :P
Brnocrist has quit [Ping timeout: 268 seconds]
Brnocrist has joined #osdev
<epony>
vague memories match vague words and vague thoughts produce vague conclusions
<maxdev>
generated code looks as expected and the error occurs right at the setting of the regsel hmm
xenos1984 has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
<dh`>
raggi: on reflection I think that model (where user threads never block, only exit) doesn't work
<dh`>
unless you don't have virtual memory, user threads need to block on paging
<dh`>
and you still need to suspend them on timer interrupts
<dh`>
(unless you have a completely cooperative realtime system or something)
<raggi>
Suspend yes, but that is mostly invisible
<dh`>
which means you need the ability to suspend, which means you don't really save anything by not having a wait system call
<raggi>
I don't see the relationship you're drawing between the two
<dh`>
what's the difference between blocking for paging and blocking for read()? damn little
<dh`>
you can rig that out so you don't block _in_ the kernel for read, but for paging you still at best need to wait in the kernel in the top of the page fault handler
<dh`>
consequently, having a call that waits in the top of the syscall handler isn't really any different
<raggi>
who initiates a context switch is quite a significant difference, especially if you can make assumptions which you can when it is only ever a single actor causing it
<dh`>
I don't follow
<dh`>
in both cases it's the user program
<raggi>
no, in both cases it's an exception
heat has quit [Read error: Connection reset by peer]
<dh`>
so is the wait syscall
heat has joined #osdev
<raggi>
Not a termination call though, a termination call doesn't need to save any registers
<dh`>
right, my point is that structurally the wait syscall is no different from waiting for a page fault, and consequently there's nothing to be gained by not having it
<raggi>
That depends on whether or not you have bounded limits on your fault handler. If you never allow long pauses, and you require limited resources to execute fault handling from free pages, then again, you could have a cheaper implementation than a regular synchronous syscall context switch or a preemption event
<heat>
how would that model ever work?
<heat>
that assumes you always have useful work to do
<heat>
instead of just blocking and saving some CPU
<heat>
(or passing it off to another task that could make progress on what you're trying to do)
<heat>
right?
<raggi>
the rest of the model is essentially having configured entry points for event handlers without necessarily fixed / previously saved stacks they're executed on
<raggi>
(likely you'd do something like pool some regions for that instead, in practice)
<raggi>
but the point would be not having "idle stacks" around, and never having any blocking syscalls
<heat>
hrmmmmmmmm
<heat>
so co_yield() instead of yield()
<heat>
?
<raggi>
exit instead of yield, the stack finishes, registers aren't saved, they're dropped
<heat>
would you make progress though
<raggi>
future events are handled by code in a new context
<heat>
like "main(){ read(fd, buf, 20); printf("%s\n", buf); }"
<heat>
you block on the read
<raggi>
C is not a good fit for this model
<heat>
is this just not how you could structure something like this?
<raggi>
It's a simple/extreme form of what some intrusive kernels do, which fwiw, some don't offer virtual memory
<heat>
would you basically form something like promise chains?
<heat>
auto status = read(fd).then([](void *buf, ssize_t len) { printf("%s\n", buf); return 0;}