<bslsk05>
www.globenewswire.com: Server Operating System Market to Worth More than US$ 43.35
gog has quit [Ping timeout: 244 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
surabax has quit [Quit: Leaving]
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
the_oz has joined #osdev
<kof673>
niko lar: https://0x0.st/s/xZVuCbwWdUqSM80xnYaWMw/8ATK.txt dev86/bcc elks linux86 binaries...you get a nice large comfortable 64k for malloc() to play with. 32-bit long looks like ;D -Mf optimization flag produced binaries that elksemu at least did not like, -Mc works
<kof673>
i assume that means 64k max code size too lol
<Matt|home>
o\
<kof673>
*nice large comfortable spacious breathtaking views
bradd has quit [Read error: Connection reset by peer]
Velonie has joined #osdev
HD36079 has joined #osdev
bradd has joined #osdev
Velonie has quit [Ping timeout: 246 seconds]
Velonie has joined #osdev
<geist>
heat took er jerb
bauen1 has quit [Ping timeout: 244 seconds]
<araxestroy>
terkajerbs!
cow321 has quit [Ping timeout: 252 seconds]
cow321 has joined #osdev
bauen1 has joined #osdev
Velonie has quit [Ping timeout: 246 seconds]
craigo has joined #osdev
Velonie has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
Lucretia has joined #osdev
sskras has quit [Ping timeout: 244 seconds]
x64S has quit [Quit: Leaving]
sskras has joined #osdev
kkd has quit [Ping timeout: 272 seconds]
kkd has joined #osdev
netbsduser` has quit [Ping timeout: 272 seconds]
netbsduser` has joined #osdev
levitating has joined #osdev
zid has quit [Remote host closed the connection]
Velonie has quit [Ping timeout: 252 seconds]
Left_Turn has joined #osdev
fedaykin has quit [Ping timeout: 252 seconds]
fedaykin has joined #osdev
GeDaMo has joined #osdev
Velonie has joined #osdev
hwpplayer1 has joined #osdev
zid has joined #osdev
zid has quit [Remote host closed the connection]
osmten has quit [Quit: Client closed]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
zid has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
Velonie has quit [Ping timeout: 248 seconds]
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
gorgonical has quit [Ping timeout: 252 seconds]
Velonie has joined #osdev
ZipCPU has joined #osdev
hwpplayer1 has joined #osdev
Velonie has quit [Ping timeout: 272 seconds]
Velonie has joined #osdev
nihal has joined #osdev
HD36079 has quit [Ping timeout: 260 seconds]
xvmt has quit [Ping timeout: 276 seconds]
Velonie has quit [Ping timeout: 260 seconds]
the_oz has quit [Ping timeout: 252 seconds]
xvmt has joined #osdev
HD36079 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
Velonie has joined #osdev
nihal has quit [Ping timeout: 252 seconds]
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #osdev
xenos1984 has joined #osdev
edr has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
heat_ has joined #osdev
hwpplayer1 has joined #osdev
bauen1 has joined #osdev
Velonie has quit [Ping timeout: 248 seconds]
Turn_Left has joined #osdev
levitating has quit [Remote host closed the connection]
Left_Turn has quit [Ping timeout: 244 seconds]
Velonie has joined #osdev
leon has quit [Ping timeout: 248 seconds]
leon has joined #osdev
HD36079 has quit [Quit: Leaving]
stolen has joined #osdev
goliath has quit [Quit: SIGSEGV]
<PublicWiFi>
vfs abstraction with drivers is a lot easier to wrap my head around than with disks
<PublicWiFi>
because disks require the filesystem driver middle man
<PublicWiFi>
so now I'm trying to figure out what the filesystem driver should be in charge of, should it handle selecting sectors and such?
<heat_>
no they don't
<PublicWiFi>
wat
<heat_>
do you mean disks as in "on-disk filesystems"
<PublicWiFi>
i mean disks and physical disks sorry
<PublicWiFi>
vfs to driver/dev abstraction is relatievly straight forward
<heat_>
that tells me nothing
<PublicWiFi>
but with a physical disk you gotta interact with a filesystem driver, so I'm trying to figure out what exactly the filesystem driver should do
<heat_>
do you mean disks as in "on-disk filesystems"
<PublicWiFi>
yes... i think?
<heat_>
/dev/sda != /bin/bash
<PublicWiFi>
vfs -> file system driver -> actual physical disk driver
<PublicWiFi>
if i wanna open a text file on disk, i have to go through that workflow
<PublicWiFi>
its the extra layer of abstraction that's getting me down
<heat_>
ok so what's the hard part
<heat_>
you know how an on-disk fs works right?
<zid>
sda != bash!?
<PublicWiFi>
I am writing a fat16 driver from scratch
<PublicWiFi>
trying to figure out what the file system driver should/should not be responsible for exactly
<zid>
yea where each thing's responsibility starts and ends isn't super trivial to decide in a vacuum
<heat_>
ok. so make open open a file, read read a file, write write to a file
<PublicWiFi>
zid+++
<zid>
best way is just to have two of everything and push down the shared bits
<zid>
:D
<PublicWiFi>
lol
<zid>
your caches end up inside the right files then
<PublicWiFi>
the physical disk driver seems pretty straight forward
heat_ is now known as heat
<zid>
yea because it just cares about taking reqs and delivering results
<PublicWiFi>
i guess anything outside of standard syscall should be file system driver responsiblity
<PublicWiFi>
send() == vfs, anythign above bare metal should be file system I guess
<PublicWiFi>
lol
<PublicWiFi>
do this mean the file system will interact directly with the disk??
<zid>
fs on top cares about.. mapping file reads to read requests, vfs on top cares abuot mapping strings to files
<heat>
most standard system calls are largely the fs driver's responsibility
<zid>
roughly
<PublicWiFi>
so the file system will call disk drivers?
<heat>
yes
<PublicWiFi>
okok
<PublicWiFi>
that helps
<PublicWiFi>
so as long as my physical disk drivers are standardized (they are) then it should be easy to use another FS in the future
<PublicWiFi>
my disk drivers follow a character device struct pattern like all of my drivers
<heat>
in linux you as the fs need to implement a bunch of callbacks which may or may not be shared code
<heat>
this is the most flexible approach
<PublicWiFi>
so it actually has a read() write() ioctl for sector selection and etc
<heat>
the only thing you dont implement directly is open(), you implement a lookup() that opens path segments
<PublicWiFi>
so the file system will just do a search
<PublicWiFi>
then return that data, then the vfs will call open?
<PublicWiFi>
ok wait
<PublicWiFi>
lets say I open a file, vfs calls open()
<PublicWiFi>
file system searches and do the thing
<PublicWiFi>
eh
<PublicWiFi>
abstraction melts the brain man
<PublicWiFi>
xDDD
<PublicWiFi>
ok so open() is called, vfs will ask fs to seek and find the file, then that data is saved in the fd file?
Left_Turn has joined #osdev
<heat>
yes, that's how a vfs works
<PublicWiFi>
the meta data i mean
<PublicWiFi>
yeah I'm just trying to figure out the physical disk abstraction specifically
<PublicWiFi>
idk why but the file system really has my brain melting lol
<heat>
you have a struct file which is the fd-specific stuff, then a struct inode which is vfs-specific inode data, then filesystems might have their own struct ext4_inode_info { struct inode ino; /* buncha other shit */ }
Velonie has quit [Ping timeout: 272 seconds]
Turn_Left has quit [Ping timeout: 245 seconds]
<PublicWiFi>
structs in structs in structs
<PublicWiFi>
META
<zid>
well ofc
<zid>
we're three abstractions deep
<PublicWiFi>
:P
<zid>
so you'd expect three structs
<PublicWiFi>
3 abstractions isn't enough
<PublicWiFi>
we. must. go. deeper.
<zid>
make yourself a sector struct then
<PublicWiFi>
but you know this is reallying helping me undersstand *nix more lol
<zid>
and a request packet
<PublicWiFi>
as a sysadmin I'm ashamed I didn't know a lot of this already
<zid>
command queue full of packets
<zid>
command queue list for handling multiple queues
* PublicWiFi
looks at his 64K RAM max with 16K pages
* PublicWiFi
makes sad memory noises
<zid>
That's your punishment, rather than our problem
<PublicWiFi>
i will need some queue buffers later though for thread messages.. something else I know jack shit about
<PublicWiFi>
I literally dont know shit about any of this, its been painful and fun to learn
<PublicWiFi>
esp on hard mode, which idk why I do this to myself
<PublicWiFi>
i built this shitty z80 backplane and cards and though "i should make a "modern-ish" OS"
<heat>
PublicWiFi, dude i skipped like 3 or 6 indirections
<PublicWiFi>
and here I am, harassing you fine folks
<zid>
I added a few more back in dw
<zid>
next we have to go from the other end, things above files
<PublicWiFi>
I _could_ skip all of this and build it in a way that's highly specific to my hardware
<heat>
and im missing a few other structs i dont know about
<PublicWiFi>
wat
<zid>
what what?
<PublicWiFi>
thousands of what
<zid>
You can't have symlinks, and mount points, and permissions, and ...
<zid>
unused
<PublicWiFi>
symlinks are a pipe dream man
<PublicWiFi>
ill be lucky to have a working shitty ls
<PublicWiFi>
lmao
<zid>
so you're going to HAVE to stub a lot of things out with comments saying this is where they WOULD go, if we had them
<zid>
thousands of things, compared to posix
<PublicWiFi>
oh
<PublicWiFi>
well this isn't gonna be totally POSIX compliant
<PublicWiFi>
its gonna be posix-lite
<zid>
yes
<PublicWiFi>
:D
<zid>
it's not even going to approach that
<zid>
so you're going to HAVE to stub a lot of things out with comments saying this is where they WOULD go, if we had them
<PublicWiFi>
oh I see what you're saying
<PublicWiFi>
but I'm not gonna bother
<heat>
practically speaking you can't have a POSIX compliant nommu system
<PublicWiFi>
lmfaoooo
<PublicWiFi>
I have an MMU
<heat>
oh ok
<zid>
does bank switching count as an mmu
<PublicWiFi>
its custom hardware that can do 4 pages of 16k :D
<zid>
Are you planning on running more than 4 processes?
<PublicWiFi>
but there's no kernel protected mode or anything, im raw dogging my kernel
<zid>
If yes, we're back to "nommu" imo
<PublicWiFi>
I am aiming for like maybe 8 processes max
<zid>
because you're going to have to break all the abstractions an mmu provides in order to achieve it
<PublicWiFi>
why tho
<zid>
because.. that's what an mmu is used for?
<zid>
isolation and abstraction
<PublicWiFi>
i could just have a bigass table to keep up with what process is where
<PublicWiFi>
the bottom 16K will prolly just house kernel
<zid>
you could implement 4 processes as though they had a 'real' mmu using your 4 bank bank switcher
<PublicWiFi>
but i haven't decided yet
<PublicWiFi>
I also haven't decided if i want to use the paging yet
<PublicWiFi>
I have like 512KB ram on board though so it woul dbe nice
<zid>
but if you go above 4 you'll have to not use the bank switcher in the manner where it's analogous to an mmu
<PublicWiFi>
i see
<PublicWiFi>
OH you're saying for virutal memory
<PublicWiFi>
and each process having it own virutal block?
<PublicWiFi>
like modern systems?
<zid>
yea you could just stick each process in one bank
<zid>
the other bank is kernel/shm
<PublicWiFi>
yeah I get cha
<zid>
and then you could do a 'classic' system
<zid>
basically identical to segmented x86
<PublicWiFi>
yeah i haven't got that far yet
<PublicWiFi>
I just figured it would be "cool" to have daemons n shit
<PublicWiFi>
xDDD
<PublicWiFi>
abstract the network layer to a network daemon to keep up with and etc
<PublicWiFi>
significantly slowing down my poor system but its for fun amirite
<PublicWiFi>
honestly, I only added the "MMU" as a future proof thing
<PublicWiFi>
I think my first major builds will justbe on the flat 64K
<PublicWiFi>
my bootloader currently just sets the MMU to be a contiguous 64K so it acts like a classic system
<PublicWiFi>
it sets it all to 64k contiguous, then copies the bootloader to RAM and kills the ROM
Velonie has joined #osdev
<PublicWiFi>
anyways sorry for the spam, and thanks for the sanity check as always
<PublicWiFi>
so wait 1 more thing
<PublicWiFi>
just for one last sanity check
<zid>
7
<PublicWiFi>
so on boot the disk will be registered to the vfs (/dev/sda) and given a fd
<PublicWiFi>
then when the file system is mounted, itll have its own fd
<heat>
no
<PublicWiFi>
oh
<PublicWiFi>
ok
<PublicWiFi>
lol
<heat>
why would the disk be given a fd?
<PublicWiFi>
i dunno
<PublicWiFi>
how else would the vfs interact with it
<PublicWiFi>
(genuine question man)
<heat>
structs.
<heat>
you should read unix v6 source code
<heat>
it's literally as adhoc as you need to be in low memory situations
<heat>
no fancy abstractions
craigo has quit [Ping timeout: 260 seconds]
<kof673>
buried deep in the unix source code, a lone comment: /* rawdogging it */
<heat>
no abstractions no safety just rawdogging some kernel code
<PublicWiFi>
lol kof673
<PublicWiFi>
i love C dont get me wrong
<PublicWiFi>
but when i go to look at massive C projects it makes me sad cause there's always 1000000 header and 100000 c files
<PublicWiFi>
and i pretty much have to clone the repo so i can click through
<PublicWiFi>
xD
<PublicWiFi>
zid: you know why couldn't i just add the MMU state to my thread struct? so when context switches I can save the MMU config there and make it completely transparent
<PublicWiFi>
though my ignorance is shining i bet
<PublicWiFi>
lol
<heat>
fuck do you mean
<PublicWiFi>
bro
<PublicWiFi>
have you not noticed I'm a dumdum
vdamewood has joined #osdev
<PublicWiFi>
idunno why i specified C up there
<PublicWiFi>
large projects are hard to follow sometimes without really having to sit and dig in
<PublicWiFi>
since there's so many seperate files and headers n stuff
<PublicWiFi>
for your layman like me
<heat>
im talking about the mmu thread state thing
<PublicWiFi>
oh
<PublicWiFi>
> fuck do you mean
<PublicWiFi>
not even I know man
<PublicWiFi>
not even I know
<heat>
what
<PublicWiFi>
i feel like im in a fever dream when im working on OS dev stuff
<PublicWiFi>
xDDD
<heat>
1) make a suggestion
<PublicWiFi>
lets just forget I mentioned that and move
<PublicWiFi>
lmfao
<heat>
2) *someone asks what they mean*
<heat>
3) idk
goliath has joined #osdev
<heat>
4) ????
<PublicWiFi>
heat: well he said I couldn't do more than 3-4 posix threads with my current mmu
<PublicWiFi>
but if i switched the banks on every context switch I think I could
<PublicWiFi>
if i keep up with the current bank on the thread when switching I could switch transparently everytime
<PublicWiFi>
but that's not something I want to explore for a long, long time
<PublicWiFi>
ok.. sorry
<PublicWiFi>
im done flooding for now I think :D
<heat>
well the problem is that if you have 4 16K banks (and 64K of memory) then you're fucked
<heat>
you have to pick one out of 4 16K banks for a process
<heat>
you pretty much have no mmu
<PublicWiFi>
yeah true
<PublicWiFi>
in the future I can adjust my circuit to do 8k or lower pages
<heat>
8k is still too stupidly large
<PublicWiFi>
but for now im just gonna get this running on a flat 64k and do banks later
<heat>
you have 64K of memory
<PublicWiFi>
no you're def right lol
<heat>
a more appropriate proper page size is like, 512 bytes
<heat>
even then you'll only have 128 pages
<PublicWiFi>
I plan on implementing a simple malloc() and etc, which will be easier on a flat 64k as well.
<PublicWiFi>
addingin the MMU would make that more complex for me haha
<PublicWiFi>
anyway, the banking thing is like last on my list to figure out at this moment in time
<heat>
anyway as-is you're kind of fucked UNIX-wise
<heat>
better pull out your lions commentary on v6 and do actual process swapping to disk
Velonie has quit [Ping timeout: 265 seconds]
<PublicWiFi>
im ok with making this the most bare bonus shitty unix-like OS ever
<PublicWiFi>
im mostly just trying to learn the concept of the various abstraction layers
<PublicWiFi>
concepts*
<heat>
dude im basically telling you this won't work at all
<heat>
if you want to learn UNIX or learn good solid OS concepts doing an OS for the barest bones shit out there is just... not really the way to go
Velonie has joined #osdev
<nortti>
PublicWiFi: is 64K of memory your address space or your RAM size?
<nikolar>
heat: fun fact, pdp-11 had 8k pages
<nikolar>
64k is too limiting of an address space, you don't get much from smaller pages
<heat>
nikolar, and thaaaaaaaaaaaats why it was nommu
<nikolar>
what
<heat>
unix was nommu
<heat>
hth
<nikolar>
pdp-11 had an mmu, and unix used it
<nikolar>
what are you talking about
<heat>
they had to emulate an mmu with actual paging dude
<nikolar>
??
<heat>
??? what
<heat>
fork()
xenos1984 has quit [Ping timeout: 268 seconds]
<heat>
they swapped out processes to disk
<nikolar>
> heat | they had to emulate an mmu with actual paging dude
<nikolar>
if you have paging, you have an mmu
xenos1984 has joined #osdev
<nikolar>
i don't know what you're trying to say
<heat>
paging as in "writing out a process to disk"
<zid>
dw nobody does
<nikolar>
then say swapping
<nikolar>
or something
<nikolar>
and again, pdp-11 had an mmu
<nikolar>
i don't know why you'd emulate something you have
<heat>
because it was fucking useless
<nikolar>
they had an mmu
<nikolar>
there was no emulating
<nikolar>
i don't know what you're trying to say
<zid>
I think he means
<zid>
they didn't use the mmu, and ran a nommu config
<zid>
but he's being weird
<nikolar>
they did use an mmu though
<heat>
thank you.
<zid>
by claiming that nommu means "emulating" an mmu
<nikolar>
that's a very dumb way to say that
<zid>
it is yes
<nikolar>
and it's also wrong, unix did use the pdp-11 mmu
<heat>
for what?
<nikolar>
and could access up to 4mb of ram
<nikolar>
which you can't with the nommu pdp-11
<nikolar>
heat: for everything?
<heat>
it's all fun and games until you realize they literally wrote everything to disk on a context switch
<nikolar>
heat what unix are you talking about
<heat>
v6
<nikolar>
there's literally no reason why they would've done that if they had more than 64k of ram or something
<nikolar>
and also, even if they did do that, that's not emulating an mmu lol
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
<PublicWiFi>
nikolar: 64K address space, RAM size is technically 512KB but i'm going to just run it as 64k contiguous for now
<PublicWiFi>
until I can wrap my head around simple OS design and get something going lol
<nikolar>
so you get, what, 8 processes
<nikolar>
tops
<PublicWiFi>
i currently have 16k banks
<PublicWiFi>
but I think I will change my circuit to do more banks
<PublicWiFi>
at a smaller size
<PublicWiFi>
probably 2k or 10k
<PublicWiFi>
1k*
<PublicWiFi>
but meh on that for now
<PublicWiFi>
8 threads is my long term goal though :)
gog has joined #osdev
<PublicWiFi>
I gotta nail down my simple vfs before I do anything lol
<PublicWiFi>
i think my current hang up is defining my file system driver's responsibilities
<PublicWiFi>
and what functions I will need from it
<PublicWiFi>
basically I guess itll need, open, read, write, ability to make new files/dirs, ability to delete files/dirs
<PublicWiFi>
and to drill down, reading files would ofc mean the ability to follow the file parts across the filesystem using the pointers/linkedlist/whatever
<PublicWiFi>
same for writing and etc
<PublicWiFi>
ok enough flooding for now lol
<nortti>
heat: the system we have in question here has the process-visible address space of 64K split into four 16K banks that can be switched to point to wherever in the 512K physical RAM. you can have every one of your processes think they have the memory from 0 to 32K, by having the kernel swap out the mappings for the two lowest segments when you switch to a task (this is what PublicWiFi meant by MMU state in
<nortti>
the thread struct)
<nortti>
while this doesn't get you memory protection (interestingly enough, there is a way to get that with z80 too, https://www.youtube.com/watch?v=DLSUAVPKeYk) you do have the mapping part, so I don't see how this is a no-mmu system
<heat>
one process takes the whole of 32K (or 16K)
<heat>
if you have 64K of memory, you're screwed
<PublicWiFi>
ok the way I picture it is that when context switching the kernel can set the MMU page to the correct page, then once the stack pointer is restored wouldn't it just run?
<PublicWiFi>
as long as no processes go out of bounds of that page
<nortti>
heat: but you don't, you have 64K of address space, and 512K of memory
<PublicWiFi>
which could be tricky
<heat>
512K of memory is nicer but we didn't know that beforehand
<PublicWiFi>
technically 4 16K banks with 512KB total, thought bank 0 (or maybe Bank 3, i haven't decided yet) will likely be totally dedicated to kernel only
<PublicWiFi>
BUT i'm also not above revising my banking circuit to allow for more banks at a smaller memory size
<PublicWiFi>
its trivial tbh, just adds some costs of a few more 74xx chips :D
<PublicWiFi>
and a pcb refab lol
<PublicWiFi>
though using the MMU is a super future endeavor
<PublicWiFi>
it adds to much complexity now
<PublicWiFi>
i dont even have a vfs running yet lol
<PublicWiFi>
let alone threading
geist has quit [Ping timeout: 265 seconds]
<PublicWiFi>
I will be adding in some members to the various structs to account for this in the future though so I won't have to redesign as much
<zid>
threading is the easy bit
<PublicWiFi>
like lock status and etc
Turn_Left has joined #osdev
<PublicWiFi>
lock status, which PID has it locked, etc etc
geist has joined #osdev
<PublicWiFi>
priority
<PublicWiFi>
all that fun stuff
<PublicWiFi>
I'be been reviewing the fat16 standard a bunch and I think I understand how it works, I just need to figure out which routines i will actually need and stuff
<PublicWiFi>
also I'm not trying to narrate my life in here, I'm a bit self conscious with my walls of texts ive been dumping
<PublicWiFi>
lol
travisg has quit [Ping timeout: 265 seconds]
Left_Turn has quit [Ping timeout: 265 seconds]
<netbsduser`>
PublicWiFi: i think i would leave "put unix on something that doesn't have a linear, paged address space" until after "put unix on something with a paged, linear address space"
<PublicWiFi>
yes
<PublicWiFi>
that's the idea
travisg has joined #osdev
<PublicWiFi>
v1 will be flat 64K address space
<PublicWiFi>
v2 I will try to move to MMU support
<netbsduser`>
i mean paged
<netbsduser`>
that's why i said it
<netbsduser`>
no mmu unix is doable but your scheduler will have to be a swapper
<PublicWiFi>
yeah
<PublicWiFi>
I'm going from 0 exp in this, so I'm gonna start with the most "simple" version
<PublicWiFi>
which is still relatively complex lol
<PublicWiFi>
ill add mmu complexity later
travisg has quit [Ping timeout: 245 seconds]
<heat>
most simple version is a i386 with tons of ram and address space
<zid>
most simple version is to completely disregard almost all of these concepts
<zid>
and hardcode the fuck out of everything
<PublicWiFi>
LMFAO
<PublicWiFi>
zid++ but where's the fun in that
<zid>
you don't need abstractions unless it's pluggable
<PublicWiFi>
;PPP
<PublicWiFi>
it is pluggable :o
<PublicWiFi>
i have a modular system my guy
<zid>
for hw that it will never run on or even exists?
<heat>
yes zid
<heat>
exactly
<heat>
you have almost no RAM
<PublicWiFi>
I have a ton of cards already fabbed :p
<zid>
and it's also hanging you up on actually getting ANYTHING
<PublicWiFi>
yes this more about the "can I" than the "should I" ya know?
<PublicWiFi>
I mean I've already written simple monitor systems and all that
<PublicWiFi>
I wanna make something hard man
<zid>
so do it
<heat>
a VFS on 32K of ram is absolutely impossible
<heat>
you'll struggle to get anything going
<PublicWiFi>
that's not true
<PublicWiFi>
zeal 8-bit project did it
<heat>
much less *abstractions*
<zid>
I mean, it's possible, but just pointless
<PublicWiFi>
but he doesn't have threading
<heat>
you might be able to squeeze shit in if you squeeze something else out
<nortti>
doesn't FUZIX run in like 128K total of RAM?
<PublicWiFi>
the idea is that he wants to port it to multiple systems so the abstractions helps
<zid>
because you don't need it, with the scope of what it will be able to accomplish, it may as well just be "rudimentary sector cache" and not "vfs"
<PublicWiFi>
yeah the fuzix dev has been givign me pointers too
travisg has joined #osdev
<zid>
once you've written all the actual vfs code, filled out the data structures for your.. one filesystem
<PublicWiFi>
its 100% a "i wanna see how this would work"
<zid>
it'll have used your 32kB
<zid>
and achieved nothing
<zid>
but be PLUGGABLE
<PublicWiFi>
lemme see the size of zeal 8-but
<zid>
for.. a different fs to be also-mounted, which doesn't actually exist
<heat>
early UNIX was basically if (is_chr_device) else if (is_blk_device) else {/* buncha on-disk filesystem (the one you just have) specific shit */}
<PublicWiFi>
zid: doesn't exist... YET!
<PublicWiFi>
:D
<zid>
doesn't exist then
<zid>
glad you agree
<zid>
If it comes to exist, you add an if()
<heat>
VFS started to be a thing for the VAX, because the VAX was way more capable
<zid>
you don't add a fully abstract OO style translation layer
<heat>
you should write it in java for the portability too
xenos1984 has quit [Ping timeout: 272 seconds]
<PublicWiFi>
IIRC Zeal 8bit takes up about 8KB or so
<PublicWiFi>
but he also has a lot of stuff I probably won't
<zid>
Like, I'll give you a concrete example from some code I didn't write
<bslsk05>
github.com: boros/pci.c at master · zid/boros · GitHub
<PublicWiFi>
ha
<zid>
I suppor three devices, so they're just if()'d
<PublicWiFi>
i promise I get what yall are saying
<zid>
if I had written the actual code to do that dynamically and pluggable
<PublicWiFi>
and on paper you are 1000% right
<zid>
it'd take 1kB of .text space and I wouldn't have finished writing anything
<PublicWiFi>
but idk, I wanna just see how this works, and even see hwo bad it would perform
<PublicWiFi>
but
<PublicWiFi>
you might have a point, get it working then just come back and make it "right" later I guess
<zid>
My code is right *as it is*
<zid>
Is the real point
<PublicWiFi>
yeah
<PublicWiFi>
no i get what you mean
<zid>
It's *incorrect* to have written the stupid pluggable dynamic layer, before there's anything to dynamically plug, and *I may not get around to writing anyway*
<heat>
how large is boros zid?
<zid>
it just holds you back
<zid>
heat: few hundreds of lines?
<heat>
binary-wise
<zid>
few kilobytes
<PublicWiFi>
well i want to write this layer to just get an idea of how this stuff works
<PublicWiFi>
its for LeArNing
<PublicWiFi>
:PPP
<heat>
learning what exactly?
<zid>
learning is *writing*
<PublicWiFi>
i had no idea how any of this stuff worked before I started
<zid>
theorycrafting is great, except you have *no idea what your constraints are yet*
<heat>
you're not learning how to program a modern system on a space-constricted oldschool system
<PublicWiFi>
how do you know has a vintage cpu running a rudimentary vfs
<zid>
PublicWiFi: if you try your hardest on a pared-down version, how many processes can you realistically fit? How much buffer space does that take in the kernel? How slow does it make task-switching, etc
<PublicWiFi>
:o
<PublicWiFi>
who*
<zid>
that's what you need to 'learn'
<heat>
70s unix and 80s unix were worlds apart, 80s and 90s had significant differences, 90s and 2000s are quite different too, 2010s forwards is also paradigmatically quite different
<zid>
You need to get a sense of scale, and appreciation for having *done* it
<zid>
I make this mistake myself
<zid>
"I'm sure that's easy and I could write that"
<zid>
then 2-3 years later I go into it with that full confidence and I find out very quickly I forgot to account for something
<PublicWiFi>
xD
<zid>
and it actually really annoying and requires a workaround I should have been thinking about for the past 2 years
<PublicWiFi>
well im not really trying to build a unix system, i'm just learning some of these cool workflows
<zid>
no you're not
<zid>
You're on irc
<PublicWiFi>
:(
<zid>
spitballing code that doesn't exist
<zid>
for a platform that doesn't exist
Turn_Left has quit [Remote host closed the connection]
<PublicWiFi>
that's not entirely true!
<PublicWiFi>
I have all my drivers finished :D
<zid>
but you have no idea what they should expose, you admitted it
ryoskzypu has quit [Remote host closed the connection]
ryoskzypu has joined #osdev
<sortie>
nikolar, careful, he's big linux now
<geist>
heat_ terkerjerbs!
<heat_>
THEYTOOKERJERBS
hwpplayer1 has quit [Read error: Connection reset by peer]
<geist>
grats btw
<heat_>
thanks
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
<sortie>
I remember having a jerb
<heat_>
but you took an arrow to the knee
<nikolar>
heat_, you got a jerb
<heat_>
yes, kernel @ SUSE
<nikolar>
oh congrats
<nikolar>
got anything to do yet
<heat_>
i only start on the 15th
<heat_>
but thanks :)
<nikolar>
nice
<nikolar>
good luck
ryoskzypu has quit [Remote host closed the connection]
<heat_>
cheers
ryoskzypu has joined #osdev
hwpplayer1 has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
ryoskzypu has quit [Remote host closed the connection]
ryoskzypu has joined #osdev
ryoskzypu has quit [Remote host closed the connection]
netbsduser` has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
<nikolar>
kof673: you mentioned linux lite, but how do i even get the sources for it lol
<heat_>
the sources will present themselves if and when you are worthy enough
hwpplayer1 has quit [Remote host closed the connection]
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #osdev
<zid>
nikolar: you'll need some chalk, candles, and a goat
<nikolar>
sounds like hassle zid
Turn_Left has quit [Ping timeout: 248 seconds]
bauen1 has quit [Ping timeout: 244 seconds]
<kof673>
hold on that thing i linked is an ftp site or http mirror just go up one level
craigo has joined #osdev
<kof673>
in fact...it panics...maybe needs a root fs...but i was building gcc 2.7.2.3 something or other for something else, so i built i386-linux-aout and i386-linux-elf targets, and 2.14a binutils........so i can confirm linux lite compiles with those :D but only the uncompressed Image. and qemu will run it, but panics :D
<kof673>
so ....probably can be made to work......
<kof673>
the kernel thing even says there was i386-linux-coff lol
<kof673>
and binutils and gcc i believe also support that lol
<kof673>
you got 3 choices: elf, coff, or a.out lol
<kof673>
needs a few makefile fixes and header symlinks..it kind of has some spots is perhaps confusing hostcc with "compiler for kernel" ...and assumes "compiler for kernel" has libc/stdio.h/etc. and another spot needs some dummy system calls added, unresolved references :D
<kof673>
anyways...i think it can be made to work........just annoying little things
<kof673>
and the gcc and binutils i built i kind of just made a dummy libgcc...but i don't think you need a libc + headers to compile the kernel....except for zImage seems to want that.....
<kof673>
TLDR yes slaughter a goat or two lol
<kof673>
i had to edit the kernel Makefile to match by binutils gcc ...it gets bootup text in qemu...looking for a filesystem on disk...maybe to run init :D anyways, i changed a few options, added something, got ~500k kernels for both a.out and elf
<kof673>
you can probably trim down a lot more
<kof673>
and you need dev86/bcc as86 ld86 whatever too, but i just pointed it at the "elks" version. maybe better to use an older revision :D
<kof673>
it even says it has nfs but i would be surprised if it can get a root fs from that :D