<netbsduser>
then Apple hired him where he became Director of UNIX Technologies or some similar such title
<netbsduser>
he made a brief return to the FreeBSD community after leaving Apple, implementing Mach ports on FreeBSD and porting the likes of LaunchD as part of the NeXTBSD project
<bslsk05>
wiki.gentoo.org: Project:Prefix - Gentoo wiki
<mcrod`>
reality is though, there have been points where I pacman -Syu'd and then death ensued
<mcrod`>
that's... almost never happened on LTS
<geist>
actually the biggest problem i've had with -march=native is i end up trying to move the disk or the VM to a different machine and it wont boot
<mcrod`>
and honestly, I really don't see much benefit in bleeding edge
<mcrod`>
I don't see a material impact ever in performance or security 98% of the time
<mcrod`>
but maybe I'm just not running the right shit?
<mcrod`>
who knows
<geist>
agreed. honestly most of the advantage i see with modern day gentoo or arch is you can build a very small boot image to run on a low end machine
<geist>
but then the problem is (at least with gentoo) the low end machine doesn't have the oomph to compile itself
<zid>
I bought a cpu with 3dnow! and I wanna use it damnit
<geist>
i have a gentoo install on an old pentium 3, and it's kinda fun to fire it up every once in a while and rebuild
<geist>
but... it takes days to rebuild
<geist>
but at the end of it it has a pretty small system, just a handful of processes, like it was meant to be
<geist>
but speaking of, i'm enjoying playing with the 2.11BSD on the PDP-11
<geist>
it's fairly low, but the fans are huge on the rack case, so it kind is more of a low rumble. and surprisingly uses < 100W
<geist>
but the best is i dug around in my old scsi drives and found this connor 2GB drive that is *perfect* sounding
<geist>
no spindle whine, and a very pronounced and loud click when it seeks
<geist>
so you get the best of a spinny drive, combined with old BSD/unix not really having much of a file cache, almost everything is synchronous
<geist>
so it gives you a real in person experience
<mcrod`>
beautiful
<puck>
geist: i have a pidp-11, which is kinda cute
<geist>
same. that's actually where i got the disk image from, i just DDed the pidp11's 211bsd distro onto a SCSI disk and lo and behold it just booted right up on the real PDP
<bslsk05>
chasecovello/211bsd-pidp11 - 2.11BSD distribution and tools for the PiDP-11 (1 forks/26 stargazers)
<puck>
i want to rewrite the pidp stack some day
<puck>
simh is Okay Enough, but the entire front panel controller is quite unstable and .. overengineered to hell and back
<geist>
yeah, honestly of those two projects, i like the pidp8 more
<puck>
geist: i assume that uses the same controller
<geist>
it's a simpler arch, and it just seems a bit more stable. the lights dont crash every week or so
<puck>
which is uhhh. sun rpc. like. xdr
<geist>
similar, but i think the software stack is somewhat simpler
<puck>
geist: i think crashes are around every few weeks for me? but yeahhhhh.
<geist>
iirc, they just MMAP some shared region and the sim process just blats a copy of the register state
<geist>
but then the pdp8 is much simpler to do
<geist>
i think it may have been designed by someone else (the software stack). the hardware is all oscar.
<puck>
i worked on a rust crate to interact with the gpio, but i was tempted to either add fdt support, or just give up and get a pi pico or something to plug into the 40-pin header, then have the pi in not-the-header
<geist>
yah i guess all told you could pluyg anything into the header and drive the lights and switches huh
<geist>
a pico would probably eat that up
<puck>
yeah, and you con get picos in pi zero form factor
<geist>
from what i understand the electrical bits of the panel is reasonable. there are a few latches and whatnot to multiplex more bits from the limited number of gpio
<geist>
dunno how the knobs work
<puck>
no latches on the pidp!
<geist>
oh... it's just constantly scanning?
<puck>
it's charlieplexed LEDs, with some buttons
<puck>
yeah
<puck>
geist: and the encoders are just two pins on the matrix
<geist>
oh. well, i guess that works if the duty cycle is fast enough
<puck>
i meman, you have to PWM the LEDs anyways for the flickering effect
<geist>
yeah. the pdp8 has a lovely effect if you have a beefy enough cpu where they try to simulate the incandescent light on the pdp-8i
<geist>
and since the cpu runs slow enough if you're trying to be realistic, it has a lovely look
<puck>
the pidp-11 has a bit of a fade going on
<puck>
i tried emulating it in the rust code and it's .. tricky
<geist>
need it for the proper swoosh effect :)
<geist>
that's the biggest downside of the real pdp-11/53 of course. no lights. it's just a big 4u looking rack
<geist>
but really after about 1975 lights were silly
<puck>
..hook the pidp-11 up to the pdp-11/53
<geist>
well, i kinda sorta thought about maybe would be interesting to try to fab a QBUS card that brings some stuff out
<geist>
i doubt anyone has done that, not a lot of QBUS machines around
<geist>
looking in it seems that some of the pins are bent/worn
<bslsk05>
learn.adafruit.com: Overview | Little Desktop Connection Machine | Adafruit Learning System
<geist>
so need to figure out how to get in there and bend the pins back
<puck>
geist: honestly i'd be tempted to suggest soldering in a normal RJ12 socket
<geist>
well worst case i can swap the connectors on the board with the other printer MMJ which i'll never use
<geist>
which seems to be pristine
<puck>
make it a printer rj12!~
<geist>
and yeah, all told i'd prefer a 220 which i think had a db25
<geist>
but yah that's a good idea
<geist>
otherwise the vt320 is very pretty. surprisingly the first CRT i've ever heard that has zero whine. and normally i hear very high pitched stuff
<geist>
so the whine if it has it must be much higher than 15k
<geist>
but that's a good sign, probably means behind that plate is a db25 pad
<puck>
....i wonder
<puck>
yeah
<geist>
yah having a db25 would be lovely, i have a rs232 to mmj converter, but only one and it's expensive
<geist>
and i really hate to have to deal with it
<puck>
ah, A/B/C encodes phosphor (white/green/amber), 2 are 120v/attached power cord/no rs232; then the 3s are 240v, with rs232, and normal kettle plug
<puck>
then there's G2/H2/J2, which are the 120v versions of the 3s
<zid>
woo 240V
<puck>
geist: also, hmmm
<puck>
geist: RS232 to MMJ adapters would be cheap
<geist>
well, if i made one it'd be easy. proper dec ones on ebay are of course over priced, like everything
<puck>
if you can find a source for MMJ connectors cheaply it's just a pretty simple wiring job
<geist>
$50, etc
<geist>
but yeah surprisingly i think amazon has like bags of MMJ connectors for $5
<puck>
yeah i found some cheap ones and a friend has a pile of them
<puck>
since they wewre also used for mindstorms they're decently findable still i think
<zid>
Is many firework outside
<geist>
oooh interesting. mindstorms used it, odd
<puck>
geist: cheap connector not otherwise used, presumably
<geist>
yeah also i had found that if you shove a rj15 12? i forget, regular phone one, directly dead center with the latch broken off, it works
<geist>
so silly of DEC to do that
<puck>
right, offset by 2 pins i presume
<geist>
not even sure that's true. the 4 middle pins are all that matter i think
<geist>
so if you push it in just right it just works
<zid>
\\gt
<puck>
right, if you take out the entire latch
<geist>
zid: what's the occasion?
<geist>
all hail brittania?
<GeDaMo>
Remember, remember the fifth of November; Gunpowder, treason and plot
<geist>
ah, i thought quiet desperation is the English way?
<geist>
ah okay, got a little android spectrum analyzer out. the reason i can't hear it is the vt320 has a nice clean spike at about 19khz
<geist>
that's def above my hearing range. whereas the wyze50 makes all sorts of noise, and has a nice spike at 13khz and a bunch of harmonics off that
<zid>
\\gt
<zid>
.. quiet.. desperation? O_o
<zid>
Quieted away around 1/3rd of the world's total landmass!
<geist>
well that's otherwise what i was wondering what you were celebrating. perhaps subjugating another peoples?
<zid>
We just wanted to give everybody a nice independence day holiday
<sortie>
zid, I swear that is what happened to Sortix no kidding
wereii has joined #osdev
<sortie>
heat: make -C /src # wait and enjoy
<vaxuser>
i thought the crux of lfs was not that it builds
<vaxuser>
but that you have to fuck with the process to do it?
<vaxuser>
in that sense the bsds are decidedly not lfs
<vaxuser>
-alike
<sortie>
It's also nice that it walks you through all the system components and how to build them manually
<sortie>
For a consistent base system like BSD and even my Sortix, you could basically generate a guide to go to each subdir and make and make install, basically what the top level makefile does
<sortie>
That makefile is kinda like the LFS
<sham1>
Recursive make considered harmful, although for this it probably works
<vaxuser>
i just checked lfs manual
<vaxuser>
and it indeed is all about being cumbersome to build
theruran has quit [Quit: Connection closed for inactivity]
<geist>
what is interesting after having been building and fiddling with 2.11 BSD the last few days is how much the netbsd/openbsd/freebsd builds *havent* changed in the last 30 years
<geist>
it's pretty close in general, especially with /usr/src/sys/conf stuff
<geist>
i've always been pretty happy with precisely that sort of build. makes logical sense
<geist>
and you get a functional system at the end
<vaxuser>
back in the day you had to mess with it by hand tho
<heat>
why doesn't openbsd use linux?
<vaxuser>
run config, make obj and so on
<vaxuser>
at least on free and net this is all wrapped now
<Ermine>
If openbsd so cool why didn't they do closedbsd
<vaxuser>
for example on free you 'make buildkernel' and you are done
<geist>
sure
<vaxuser>
Ermine: because closed is opposite of cool
<heat>
that sounds like a GNU opinion
<geist>
well ,there was a closed bsd. was BSDi
<heat>
is this matthew garrett?
<geist>
just didn't survive
<vaxuser>
yes it is why yes hello
<heat>
geist, early sunos was also bsd-based wasn't it?
<geist>
i think so too, it switched to sysv with 2.x
<vaxuser>
bsdi... there are bits of it which got into freebsd
<vaxuser>
the switch is a well known fact
<vaxuser>
and a massive flamewar material
<heat>
system v was poggers
<geist>
386bsd, etc etc. bunch of forks off 4BSD
<vaxuser>
you know a story why there is 4.1 etc bsd intead of 5bsd?
<vaxuser>
supposedly at&t took an issue
<vaxuser>
cause sysv
<geist>
right
<vaxuser>
bunch of wankers
<heat>
vaxuser, sir, i have a question
<vaxuser>
no
<heat>
verify_update_old_key+0x1b2/0x1c0
<vaxuser>
next
<heat>
what do the hex numbers mean there?
<heat>
<offset>/<symbol_size>?
<vaxuser>
offset vs total size
<heat>
ah
<heat>
cool, thanks boss
<vaxuser>
j/k it's a fraction of the function already executed!
<vaxuser>
are you subbed to bcachrfs or somethin
<heat>
no lol, you just linked the lore.kernel.org
<heat>
i only sub rust-for-linux and linux-btrfs
<vaxuser>
true, but htat hing only popped up *now*
<sham1>
> rust
<vaxuser>
you don't need offsets into functions in rust
<sham1>
Webdev kernel
<vaxuser>
does not work? just rstart
gildasio has quit [Ping timeout: 256 seconds]
gildasio has joined #osdev
<vaxuser>
geist: so how long does it take to compile
<vaxuser>
geist: is time(1) available
<geist>
sure
<geist>
i didn't recompile the world, but it took about an hour to compile the kernel
<geist>
about 45s-1m per file and like 100 files
<vaxuser>
hm
<geist>
the whole world would probably be like a day
<geist>
but then if you run it in simh, it already can emulate a pdp11 thats an order of magnitude slower, with zero seek time
<geist>
takes like 15 seconds there
<geist>
s/slower/faster
<vaxuser>
:]
<vaxuser>
is thre make -j on that sucker?
<vaxuser>
(probably not, but...)
<geist>
no
<geist>
i actually tried for lulz
<vaxuser>
right
<geist>
it's only got 1.5MB ram anyway
<vaxuser>
ooff
<geist>
though that's perfectly suitable to run it
<vaxuser>
a breakdown user sys real would help
<vaxuser>
maybe it is not idling much
<vaxuser>
or maybe is idling A LOT
<vaxuser>
or maybe compuation of that is broken
<geist>
this is a 15Mhz 16 bit computer
<vaxuser>
i mean it may be idling waiting for that i/o
<vaxuser>
and by idling im ean burning cpu
<geist>
oh, maybe
<geist>
it's hitting the disk somewhat, but not wailing on it
<geist>
most of the per file compile step is it just thinking
<vaxuser>
any fuckery to replace storage with a sd card?
<vaxuser>
:]
zetef has joined #osdev
<geist>
i did for a bit, i have a scsi2sd card
<vaxuser>
or is thte entire idea not kosher in your approach
<geist>
i did for a while until i got it bootstrapped, and then i copied the image to a real disk
<geist>
since a) it's more fun that way and b) i want to use the scsi2sd for other purposes and i only have 1
<geist>
now i have the computer in a semi permanent place so i'm happy
<heat>
2.11BSD has those old-ass cc(1)'s?
xenos1984 has quit [Read error: Connection reset by peer]
<vaxuser>
geist: does it have a reboot syscall
<vaxuser>
A reboot utility appeared in 4.0BSD.
<vaxuser>
lol
<geist>
it has a halt
<geist>
some amount of stuff was backported to 2BSD
<heat>
you know, why is 2.11BSD a thing?
<vaxuser>
what's the newest bsd which runs on it?
<geist>
though it's a 2BSD line, there are still a set of patches being developed
<vaxuser>
someone is writing them *now*?
<heat>
does it have actual utility or is it just for computing necrophiliacs
<geist>
heat: because its the only thing that runs on 16 bit machines
<heat>
vaxuser, yes
<geist>
3BSD and above need 32bit flat memory model
<bslsk05>
redirect -> photos.google.com: Shared album - Travis Geiselbrecht - Google Photos
<heat>
dang that's big
<heat>
how big is the PDP?
<geist>
it's the rack at the top. it's full length, looks about 3u
<geist>
i may get a rail and install it on my rack o the left
<geist>
but the vaxserver 3800 is the pedestal underneath it
<vaxuser>
did you get all of them operational yet/
<geist>
yep
<heat>
oh that's smaller than I expected
<vaxuser>
how many on some network
<geist>
any larger would probably take too much power for me to deal with right now
<heat>
vaxuser, 2.11 has a network stack
<geist>
yep. i can telnet into it and everything
<vaxuser>
solid
<geist>
the vax3800 is going to need some more work. has a copy of VMS 5.5 on it that i reset the system password,etc
<vaxuser>
at this point you may have a setup comparable to theo
<geist>
used to be some sort of server for a city (there's a sticker on the front)
<geist>
but they were using it in a vaxcluster (hence the label CPU A)
<geist>
so doesn't really have any networking, since the cluster would have solved that
<zid>
telneted is a valid scrabble word.
<zid>
you're welcome.
<geist>
also bummer is the two drives in it are not SCSI, they're using an interface called DSSI
<heat>
geist, aw so you don't have networking on the vax? that sucks
<geist>
which i dont completely grok yet. looks ike it's similar to SCSI but i guess DEC proprietary
<geist>
well, i have 4 other vaxen, all of which have networking, and are technically faster than the server
<heat>
dang
<geist>
actually no, the sever *has* ethernet, but the VMS install on it right now does not have networking enabled
<heat>
this is the true vaxen useren
<heat>
5 vaxen
<geist>
so trouble is since the drives are not scsi and i dont have a TK70 tape drive anywhere else, i cna't easily get stuff onto it and off it
<geist>
since all i have is a serial console
<geist>
so i'm thinking of looking out for a QBUS SCSI card for the vax
<geist>
looks like that sort of thing does exist
<vaxuser>
you may be comepting for biggest vax deploymenti n the world at the moment
<geist>
it's nice now that it's winter since it keeps the room warm
<vaxuser>
but now that i said it, there is probably someone wtf all-vax setup which is *still* in use
<geist>
and same weith PDP-11s
<ripsquid>
I think I am having issues setting up the 8259 PIC. Is there a way to "force-send" an interrupt through the 8259 PIC in qemu to test it?
<heat>
US army nuclear system
<geist>
theres some lore that there are some nuclear plants that still use them
<heat>
ripsquid, no
<geist>
and maybe some... yeah military stuff
Ram-Z has quit [Ping timeout: 240 seconds]
<heat>
ripsquid, what do you need? what's going wrong?
<mcrod`>
probably for the best re nuclear stuff
<mcrod`>
that's the definition of "if it ain't broke, don't fix it"
<mcrod`>
especially cuz downtime would mean vulnerability
<geist>
yah and a late model thing like that is probably very very reliable
<geist>
and QBUS and unibus are quite reliable busses, very checksummed, etc etc
skipwich has quit [Ping timeout: 240 seconds]
<vaxuser>
but this is a great example of something which *will* break
<geist>
so if you built some controller card aside from regular silicon aging, should continue to work forever
<vaxuser>
and then you will be f-worded
<ripsquid>
heat, I am not fully sure. I am able to call my interrupt with "int 33" but I don't think I receive any interrupts from the 8259 PIC. I would love to test it so I know if it works or not.
<heat>
ripsquid, did you enable the PIT? that's a good first test
<geist>
yah int 33 is local to the cpu, will not go through the irq controller
<mcrod`>
vaxuser: the IRS is still somehow going strong, although dying, on ancient equipment
<vaxuser>
mcrod`: literally on ancient equipment or new equipment emulating old
<heat>
mcrod`, what if US nukes ran on node.js + express + mongodb + redis + elastisearch
<mcrod`>
literally on ancient equipment
<vaxuser>
wut
<ripsquid>
heat, I think I tried but I am not fully sure if I did it correct. I would love if there is a simple C example that just sets it up as simple as possible.
<mcrod`>
the type where the people who can fix it are dead or dying or retired
<geist>
yah but it's documented and you could figure it out and debug it with a oscilliscope
<bslsk05>
wiki.osdev.org: Expanded Main Page - OSDev Wiki
<mcrod`>
and by different I mean discord didn't exist and IRC was *the* shit
<vaxuser>
geist: well technically it was not *here* ;)
<geist>
was waiting for someone to say that
<geist>
you win the prize
<vaxuser>
please to serve
<vaxuser>
pleaed
<vaxuser>
fuck
<geist>
achtuuallly
<mcrod`>
still can't believe that happened
<vaxuser>
there you go
<mcrod`>
that was the fall of dalnet level
<mcrod`>
I started using IRC not too long after that happened
<vaxuser>
on that note i'm on irc since about 2001
<heat>
wow yall so old
<mcrod`>
2006 for me
<vaxuser>
and i'm still in contact with about 3 people from when i startd
<geist>
well, this channel predated freenode too
<vaxuser>
probably helps that they also do IT
<geist>
i joined it when it was on openprojects
<mcrod`>
my first introduction to IRC was wanting help on PSP custom firmware
<geist>
and apparelty it started on efnet or something in 1999 before that
<mcrod`>
i was 13 leave me alone
<mcrod`>
as far as I know now efnet is a crapshoot
<vaxuser>
heh
<heat>
i respect the psp grind a lot more than i respect your distro building grind
<vaxuser>
irc networks were full olf lol problems which they refused to fix
<vaxuser>
like nick or channel registration
<vaxuser>
for example takeovers were common on ircnet
<mcrod`>
that IRC network where I used to go to is long, *long* gone
<vaxuser>
while the entire thing could have been sorted out no problem
<zid>
freenet is the one true irc
<vaxuser>
so did anyone check osdev on freenode today?
<vaxuser>
:)
<mcrod`>
tell me something
<heat>
CompanionCube, how's the freenode going?
<mcrod`>
is Zhivago on #c in freenode
<mcrod`>
or is he completely dead and gone
<vaxuser>
hahaha
<vaxuser>
that is a name
<vaxuser>
dude left years ago afair
<zid>
he's gone
<vaxuser>
before the drop
<zid>
a good few years back now
<mcrod`>
probably dead with the way he acted
<CompanionCube>
heat: implying i pay attention to those buffers
<zid>
don't think he even knows what libera is
<zid>
why? zhiv was a great op
<mcrod`>
can't believe he lived as long as he did
<vaxuser>
fwiw #c was always kind of a shite channel
<mcrod`>
maybe he's still alive
<CompanionCube>
backlog suggests there was actual activity ~recently, though?
<mcrod`>
zid: with him, it was "you would get the right answer, but after 5 hours and 4.99 of those hours were being berated"
<vaxuser>
they guy was a massive time waster
<mcrod`>
to such a level that I don't know how he functioned
<vaxuser>
but at the same time most people asking were also time wasters
<mcrod`>
I legitimately believed for a long time that he had a serious psychiatric ailment
<vaxuser>
so it made sense to an extent
<zid>
you were probably a child being abusive if that was your experience with him
<mcrod`>
no I mostly watched
<vaxuser>
what
<vaxuser>
his opening line is "my retarded little friend"
<vaxuser>
or so
<mcrod`>
yes
<zid>
One was probably a child being abusive if that was one's experience with him
<mcrod`>
the worst part is
<mcrod`>
he'd call people stupid if they didn't have an exact per standard definition of something
<zid>
If you asked good questions he gave good answers, if you asked bad questions, on a busy and popular channel, he asked which book you were following and if you said you weren't, he told you to buy one
<ripsquid>
heat, I think I ported your code correctly and nothing is happening. Guess I will need to find another library for PIC8259 or make my own.
<zid>
Yes, because it was a channel for teaching C
<mcrod`>
no, no, you don't understand
<zid>
You know I was an op in there right?
<zid>
I very understand
<vaxuser>
you were? lulz
<mcrod`>
i did not know that, but that explains a lot
<heat>
ripsquid, you should make your own
<mcrod`>
were you a part of #c-banned?
<mcrod`>
i was
<heat>
i imagine you're using a crate - don't use a crate
<mcrod`>
a very long time ago
<mcrod`>
with poppavic and such
<zid>
oh hey poppavic is a name I've not heard in a time
<mcrod`>
yeah no idea what happened to him
<heat>
ripsquid, OH did you sti?
<zid>
he was on freenode later than zhiv was at least
<ripsquid>
heat, This is supposed to be a school project so we were trying to take some shortcuts.
<zid>
most of us left #c after zhiv left
<mcrod`>
from what I understand he was an old fart
<mcrod`>
so, might be dead
<zid>
it became too unmoderated to want to be there
<mcrod`>
but I was ejected from #c-banned because admittedly I was a bit too immature
<zid>
just people with no clue giving incorrect answers to other people with no clue all day, precisely what happens if you don't heavily moderate a place like that
<mcrod`>
but there was always a consistent grumpiness
<mcrod`>
_consistent_
<vaxuser>
zid: c aphorisms were great
<vaxuser>
zid: the channel was mostly crap, but channel's website was pretty good
<mcrod`>
yeah I picked up KN King's book off of the wiki
<mcrod`>
ultimately, all I'll say is you can certainly get good information off of #c, back then or now
<zid>
I've not checked in a couple of years, but you certainly couldn't then
<mcrod`>
but back then, even if your question was innocuous, "my retarded little friend" is what you'd get
<bslsk05>
pdf.datasheetcatalog.com: Intel mXvqwzr datasheet pdf
<zid>
if you asked anything you got 4-5 people telling you utter nonsense that was fully UB or just plain incomprensible, and *maybe* one of the regulars was there like poppavic or kate or someone trying to talk to you, but being shouted down by the noise
<zid>
SNR became incredibly poor
<mcrod`>
or "where's your book" which is *fine*, but you could say that about anything
<mcrod`>
"how do I do x" "RTFM"
<mcrod`>
thanks. that means a lot.
<geist>
somewhat like the SNR right now in the chanel
<mcrod`>
zid: I've seen that so many terrible times
<mcrod`>
and I have to tell you
<zid>
I assume lots of people have linked it to you.
<mcrod`>
it's not quite normal to have a whole HTML document for something like that
<ripsquid>
heat, Isn't sti needed for "int 33"?
<zid>
If you disagree with it, say you disagree with it
<mcrod`>
by any normal social standard
<heat>
ripsquid, no
<ripsquid>
Oh. That was the issue
<zid>
but it's very much the required level of effort many of us deem minimal for doing hours of someone else's work
<heat>
int 33 -> synchronous exception
<geist>
right the int instruction does not go through the IRQ controller, it's directly on the cpu itself
<mcrod`>
this is pretty much written by someone who is extremely grumpy
<mcrod`>
and can't tolerate almost anything
<geist>
doesn't even need sti, because cli/sti unblock *external* interrupts
<mcrod`>
that's my take on that
<vaxuser>
ok seriously, the offtopic convo should go quiet for the time being
<geist>
not exceptions or synchronous things like int
<mcrod`>
ok ok
* mcrod`
leave
<zid>
them not being shitty, having a proper questions etc is the *minimum* I expect of people who don't want me dismiss them out of hand and tell them to buy a book.
zetef has quit [Ping timeout: 264 seconds]
<heat>
device on the bus asserts IRQ 1 or something -> asynchronous interrupt, goes through the PIC, needs the I flag
<zid>
I think all this is easier if you've done something more simple and sane first like gameboy.
<heat>
but seriously, try writing your own PIC code. the 8259 really is a dumbass little chip
<zid>
There's a very good doc for the 8259 that always takes me 10 minutes to find
<geist>
also there's a good chance if you just enable the PITs IRQ there's already one queued up
<geist>
oh hmm, at very very quick glance that's nice. talks about how it's wired up, etc
<geist>
though i doubt most people care about that, they just wanna get to the code snippets
<heat>
oh haha broknthorn
<zid>
yea I skim to the bit I want, when I need to do PIC things
<zid>
it's nicely presented and has text explaining it + example code
<zid>
so it's hard to come away with an incorrect interpretation
<heat>
well it's also wildly inaccurate for remotely modern hardware :P
<zid>
doesn't however, matter
zetef has joined #osdev
<geist>
well, yes and no. the model of how it originally looked is what modern hardware is emulating for the most part
<heat>
why did they write it in assembly?
<geist>
so it's not inaccurate, it's just a description of the virtual hardware
<zid>
because that's cleanest, imo
<zid>
Writing it in C means you have to hand-wave a bunch of stuff
<geist>
well, that *always* happens. evenon the other osdev wiki, folks always insist on doing something in asm or whatnot
<zid>
given C's lack of i/o
<geist>
which does not help newbies
<geist>
sure, but that makse it effectively pseudocode, which i think is what you want
<heat>
gosh i think this tutorial is the one that really tries to use msvc
<zid>
your C is just 'fight the inline assembly to spit out the instructions I know I want, because they're written here on this page'
<zid>
so teaching it in C doesn't add any clarity to me, if anything it massively detracts
<zid>
because it turns into macros that you don't have
<geist>
zid: right, but problem there becomes 'omg this is some weird asm syntax i dont understand' or 'what is this asm crap' etc
<zid>
should those people be reading this tutorial?
<zid>
Should "I can use out dx, al" not be a *pre* requisite for programming stuff over the i/o bus?
<geist>
well, i dunno! if you do it in pseudocode then the folks that know the asm can do it, and the folks that dont have a starting point because they can at least understand what the code is trying to do
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<zid>
Doing out dx, al correctly from *C* is actually incredibly advanced
gbowne1 has joined #osdev
<geist>
it's if you're trying do demonstrate the intent of how to control the hardware, vs how you do it in <insert language here>
<geist>
themuch worse for me is something like the PCI article or AHCI or something where someone insists on writing the code in asm
<zid>
like, should the intel manuals be written as `mov eax, 39022; crc eax` or C psuedocode that does `CRC(39022)` with the codegen for that being too large to fit int he marign?
<geist>
for the pic/pit, less of a deal
<zid>
I don't see the benefit at all, only huge downsides
<bslsk05>
wiki.osdev.org: Detecting CPU Speed - OSDev Wiki
<zid>
you need to have a very good understanding of what the optimizer etc predicates elimations around etc
<zid>
in order to constraint things perfect
<geist>
but i'm also curious what's up with needing to set the selector there anyway
<zid>
I don't mind that being written in asm in the least, heat
<geist>
like there's a basic assumption that the es selector is already ds
<zid>
fuck knows what that ~ stuff is though
<geist>
it's as if that sequence was ported from asm and they thought they needed to push/pop the es selector
<zid>
and why it's randomly missing spaces etc
<zid>
geist: Just someone who doesn't know much trying to be 'helpful', I imagine.
<zid>
Copy pasting bits of stuff they found elsewhere without much deeper knowledge
<geist>
but that being said i think the world is better off with the wiki than without
<geist>
it's just you get what you pay for
<zid>
I've still yet to see good code on the wiki, but I like that the wiki exists yea
<heat>
zid, they go through a great effort to manually time the CPU and skip the actual solutions on remotely modern hardware
<zid>
didn't know that was contentious
<geist>
i still use it to this day quite frequently for things like serial stuff
<zid>
heat: it says it's for PENTIUM
<zid>
so it's copy-pasted from some 40 year old code
<zid>
but cpu detection code *should* be in assembly
Arthuria has quit [Ping timeout: 255 seconds]
<zid>
there's no real way to write it in C in the first place unless you're willing to *heavily* invest yourself into __attribute__(("-mgeneral-regs-only")) nonsense for days first, and it *still* needs assembly even then, for cpuid (or the handy gcc intrinsic that exists now)
<geist>
well again depends. it's quite easy in most cases to write/copy inline asm wrappers that work, and write it in C
<geist>
yes you are writing assembly, but in a certain sense you're not: you're just defining an intrinsic and then writing it in that style
<geist>
its where the main logic exists or not
<geist>
is what i consier to be in language X or Y
<zid>
we've seen how well "people trying to write the asm intrinsic version" goes last article
<zid>
I'm surprised you're still defending it
<geist>
of course i'm defending it. because people fuck that up doesn't mean it can't be made to work
<geist>
they also royally fuck up asm too
<zid>
This is like 10 instructions, and it'd be that many constraints in a gcc-only assembly block too
<zid>
so you've gained nothing but adding noise
<geist>
okay, agree to disagree here
<heat>
if you have well defined, provably correct inline asm wrappers for basic stuff, it's way easier to use
<zid>
anything that doesn't need to touch special x86 only instructions can absolutely be 100% and I'd prefer that
<geist>
heat: if anything there should be an osdev page with precisely that
<heat>
there is
<geist>
since virtually every inline asm wrapper you'd ever want has been written by someone and can be made to be perfect
<heat>
you would really need __attribute__((always_inline)) for things you really **want** to inline
<zid>
clever: that's C++
<geist>
sure
<zid>
C++ has *entirely* different rules for what inline means
<clever>
zid: its only c++ because i needed to template the arg types
<zid>
It's one of the major differences between C and C++'s shared heritage
<clever>
without that, id need to write the same code 4 or more times
<clever>
how does c and c++ differ in this case then?
<geist>
here's my point, marking it inline maybe is excessive depending on which language it is, but then i have a header ifle here that may be in C and may be in C++, and may be compiled with -O0, or maybe clang or gcc or whatnot
<zid>
I 100% cannot comment on it, either
<geist>
so i put inline in it, and it tells someone reading it it's probalby inlined too
<geist>
no harm no foul
<geist>
i dont see the problem
<zid>
geist: It's almost certainly not problematic either way
<geist>
then there you go
<zid>
so then why not agree with me?
<zid>
why are you right?
<geist>
becuase i disagree with you
<heat>
i put inline on every function i define in a header, because i do usually want those to be inlined
<geist>
right, i do too
<zid>
yea I never ever ever define functions in ehaders
<clever>
heat: yep, exactly what i do as well
<zid>
that's a massive no-no for me
<heat>
heck, for things i demand inline for, i add __always_inline
<geist>
well there's the fundamental difference. these are functions that are in headers, things like one liners like this
<zid>
heat: see, that I agree with
<geist>
sure if it's local to a file static is totally fine with
<clever>
zid: for me, it depends on the use-case of the function, and if i want to avoid the overhead of a function call
<clever>
most of the time, they should go into a .c file
<zid>
if you *actually* want it to be always always inlined, because your code requires it to function, always_inline is the solution
<geist>
hey at least we're beyond the era of extern inline
<clever>
geist: wtf is that? lol
<geist>
i dot want to remember
<zid>
sprinkling on hints to inline it, when it was going to inline it anyway, is just weird and *smells* of C++ programmers misunderstanding C
<geist>
there were all these dumbass rules there, was a C vs C++ thing. got resoled at some point. probably C99
<zid>
from the gcc manual
<zid>
C code ordinarily should not use inline. Typically it is better to let the compiler figure out whether to inline, as compilers are pretty good about optimization nowadays. In this sense, inline is like register, another keyword that is typically no longer needed.
<ripsquid>
How does programs get keyboard input in linux? I am trying to figure out how to implement keyboard handling (I know too little about this so might be a stupid question)
<zid>
I'll make a concession, you may use static inline, if that function also uses 'register' :P
<zid>
ripsquid: through many many layers
<geist>
geenral strategy is to read keys off the hardware in an IRQ and put it into some sort of queue
<ripsquid>
zid: Ah... Well what are my options for simple keyboard input for programs?
<zid>
Sorry I can't be more specific, it's a very non-specific question
<zid>
read()
<clever>
ah, i remembered a reason to define (class) functions in header files with c++, gating access to private class members
<geist>
and then at another layer have some code that waits for the queue to have somehting in it and process it
<clever>
for example, having a `get_foo()` defined in the header, but no `set_foo()`
<zid>
Internally it's emulating a DEC terminal's internal hardware
<clever>
so its read-only to external things
<zid>
with a bunch of queuing and other things
<clever>
but after compiling, it has the identical performance to just a direct access
<zid>
which itself is emulating a teletype
<heat>
ripsquid, set up the PS/2 controller and keyboard, handle its IRQs and read from the io ports
<clever>
as-if the function didnt exist
<zid>
heat: we found a good imagine for this last time right?
<heat>
zid, yeah but im pretty sure emulating the tty, n_tty and vterm layers is not ripsquid's point here
<zid>
he did ask 'in linux'
<zid>
'from user code'
<zid>
so it's more accurate than your answer imo
* geist
shrugs and wanders off
<ripsquid>
Yeah. I am asking about how the kernel sends it to a running program. Although what is a simple solution for it? It doesn't need to be a good solution
<netbsduser>
about the C++ v.s. C earlier: bjarn stropstrop actually says in his personal FAQ "i never intended C++ and C to diverge, this is a mistake which ought to be corrected"
<heat>
ok lets step back for a second
<zid>
Like for X the chain would be like, "usb/ps2 is set up to fire an IRQ on keypress, keypress goes into a buffer in the interrupt handler, is picked up by the keyboard driver and translated to a character code, is handed off to the virtual terminal emulator, line discpline is applied, is queued into the recv buffer on /dev/tty7 or such, which alerts xorg's epoll/select,
<heat>
ripsquid, what do you want to do?
<zid>
which causes the character to be read, which generates a message over dbus
<zid>
which alerts an application, which read()'s it
<heat>
xorg doesn't use dbus
<zid>
might do, might not do!
<clever>
zid: i think X is heavily using /dev/input now, not /dev/tty7
<clever>
evtest is one way to read those input devices
<heat>
also probably not the tty either, they use input devs
<zid>
yea there are more modern and different paths and stuff
<clever>
and it will return a whole struct for each event, rather then just a byte or 2
<clever>
yeah
<ripsquid>
heat, I have now setup interrupts and is working on converting scan codes to which key got pressed etc. I am now trying to figure out where to send/put these events so that software running under my kernel could use it
<zid>
but it's not a bad general flow imo, if you have a better one post it
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
<zid>
ripsquid: Do you have anything like a file object yet?
<zid>
That's what *nix philosophy says to do, buffer that character in a file, so that someone can read() it
<ripsquid>
Nope. And I am not looking for a specially good solution. Just a simple one.
<zid>
historically that'd be say, to buffer it on /dev/tty
<heat>
ripsquid, the really horrendous, complete solution would involve a buncha layers of backwards compatibilit (in the form of the tty subsystem, n_tty line discipline, and an emulator for 1980s terminal hardware)
<zid>
so that your terminal emulator can read it, and then give it to your shell
<heat>
the easy solution is something like "read from the keyboard, buffer it in, hand those bytes out in some way"
<heat>
where way = special syscall, or read() from a file descriptor, etc
<zid>
but.. "for now".. a fake file that just queues up some characters in a buffer and you add a 'pop character from buffer' syscall would work?
<zid>
sys_kbd_get
<zid>
and you replace it with a real interface later
<zid>
just so you can have 1 program that can take input while it's running, to test all the code paths out
<ripsquid>
I will just do a syscall that sends either characters or events like key_pressed, key_released
<zid>
well syscalls can't really send, that'd be signals