<bslsk05>
github.com: lk/arch/arm/arm-m/vectab.c at master · littlekernel/lk · GitHub
<geist>
it's like .bss.prebss which i explicitly avoid memsetting over
<geist>
that way it gets the advantage of bss (not in the binary) but still works for being used before the bss memset
<Ermine>
thank you for advice
<mjg>
premature evil is the root of all optimisation
[_] has joined #osdev
epony has quit [Remote host closed the connection]
gxt has quit [Ping timeout: 240 seconds]
epony has joined #osdev
[itchyjunk] has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
gog has quit [Quit: byee]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
loosipher has joined #osdev
<loosipher>
So if my project is licensed with the GPL, I should put the source of my project in with the release, yes? And using GRUB, I need to put the source of that with the release too, yeah? I just want to make sure I follow the rules for free and open source.
epony has quit [Remote host closed the connection]
<Mondenkind>
if you wrote the code, then you're literally allowed to do whatever you want with it
<Mondenkind>
if you didn't write the code, then you can't do _anything_ with it, unless the person who wrote the code gives you permission to
epony has joined #osdev
<Mondenkind>
the gpl being one form of (conditional!) permission
<loosipher>
I figured the GPL had some level of restriction. I mean, I could change the license, but assuming I want to stick with it. I understand in the case of my own code, I suppose.
<loosipher>
Right. The GPL requires the disclosure of code and me not trying to make money off it, I think.
<Mondenkind>
if you wrote the code, you can do whatever you want with it. Licensing your code to other people under the gpl restricts what _they_ can do with it; it doesn't restrict you
<Mondenkind>
it's not uncommon to provide code either under the gpl or under a more permissive license you have to pay for
<loosipher>
Okay. That's good to know. So like, using GRUB with my OS. If I release a bootable CD with GRUB on it, then I would need to pack the source with it? I think I read that correctly off the wiki. And I thought the gpl was explicitly free?
pm123123123 has joined #osdev
<loosipher>
Looking into it I'm seeing it's not true that it's free...
<klange>
loosipher: no, the GPL does not require you to distribute the source, only "make it available"
<klange>
if you aren't modifying it, it's perfectly acceptable under the GPL to just say "go grab it from here, i didn't change anything"
<loosipher>
Okay. I think that makes sense. Thank you.
<klange>
when the original gpl was written, the idea of having to distribute the source alongside binaries would have been preposterous, so it was always designed to allow for providing the source "by request", and the FSF has clarified that giving people a link to a web host is fine
<loosipher>
Sounds good, I just have to provide a link to the web host like in the readme or somewhere accessible and easy-to-find.
goliath has quit [Quit: SIGSEGV]
pm123123123 has quit [Quit: Client closed]
pm123123123 has joined #osdev
<heat>
if they got the README they probably found it ;)
gorgonical has joined #osdev
navi has quit [Quit: WeeChat 4.0.4]
<pm123123123>
finally solve the padding/align issue. realize that it's 8byte aligned not 8bit. now my kernel loads but still no graphics.
<geist>
woot
<heat>
pm123123123, why do you say no graphics
<gorgonical>
Since I'm sick I want to plug my work this week too. I have a webassembly runtime running in my kernel in secure mode
<gorgonical>
because buzzwords make reviewers excited
<pm123123123>
heat: there's a line of C code which supposedly draw some patterns on the screen: for (i=0xa0000; i<=0xaffff; i++) { write_mem8(i, 15); }. but there isn't any
<heat>
that's not going to work
<geist>
gorgonical: is excite
<pm123123123>
screen did clear so i assume it's no longer text 80x25 mode
<heat>
high resolution framebuffers aren't at 0xa0000
<heat>
you need to parse the framebuffer info multiboot 2 gives you, and draw there
<pm123123123>
right i follow the book with 320x200x8
<geist>
the address of the framebuffer will get passed in the multiboot inos
<geist>
yeah
<gorgonical>
geist: honestly it is very exciting to go from janky research work to running mongoose over tcp as well as arbitrary wasi bytecode
<geist>
and the bit format, etc
<geist>
gorgonical: yah, sounds neat
<heat>
gorgonical, congrats, you are now web eBPF
<pm123123123>
heat: i hear you. not capable to check fb info yet.
<heat>
and because it's mongodb it's also WEB SKEL
<gorgonical>
not mongo
<gorgonical>
mongOOSE
<geist>
really especially in embedded context, the idea of having a little multithreaded thing that runs some interpretted language is not bad
<heat>
oh :(
<heat>
so you're running nodejs?
<gorgonical>
we are not
<geist>
oh i dunno, that's how i read it
<geist>
my skillz with web stuff is zero
<heat>
isnt mongoose literally just a nodejs library or do i have it wrong?
<gorgonical>
mongoose is an embedded web server
<gorgonical>
runs on everything in the universe
<heat>
ohhhhhhh
<heat>
i have the wrong mongoose lmao
<gorgonical>
basically we wanted to support some version of a LAMP stack
<gorgonical>
so its KMSW stack lmao
<gorgonical>
kitten-mongoose-sqlite-wasm
<gorgonical>
geist: webassembly is mostly a browser thing but you can also compile c or rust code to it and run that in the standalone runtimes
<heat>
web assembly is a top 10 worthless tech
<gorgonical>
I think the idea of a more universal vm/runtime is intriguing
<heat>
it's supposedly designed to be fast and run LE RUST
<heat>
but it's slow compared to regular js
<gorgonical>
Sure but the reason I did work with it is because it has interesting security use cases
<gorgonical>
Provides "free" sandboxing at the runtime level
<heat>
yeah
<heat>
did you look into the uBPF thing
<gorgonical>
that's the whole vm inside the kernel right
<heat>
no, that's eBPF
<heat>
uBPF is the userspace version of it
<heat>
and it's what windows uses for its eBPF support
<bslsk05>
cloudblogs.microsoft.com: Making eBPF work on Windows - Microsoft Open Source Blog
<gorgonical>
hmm
<gorgonical>
when would I want to allow arbitrary code to run in the kernel space though
<gorgonical>
Even if its verified
<gorgonical>
drivers?
<heat>
i mean... aren't you running wasm just now
<gorgonical>
but that's in userspace
<heat>
I have a webassembly runtime running in my kernel in secure mode
<heat>
that's what you said
<gorgonical>
I see how that could be misleading
<gorgonical>
let me rephrase: my kernel, which runs in secure mode on the hardware, now supports wasm3 and all its features
<heat>
ah, gotcha
<heat>
if you're porting web stuff you should port v8
<heat>
it's annoying but not hard
<gorgonical>
is there some other reason to support it than just performance?
<heat>
support what?
<gorgonical>
v8
<heat>
sure, you get nodejs
<heat>
(eventually)
<gorgonical>
makes me wonder if someone has compiled nodejs to wasm
<gorgonical>
I know so little about web stuff I'm not even really sure if that's a correct thought
<heat>
nodejs has v8 which has a wasm interpreter
<heat>
so that'd be pretty fucking freaky if you ask me
<heat>
hmmm... i wonder if you can even JIT WASM bytecode
<heat>
probably not
<gorgonical>
wasm3 can aot compile stuff
<gorgonical>
which is neat
xenos1984 has quit [Read error: Connection reset by peer]
<gorgonical>
anyway I'm hoping that supporting a rest api via mongoose will be considered good enough for most of our uses anyway
<heat>
r u webdev????!?
<heat>
i'm very concerned you are not using proven web technologies like php and XML and Oracle SQL
<gorgonical>
I'm not sure I would want any of that shit running in a car
<gorgonical>
But it probably all already is :(
<heat>
do i want wasm in a car
<heat>
wait why does a car have a web server
<gorgonical>
it at least has security by design in mind
<gorgonical>
"smart" cars with multiple operating zones are an idea now
<gorgonical>
and how they are connected is unclear
<gorgonical>
I agree hopefully not with REST APIs lol
xenos1984 has joined #osdev
<gorgonical>
"you know actually today the throttle is just a digital input that sends a post request to http://192.168.1.100/throttle/set/" to change the acceleration
<bslsk05>
192.168.1.100 <timeout>
<gorgonical>
poor robot
[_] has quit [Remote host closed the connection]
<Affliction>
"And it turns out the car listens has a http proxy on its radio modem, and allows the outside world to talk to reach that endpoint with no auth. Thank you all for coming to my presentation, 38c3 has been great."
<Affliction>
how did i mangle that sentence so badly, has a http proxy listening*
<zid>
thankfully a lot of that is illegal, but almost certainly exactly what a tesla is doing no doubt
<gorgonical>
someone recently regaled with me how aggressively regulated the speed of windshield wipers is
<Affliction>
regulated - legally? or a specific implementation maintains tight control?
<gorgonical>
the implication was both
<gorgonical>
that they must have specific operating parameters for intervals between swipes, swipe speed, etc
<gorgonical>
so much so that in the age of computerized cars usually the wipers have their own microcontroller toggling the motors
edr has quit [Quit: Leaving]
pm123123123 has quit [Quit: Client closed]
<zid>
hah, paused the song I was listening to so I could listen to a youtube video
<zid>
and they were using the song I just paused as the bgm
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
* geist
just queued up Meddle on vinyl
<geist>
so that's like 23 minutes of song
epony has quit [Remote host closed the connection]
epony has joined #osdev
Arthuria has quit [Ping timeout: 268 seconds]
sbalmos has quit [Ping timeout: 256 seconds]
sbalmos has joined #osdev
sbalmos has quit [Ping timeout: 264 seconds]
<heat>
ima write a car in nodejs + expressjs + angularjs + mongodb + solaris
<heat>
it'll scale very hard and it'll shard very hard too (mostly on impact)
sbalmos has joined #osdev
<heat>
or i'll write one in rust and use tokio to asynchronously adjust the throttle
<heat>
plus a myriad of crates i do not control
heat has quit [Ping timeout: 256 seconds]
<immibis>
rust is very popular in cars. parts of the implementation have been found to spontaneously convert themselves.
<immibis>
beer crates are also popular cargo
<Ermine>
isn't automotive industry a land of QNX?
qxz2 has quit [Remote host closed the connection]
zetef has joined #osdev
<klys>
so I finally bought the intellec mds-720 dual 8in floppy drives. going to fully disassemble one and measure it for an .stl model.
Yoofie8 has joined #osdev
netbsduser has joined #osdev
Yoofie has quit [Ping timeout: 264 seconds]
Yoofie8 is now known as Yoofie
mahk has joined #osdev
netbsduser has quit [Ping timeout: 276 seconds]
gbowne1 has quit [Quit: Leaving]
yoo has quit [Ping timeout: 264 seconds]
<geistvax>
klys: oh nice!
<geistvax>
make sure you dont destroy the drive, it's valuable
<klys>
right on
<kazinsal>
geistvax: got bitchx working, I see
vdamewood has quit [Ping timeout: 264 seconds]
<geistvax>
nah this is still old ass ircII
<geistvax>
of course bitchx failed in a compile step like 2 hours in
<geistvax>
but unclear whats up
<AmyMalik>
¿
yoo has joined #osdev
<geistvax>
i am getting some sort of weird syntax error where there shouldn't be one
<geistvax>
so it's one of those is the compilertoo old sort of things
<geistvax>
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
<geist>
oh i think i see what it is. it's legacy C so you have to declare vars up front, etc
<klys>
sounds right
<geist>
the error is weird though, it just says syntax error in the middle of the declaration, so it took me a bit to figure out what it was
<geist>
but as a show of how slow it is, each gcc step for each .c file is taking upwards of 2 or 3 minutes
<klange>
pre-clang gcc error messages...
<geist>
and these are not that complicated files
<geist>
klange: yeah, it's been a while, forgot that they used to generally not be helpful at all
GeDaMo has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 256 seconds]
<Ermine>
is VAX noisy?
<AmyMalik>
what kind of vax?
<Ermine>
DEC VAX, not vacuum cleaners
<AmyMalik>
yes, I assumed you meant the DEC one
<zid>
I have a vax
<zid>
it is very noisey
<zid>
so I wasn't sure which
<AmyMalik>
zid, DEC, or vacuum?
<zid>
vacuum
epony has quit [Remote host closed the connection]
epony has joined #osdev
yoo has quit [Ping timeout: 264 seconds]
Cindy has quit [Ping timeout: 260 seconds]
<zid>
we need one more brand you can confuse for an OS
<zid>
so we can have "Vacuum cleaner & .. appreciation society" as the topic
Cindy has joined #osdev
vdamewood has joined #osdev
<AmyMalik>
I wonder if, if I ever write my sidecar thingy, I should name it after a vacuum cleaner
<GeDaMo>
Henry
<epony>
Hernio Kissginger.. is no more.
Left_Turn has joined #osdev
osmten has joined #osdev
<AmyMalik>
neh
<AmyMalik>
I was thinking something that could plausibly sound like bissell
zetef has quit [Remote host closed the connection]
zetef has joined #osdev
zetef has quit [Ping timeout: 276 seconds]
gabi-250_ has quit [Ping timeout: 240 seconds]
gabi-250_ has joined #osdev
mahk has quit [Ping timeout: 252 seconds]
yoO0Oo has joined #osdev
yoo has quit [Ping timeout: 276 seconds]
gog has joined #osdev
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
<mjg>
who is geistvax? is this the return of people fucking with their nicks? :(
<gog>
geistvax is geist on vax
* vdamewood
changes his nmae to vdamewoodmac
<vdamewood>
name*
mjg is now known as mjglsd
<mjglsd>
micro vax? i microdose lsd
<vdamewood>
gog: Does this mean you're now gognip?
<gog>
gogcaine
<vdamewood>
I prefer Pepsi over Coke.
* vdamewood
gives gog a fishy
<mjglsd>
i used to drink pepsi
<mjglsd>
i was always surprised by people claiming they don't see the difference to coke
<mjglsd>
[fwiw i recommend not drinking either, life fucking pro tip]
* gog
chomp fishy
<mjglsd>
chomp $_;
<mjglsd>
if you gonna perl you do it right
<mjglsd>
(for genz out there, chomp whacks newline from a string)
sebastiencs has quit [Read error: Connection reset by peer]
sebastiencs has joined #osdev
heat has joined #osdev
lzrd has joined #osdev
osmten has quit [Ping timeout: 250 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
goliath has joined #osdev
navi has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
uzix has joined #osdev
uzix is now known as mahk
CryptoDavid has joined #osdev
<heat_>
plus a myriad of crates i do not control
<heat_>
shit
<heat_>
wrong window
<zid>
RUST
<heat_>
RUST
<zid>
dw heat, that's why the 'correct' way to write rust
<zid>
is to clone the entire universe
<zid>
and maintain it yourself
<heat_>
.clone()
<heat_>
i'm trying to add back C support to my kernel
<heat_>
headerz
<heat_>
are annoying
<zid>
Isn't C support just
<zid>
there
<zid>
you have to work pretty hard to not C support
<gog>
#ifndef __cplusplus time
<heat_>
yes gog, most definitely
<gog>
the lesson is never write c++
<heat_>
#ifdef __cplusplus <blob of code i cba to convert to C>
<gog>
you need to rewrite onyx in c
<heat_>
ALSO
<heat_>
feel this hack
<heat_>
/* sigh... */
<heat_>
#ifdef __cplusplus
<heat_>
radix_tree vm_pages;
<heat_>
struct __dummy_radix
<heat_>
#else
<heat_>
{
<heat_>
void *ptr;
<heat_>
int order;
<heat_>
} __dummy_vm_pages;
<heat_>
#endif
<gog>
yikes
<zid>
heat what's for lunch
xenos1984 has quit [Read error: Connection reset by peer]
<heat_>
idk
<heat_>
mcrod, how do i send dua lipa gifs through IRC
<mcrod>
heat_ I immediately switched over to Textual because I had a feeling you'd ask me exactly this
<mcrod>
but yes this channel must be blessed with dua lipa
<gog>
dua lipa!
<mcrod>
gog i want a hug
edr has joined #osdev
* gog
hug mcrod
* mcrod
hug gog
xenos1984 has joined #osdev
<zid>
heat_: I made microwave pasta, because you were being obstinate
<heat_>
hrm
<heat_>
if you have two different struct definitions what happens to the DWARF when linking?
<heat_>
two different struct defs for the same name, that is
zetef has joined #osdev
zetef has quit [Ping timeout: 246 seconds]
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
SophiaNya has joined #osdev
ptrc has joined #osdev
zetef has joined #osdev
dude12312414 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
zetef has quit [Ping timeout: 256 seconds]
slow99 has quit [Ping timeout: 268 seconds]
epony has quit [Quit: QUIT]
CryptoDavid has quit [Quit: Connection closed for inactivity]
gog has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
epony has joined #osdev
gareppa has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<klys>
sounds right
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
<heat_>
>All fields in XFS metadata structures are in big-endian byte order
<heat_>
my day is ruined
<zid>
who let the psycopaths free
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 240 seconds]
<clever>
heat_: i discovered the hard way, the xfs journal, is in host byte order and linux has no way to byte-flip things
<clever>
so if you crash while on a BE system, only another BE system can replay the journal
<Mondenkind>
ooff
<Mondenkind>
do I want to know about 'hard way'?
<Mondenkind>
clever?
<clever>
zfs on the other hand, always writes in host byte order, including the magic#, and if it detects the magic is backwards, it will byte-swap on read
<Mondenkind>
do you have something to tell us?
<clever>
Mondenkind: there is a mount flag to just discard the journal and not perform recovery
<clever>
in my case, i was using a sparc machine as a nas
<sham1>
Oh, so zfs has BOM
<clever>
and one day, it just stopped booting
<heat_>
clever, yep, noticed on the docs that the log has "big-endian linux" and "little-endian linux" formats
zetef has joined #osdev
<heat_>
oh, and here's a funny detail: XFS uses -1 for NULL values
<heat_>
>struct xfs_trans_header
<heat_>
struct xfs_🏳️⚧️_header
<zid>
-1 for null makes a lot of sense ngl
<zid>
0 is a very valid value a lot of the time
zetef has quit [Ping timeout: 256 seconds]
<Mondenkind>
MAP_FAILED is -1 usually
<clever>
since it may be valid to mmap to 0
<Mondenkind>
yeah
<Mondenkind>
(for some reason iirc on linux at least you have to be root to map 0?)
<zid>
needs a CONFIG_ too i think
<clever>
makes null-ptr's very hard to catch
<Mondenkind>
yeah but
<clever>
ive heard darwin just bans the lower 4gig entirely, so if you truncate a pointer to 32bits, it must fault
<Mondenkind>
if i wanna map null, isn't that my own business?
<heat_>
you need a CONFIG_ and a sysctl
<heat_>
Mondenkind, no
<heat_>
many archs don't have protection for the supervisor accessing user memory
<heat_>
like x86 pre ivybridge or whatever
<clever>
oh, yikes, kernel null ptr, reading user data!!
<heat_>
given 64-bit's yuuuuuuge address space, i advocate for reserving a huge chunk of that lower part
netbsduser has joined #osdev
<heat_>
i do IIRC 4MiB on x86
<heat_>
but riscv and arm64 toolchains default to 0x10000 executable base addresses so i had to lower it for them
<Mondenkind>
I think 4g is ~reasonable
<Mondenkind>
although one annoying thing is
<nortti>
iirc os x does that on 64-bit
<heat_>
4G is not reasonable because you might need it for compat
<Mondenkind>
I started doing a translator/compatibility thing for 32-bit mac binaries, and having to offset all pointers kinda sucked
<Mondenkind>
vs being able to just MAP_32BIT them
<heat_>
yes
<Mondenkind>
yeah exactly
<clever>
heat_: ive also sudgested the reverse for rpi compat, MAP_32BIT
<clever>
but i think that flag doesnt work on arm
<clever>
the firmware has 32bit slots for opaque tokens it returns to userland
<clever>
and userland uses them as pointers to userland state
<zid>
I think I should make <512GB a null pointer
<heat_>
>This flag is supported only on x86-64, for 64-bit programs
<clever>
MAP_32BIT would map them to the lower 4gig, and then no truncation
<clever>
heat_: yeah, its missing from aarch64
<heat_>
fwiw there was that performance regression in sapphire rapids coming from the distance between the interpreter/shared libs and the executable
<heat_>
that glibc fixed in ld.so using MAP_32BIT
<Mondenkind>
I dunno rpi, but on my arm server running freebsd map_32bit works fine
<heat_>
someone's running freebsd??
<Mondenkind>
it scales perfectly to both of my cores
<Mondenkind>
i could even run openbsd
<Mondenkind>
also idk zfs or something
<clever>
Mondenkind: MAP_32BIT is a linux (and i guess freebsd?) extension ontop of posix, depending on which `man mmap` you open, the flag may not even exist
<clever>
that gaslit me for a few weeks, because i could swear i saw it in the man page, yet its gone now, lol
<clever>
`man 2 mmap` has it, `man 3 mmap` doesnt
<clever>
and `man mmap` defaults to 3
<heat_>
yes
<heat_>
3P man pages are somewhat useless
<Mondenkind>
you know what I love
<Mondenkind>
if I'm looking at a c file in vim and I hover over a 'read' and hit K to see a man page
<Mondenkind>
I'm hit with--not even read(3p), but read(1)
<clever>
lol
lzrd has quit [Remote host closed the connection]
<mcrod>
dua lipa
<clever>
Mondenkind: next time its 3am, try asking linux, `whatis sleep`
<Mondenkind>
dua lipa
gog has joined #osdev
<heat_>
gog, dua lipa
<gog>
dua lipa
xenos1984 has quit [Ping timeout: 260 seconds]
yoO0Oo has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
lzrd has joined #osdev
lzrd has left #osdev [#osdev]
gareppa has quit [Quit: WeeChat 4.0.5]
<geistvax>
mjg: on the vax!
<geistvax>
the vaxserver 3800 is doing double duty as a irc client and a 300W space heater
<mjglsd>
irc?
<mjglsd>
what are you running there again?
<heat_>
NetBSD 1.5.4_ALPHA :ircii 2.9: AT&T you will (ojnk!)
<heat_>
1.5.4 being some unreleased version? did the build system increment that for you?
<geistvax>
build system incremented it. i rebuilt the kernel on the tip of the 1.5 branch
<geistvax>
1.5.3 was the final release AFAIK
<heat_>
netbsd 1.5.4 is stored alongside the aliens over at area 51
<Ermine>
what's wrong with xfs endianess?
<heat_>
its big endian
<clever>
so every access involves a cpu overhead to byte-swap
<heat_>
i mean, no, because that's a horrible idea
<netbsduser>
not on my amiga it won't
<heat_>
btw that's remarkably C++, clever
<heat_>
struct xfs_inode { big_endian<uint32> i_mode; } and then every access requiring an implicit byteswap
<Ermine>
clever: assuming that your cpu is little endian. Which is probably the common case, but not all processors are LE
<clever>
netbsduser: i believe all arm chips can byte-swap automatically
<clever>
i mean, switch on boot
<Ermine>
heat_: why it's horrible?
<clever>
so you can just flip a control register, and your arm is now BE
<clever>
i have build linux in arm BE mode before
<clever>
and another guy even booted such a thing on the rpi
<clever>
all of the drives then immediately barfed :P
<Ermine>
armel
<clever>
because the registers are LE
<clever>
drivers*
<heat_>
Ermine, because arm64, x86, x86_64, riscv are all either bi-endian or little endian
<clever>
emu68 is also a neat project, its an aarch64 BE kernel, that will JIT m68k asm into aarch64 asm
<clever>
and because its BE, it can just run without byteswaps
<heat_>
i guess ppc is mostly big-endian
<geist>
meh a data structure that's big endian isn't hard to deal with with modern cpus
<Ermine>
heat_: ah, so basically what clever said
<geist>
they all have byte swapping instructions, lost in the noise
<clever>
netbsduser: and then with an mmu trap, you can re-direct a certain IO window to the amiga databus, and just plug a pi3 right into the cpu socket
<heat_>
geist, yeah but you want to avoid the bswap if possible
<heat_>
and that brings extra overhead
<heat_>
such as allocating a copy of the data
<geist>
yah but on modern machines the superscalar scheduling of that *probably* makes it lost in the noise
<heat_>
(and swapping once in place)
<geist>
PPC i always thought did it kinda nicely: they have a load/store swapped instruction
<geist>
so you can swap it as you load it into a register
<heat_>
recent x86 does too
<heat_>
see movbe
<clever>
arm32 also had a `setend` opcode, that would change what load/store does
<clever>
but ive also heard of that causing problems, when its in the wrong mode
<clever>
so you could just flip it into BE mode, load everything, then flip back to LE mode
<geist>
yah that's common. riscv has BE mode too,but that tends to happen at the process level at the smallest
<geist>
hmm, yea i guess you could do that, swap temporarily
<heat_>
that doesn't work unless the compiler's aware of it, which i bet they aren't
<heat_>
probably a nightmare for signals and interrupts of any kind too
<geist>
yah i think the BE gets set back in an exception, but would have to be restored, etc etc
<geist>
the BE flag is part of CPSR/PSTATE at least
<geist>
in riscv it's part of sstatus so i dont think user space can get access to it, so it'd have to be a process by processs thing
<clever>
i already heard of valgrind breaking, because it hooks random functions, and isnt expecting the cpu to be in BE mode
<geist>
the canonical reason to run arm in BE mode is some ported networking app that expects to be in BE. I dont know if as much stuff does it now, but a few years back when lots of networking gear generally was transitioning off PPC onto ARM i think it was super common to just run it in BE so the already existing code didn't have to get byte swaps added, and faster at that
<geist>
nowadays, good question if explicit swaps matter much performance wise
<geist>
i posit they probably dont, unless you're really dealing with super high speed stuff (10gb+)
<clever>
zfs kind of dodges the problem, by always using host byte order, but supporting byte-swap on read
<clever>
so both BE and LE can avoid the problem, if the data never migrates
<heat_>
wait geist, isn't riscv little-endian?
<clever>
(ignoring a few datastructures that are always BE or LE)
<geist>
yah BeFS I remember doing that too: had a flag in the superblock that said what the endian was
<geist>
heat_: there's a endian bit in sstatus
<clever>
for zfs, its a per-record flag, rather then fs wide
<geist>
like ARM it's nativey LE, in the sense that the instructions are always encoded LE
<geist>
and the BE flag only really affects load/stores
<clever>
would the page tables then have to be in LE?
<geist>
hmm,that's a good question, i forget
<heat_>
no toolchain does BE riscv right?
<geist>
also i forget if riscv only lets you do BE in user mode, or if there's a mstatus register that also affects supervisor mode
<heat_>
i've never seen one of those targets at least
<heat_>
there's an mstatus bit
<geist>
that affects supervisor mode?
<clever>
arm32 i think lets any mode call `setend`, while i think aarch64 only lets you change it via `eret`
<clever>
so you need permission from a "higher power"
<geist>
yah i think that's what i remember, i forgot about setend, but haven't done much arm32 lately
<heat_>
ah, the bi-endian stuff was added in 20211203
<heat_>
it's also optional, like most of riscv
<geist>
kk
<heat_>
riscv is death-by-extension
<geist>
yeah tell me about it. we're just now adding the extension parsing stuff to zircon, since it's pretty hard to tell what the direction is
<geist>
but eventually had to settle on just parsing the shit out of it into a bunch of bits
<geist>
since that seems to be the direction linux is going in, warts and all
gbowne1 has joined #osdev
<heat_>
yeah
<heat_>
i'm still doing a feature bitmask where extension_letter - 'a' represents the extension
<heat_>
because i haven't parsed the actual ""new"" extension stuff
<heat_>
with the uppercase letters and all that
<geist>
yeah those are not too bad: a) i think the upcase is irrelevant and b) they're all separated by _
<geist>
so it *should* be just basically a strtok on _ and then string match
<bslsk05>
github.com: Onyx/kernel/include/onyx/cpu.h at master · heatd/Onyx · GitHub
<geist>
what is annoying is i've sometimes seem versions encoded in the strings
<geist>
like zbav1 or something, like that
<geist>
which would foul up a trivial strcasecmp
<heat_>
but these mappings make somewhat more sense because i'm just mapping cpuid leafs into a bitmask
<geist>
dunno if those are legit, or documented
<geist>
yeah we're basically doing the same with riscv, and starting to add to the table
<geist>
i feel mixed about it, because it means unless the kernel knows about an extension user space can't see it, but nothing keeps us from also passing the original string through to user space
<geist>
i thin khat's effectively what linux does: it passes the bitmap it curated via aux[] and then you can get to the raw string in /proc/cpuinfo
<geist>
and i think it's still TBD what most user code that's riscv aware will do with those two pieces of info
<heat_>
yep
<heat_>
and there's the new syscall
<heat_>
riscv_hwprobe
<geist>
so i think we'll add a vdso call that just reads the array out of the vdso's data segment
<geist>
that way you get a fast call to check for a feature
<geist>
looks like a syscall but happens in user space
<heat_>
yeah that makes sense
<heat_>
the annoying part is "what if the harts are heterogeneous" which seems to be accounted for specifically in riscv_hwprobe
<heat_>
which makes me wonder if this is actually going to be a thing...
<geist>
yah i think our bitmap thing we're going to try to account for it by essentially intersecting all of the features across all cores
<geist>
unclear if that's a good idea long term
<heat_>
also fyi the linux ELF hwcap is somewhat useless
<heat_>
(on riscv)
<heat_>
the hwcap seems to expose only single-letter extensions at best, at worst it only exposes IMAFDCV
<adder>
Sorry if this is personal, but I'd like to know whether any of you works on kernels for a living?
<netbsduser>
not i
<adder>
I suppose what I'm trying to get at is, are there any jobs out there where you get to work on kernels, that don't involve fine-tuning Linux, or whatever?
<netbsduser>
there are still OS research labs at some unis
<netbsduser>
or you could work for microsoft or apple (if it must be a general purpose operating system whose kernel you work on)
<adder>
I see.
<heat_>
go to india and work on the great IBM AIX
<netbsduser>
i think that's where solaris is maintained nowadays
<heat_>
i'm pretty sure solaris still has at least some US people on it
<netbsduser>
alan coopersmith will work on it as long as he lives
<heat_>
yeah exactly alan
<netbsduser>
i wonder what the last great work on the kernel was
<netbsduser>
the VM2 project was completed but i struggled to find much information about what it involved
<heat_>
what's vm2?
<netbsduser>
it was the looming massive refactoring and enhancement of the solaris virtual memory subsystem which was previously discussed when opensolaris was around
<netbsduser>
and according to jonathan adams' resume, it looks like it made it into a concrete project which was carried out in full
<netbsduser>
i can see it involved rewriting the resident memory manager to more effectively deal with NUMA and big pages; "intimate shared memory"; async rwlock acquisition was involved; and better swap and memory reserve accounting
<netbsduser>
i can't see any more but i understand it was a truly large undertaking
<netbsduser>
and of course it involved the integration of ZFS so that the duplication of pages between the primary page cache and the ARC was abolished
<heat_>
god why is the root inode for xfs *dynamic*
<heat_>
mkfs.xfs picked 128 for a root inode
<heat_>
blasphemy
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
yoo has joined #osdev
<sham1>
What's wrong with big endian, bts
<sham1>
btw*
<bl4ckb0ne>
what isnt wrong with big endian
<sham1>
Big endian is more human-friendly
<netbsduser>
in the original arabic numbers are little endian
<netbsduser>
since you write from right-to-left in arabic
<netbsduser>
so in urdu, persian, hebrew, arabic, syriac etc countries we ought to promote little-endian, but in places using the latin, cyrillic, and other left-to-right alphabets, big-endian computers are more appropriate
<nortti>
indic scripts are left to right tho, no?
dude12312414 has joined #osdev
zetef has joined #osdev
zetef has quit [Read error: Connection reset by peer]
zetef has joined #osdev
<vdamewood>
sham1: Serious answer, most of the modifications of values happen in the lower-order bits, for example incrementing and decrementing. With little endian, a pointer to a value is also a pointer to the least-significant bits. You can increment just the one byte without having to do memory address math.
<sham1>
That's just a trade-off
<vdamewood>
Trading for what?
<sham1>
For the more human-friendly ordering
<vdamewood>
Why make something human friendly if humans don't touch it?
<sham1>
I do like little endian more, but I don't think that there's anything wrong with BE as such
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
<Cindy>
big endian is bad because it's big
<Cindy>
little endian is just average
<Cindy>
i think
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 256 seconds]
<nikolar>
Cindy: why average, shouldn't it be little
<Mondenkind>
Perhaps, but it's rude to say so!
<nikolar>
heh
netbsduser has quit [Ping timeout: 252 seconds]
zetef has quit [Read error: Connection reset by peer]
<kof123>
the alchemy answer is eggs are all "double" anyways :D so...which end is bigger is not really a concern...
<kof123>
for the young people > In Jonathan Swift's Gulliver's Travels (1726) the Big-Endians are a group of people in Lilliput who believe that boiled eggs should be broken at the big end rather than at the little end
<geist>
well, it's at least not mid
<gog>
you're not mid
<gog>
you're bussin on god fr
<gog>
no cap
epony has quit [Remote host closed the connection]
epony has joined #osdev
Brnocrist has quit [Ping timeout: 264 seconds]
<nikolar>
gog: why did you do that
<gog>
what
<epony>
netbsduser(off), the direction of writing has nothing to do with that, clueless noob peon peasantry explanation of nothing
<epony>
it's about data serialisation and memory access to it and processor nibble alignment, nitwib dimbit lowquality unedicated guesswork of a silly
<epony>
and is about performance computing being big endian and networking transit being little endian as optimisation strategies, not anything else
<epony>
such a stupid guess
<epony>
now don't start guessing RISC is about rediced penis length either
<epony>
dimwit
<epony>
and of course, it would not be interesting if we don't tell you the opposite of reality either ;-)
<epony>
the successful mini- and mirco- computing systems lines (entirety) are CISC little-endian least significant first, most significant last in memory ordering, so overstep damages the small parts of numbers, not the entire number order
<epony>
for network is the opposite, the most critical part of the larger mantissa of the number goes first, and the small parts of the data in the last bits order, so an interrupt loses the small parts at the end
<epony>
that's the idea
<epony>
RISC computers started the opposite convention mostly big endianness first (for microcontrollers and embedded computing and memory bursts optimisation strategies), and later turned little- and bi-endian (both supported)
<epony>
it's not listed in the word size table per machine but would be an embarrassment to see how little the big-endianness was used in computing
<epony>
teaching starts with the 8bit computers and their least significant data first ordering in memory to teach kids about the data organisation and reversal of the nibbles and data overstepping and buffer overflows
<epony>
it reflects the most common choice in the generally programmable microprocessor machines epoch
<epony>
so, find people who write from the bottom up putting the least important info at the bottom part of the sheet of paper and move upwards, and then left to right column, pivot to paper 90° clockwise right, and you get big endian that works