<gorgonical>
Like, does failing to train memory result in a beep code??
<gorgonical>
Shouldn't it??
agent314 has quit [Client Quit]
joe9 has joined #osdev
agent314 has joined #osdev
<joe9>
is it possible to disable paging and use a flat memory model in 64-bit mode of Intel amd64?
<geist>
negative
<geist>
it's possible to use a flat memory model, but you still have to set up the page tables to at least have everything identity mapped
<gorgonical>
Yeah the best you can do is identity mapping memory
<geist>
you can use 1GB pages for that, so it's not *too* bad
<Mondenkind>
1gb pages meh on some older uarches (<icl i think)
<gorgonical>
with 16GB pages that are all idmapped does that mean you just get like, one tlb entry that's perma-pinned? lol
<Mondenkind>
huh?
<geist>
there are no 16GB pages in x86
<geist>
only goes up to 1GB (though iirc in 5 level paging they may have finally added 512GB pages?)
<gorgonical>
Okay, lets say you have a system with only 1GB memory
<gorgonical>
I guess the TLB doesn't know about what page granularity you have
<geist>
not necessarily, depends on the implementation
<geist>
most of them do, yes
<geist>
which is why in general using larger pages is a win, since in general you will use less TLB entries
<gorgonical>
So then you could in principle have just one TLB entry that pretty much fully elides the page walker
<geist>
(depends on the implementation of the exact core)
<geist>
yes
<gorgonical>
Yeah I guess you're right. Why else would large pages help if it didn't know about granularity
<geist>
wel, it would help in that you need less page tables to map something
<geist>
and when it does walk it has to walk less, etc
<gorgonical>
also true
<geist>
but dont start thinking you can just remove the page table once you map it, the cpu is still free to dump the TLB, etc when it feels like it
<joe9>
thanks. I had a bug in the code setting up the page tables and that got me wondering if I can just not use paging at all.
<geist>
so you always have to assume it a) couldn't use a 1GB TLB entry, and b) it may re-fetch things at pretty much any time
<gorgonical>
On power though you can control the TLB right?
<gorgonical>
(I have heard this but don't know if it's true)
<geist>
joe9: alas no. it's one of the weird quirks of amd64. it requires paging to be enabled to enable the switch to 64bit mode. i dunno exactly why AMD did it that way
<geist>
gorgonical: yes,m but hang on lets not confuse joe
<gorgonical>
agreed agreed
<gorgonical>
joe9: in the future intel is planning to release processors that have less of this legacy cruft, by the way
<gorgonical>
this is not applicable right now, however
<joe9>
ok, thanks. that was helpful.
<nikolar>
it won't be applicable for a long time to be fair
<Mondenkind>
can i have rex.w default on
<nikolar>
no
<Mondenkind>
fuck you nikolar
<nikolar>
you're welcome
<nikolapdp>
i am stuck on 16bit
<nikolapdp>
so enjoy your 32 by default
<dostoyevsky2>
Writing url title bots becomes more and more difficult
<zid>
poor serbia, stuck in 16bit
<zid>
They'll get a 286 one day
<gorgonical>
good news: reducing the multiplier to 3400 works. now to find out what it will tolerate!
<gorgonical>
now I feel bad for that amazon chat person I convinced to send me a replacement mobo
<geist>
3400 from what?
<gorgonical>
3400MT/s worked. Then 4800MT/s works now
<gorgonical>
I'm trying to up it to 6000MT/s as they are rated
<gorgonical>
Pushing my luckk
<geist>
got it
<gorgonical>
incredible
<gorgonical>
it works
<gorgonical>
Well then
<nikolapdp>
nice
<gorgonical>
I'm frankly a little shocked that I managed it. I looked and noticed a few of the socket pins were veeeeeeeeeeeeery slightly bent. I can't say that it worked but I extremely carefully bent them back
<geist>
did you find this thing in a dumpster or something?
<gorgonical>
I imagine with how hard the socket lever presses the cpu onto the pin array even a small deviation could press a pin into a poor-contact spot
netbsduser has quit [Ping timeout: 268 seconds]
<dzwdz>
so in a desperate attempt to recover some lost data with `dd if=/dev/mem conv=noerror,sync` i've managed to get my x86 linux laptop to hang and reboot
<dzwdz>
any ideas what could've killed it?
<dzwdz>
if that isn't clear - i'm not asking for tech support (that ship has sailed anyways)
<geist>
if /dev/mem represents the entire physical address space, IO and all, it could be readin some parts of mmio triggered something
<geist>
lame that there may be side effects of reads, but some devices can be that way
<dzwdz>
yup, that's what i'm thinking
<dzwdz>
but i'm wondering what would make it hang outright
<geist>
and/or you read unmapped something and that triggered some sort of bus fault that blew things up
<dzwdz>
i assume linux would protect me from the latter?
<geist>
not if you went in via /dev/mem
<geist>
i assume you had to be root for this?
<dzwdz>
yup
<geist>
as soon as you start mucking around with physical memory all safeties are off
<zid>
a more intuative name might be /dev/memory-bus
<zid>
where seeking sets the address to read from
<dzwdz>
if i don't use conv=noerror i do get an error early on, though
<dostoyevsky2>
/dev/mem isn't normally available these days, last I checked you not only needed to be root but also had to have some boot flags for linux
<dzwdz>
so linux does seem to protect me from shooting myself in the foot in some ways
<dostoyevsky2>
also, the last time I wanted to use /dev/mem I could read it without problems but it was incomplete...
<geist>
dostoyevsky2: yeah depends on if you're booting in secure mode or not
<geist>
there are a bunch of limitations imposed by the kernel when in secure mode, like directly futzing with physical address space even from root
<geist>
and running unsigned kernel modules, etc
<dostoyevsky2>
> Since Linux 2.6.26, and depending on the architecture, the CONFIG_STRICT_DEVMEM kernel configuration option limits the areas which can be accessed through this file. For example: on x86, RAM access is not allowed but accessing memory-mapped PCI regions is.
<dostoyevsky2>
so maybe accessing those PCI regions could have triggered an interrupt
<geist>
yah
<dostoyevsky2>
IIUC you register the memory regions for the PCI bus and then you can write commands/receive data via different buffers but polling in the kernel would be inefficient, so it's using the mmu to trigger reading/writing
<geist>
would still be lame if something had a read side effect, but i've definitely seen it
<geist>
like, reading from some value consumes some thing off a hardware queue, etc
<geist>
so as soon as you do that you can muck up the state of hardware relative to what a driver thinks.
<dostoyevsky2>
geist: I guess one could setup DMI that way: 1) write IOPS to the command buffer 2) Read from the results buffer, and now the PCI controller would access the command buffer for the IOPS on a read trap and once the results are ready your read returns and the memory can be scanned
<dostoyevsky2>
If you were to trigger on write you'd need to know when the buffer is ready to be read by the PCI controller
<geist>
yeah i consider it kinda lame, but it can be a very efficient way to design a hardware register interface in some situations
<geist>
i hate it when writing drivers, because it's many times nice to write some dump routine that just snapshots the state of all the registers and display them
<geist>
but if doing that has a side effect you can'd
<dostoyevsky2>
yeah, that's true... I guess different controllers may have different protocols
<geist>
also means you can't easily do something like `if (read_state() & thing_i_care_about) ` code, because as soon as you read the state you have a hot potato
<geist>
you read the state register now you have to deal with it becaus eyou latched the state
<geist>
but it is what it is. anything with a fifo (like a uart) usually has latch on read side effects
edr has quit [Quit: Leaving]
<zid>
Just imagining how terrible a device would be if you had to write back an ack after every byte you read from its fifo
<zid>
Thanks, I hate it
<dostoyevsky2>
I guess you could set it up like this: command buffer, data buffer (for writes), results buffer (for reads) and a commit buffer where any write will trigger reading the command buffer by the PCI controller
<gorgonical>
this is basically how I wrote my serial terminal driver for my forth
<dostoyevsky2>
gorgonical: Would it also been possible to implement it without commit buffer and just use three buffers and commit on reading the results buffer or is the setup usually not that flexible?
Matt|home has joined #osdev
valshaped7424880 has quit [Quit: Gone]
<GreaseMonkey>
well, i just discovered that QEMU *does* support DMA-less floppy disk controller access these days
<geist>
noice
<dostoyevsky2>
At one point all OSes just get booted through qemu
<geist>
i remember years ago discovering the lack of PIO floppy access on real hardware the hard way
<geist>
spending a weekend trying to debug why it wasn't working
valshaped7424880 has joined #osdev
<mjg>
:)
<mjg>
a floppy driver is one of the things i would definitely NOT want to write
<dostoyevsky2>
mjg: Not even as an audio driver?
<Mutabah>
geist: I'd express surprise, but hardware quirks no longer surprise me
<Mutabah>
especially mid 2000s hardware, engineers got lazy there
<geist>
right i think that was the idea. there were certain chipsets that simply didn't implement not using DMA
<geist>
same with some of the more unused PIC or PIT modes
<dostoyevsky2>
what could one use instead of DMA?
<geist>
also remember there were lots of non intel/amd chipset vendors at the time. nvidia, VIA, etc
<geist>
SiS. lots of them may have been cutting corners
<geist>
dostoyevsky2: you can just PIO access the floppy controller
<geist>
push/pull data a byte at a time
<geist>
all the ISA DMA controller does is just automate the transfer of data to/from its fifo
goliath has quit [Quit: SIGSEGV]
oldgalileo has quit [Ping timeout: 246 seconds]
oldgalileo has joined #osdev
duckworld has quit [Ping timeout: 264 seconds]
duckworld has joined #osdev
k4m1_ has joined #osdev
Maja_ has joined #osdev
Fox has joined #osdev
deriamis_ has joined #osdev
<immibis>
my favourite thing about SATA is that the drive tells the host controller how many bytes the host is about to send
<immibis>
i have never implemented SATA, just perused the spec (which I paid for)
<immibis>
this is related because apparently it's a backwards compatibility requirement for ISA DMA
<immibis>
or... some type of DMA
gorgonical has quit [*.net *.split]
FreeFull has quit [*.net *.split]
deriamis has quit [*.net *.split]
mavhq has quit [*.net *.split]
ppmathis has quit [*.net *.split]
tjf has quit [*.net *.split]
rom4ik has quit [*.net *.split]
teqwve has quit [*.net *.split]
Maja has quit [*.net *.split]
LittleFox has quit [*.net *.split]
dostoyevsky has quit [*.net *.split]
janemba has quit [*.net *.split]
meisaka has quit [*.net *.split]
k4m1 has quit [*.net *.split]
<immibis>
i wonder if this means a malicious SATA drive can exfiltrate memory.
<immibis>
SATA is based on transferring the complete set of emulated ATA registers around, at the protocol level. there is no "read" or "write" command.
<immibis>
there is only "update registers" and the command register happens to contain "read" or "write"
dostoyevsky has joined #osdev
janemba has joined #osdev
meisaka has joined #osdev
<GreaseMonkey>
AFAIK the floppy driver in the Atari ST isn't horrible
mavhq has joined #osdev
<GreaseMonkey>
...driver, i meant controller
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
basil has quit [Remote host closed the connection]
basil has joined #osdev
basil has quit [Remote host closed the connection]
basil has joined #osdev
Goodbye_Vincent1 has joined #osdev
hanemile_ has joined #osdev
patwid_ has joined #osdev
randm_ has joined #osdev
dostoyev1ky has joined #osdev
hl has joined #osdev
teroshan5 has joined #osdev
lh has quit [Ping timeout: 240 seconds]
hanemile has quit [Ping timeout: 240 seconds]
randm has quit [Ping timeout: 240 seconds]
hanemile_ is now known as hanemile
randm_ is now known as randm
lanodan_ has joined #osdev
tommybomb_ has joined #osdev
asymptotically_ has joined #osdev
jleightcap_ has joined #osdev
remexre_ has joined #osdev
pounce_ has joined #osdev
sskras_ has joined #osdev
theruran_ has joined #osdev
noeontheend_ has joined #osdev
nohit_ has joined #osdev
gjn_ has joined #osdev
ursa-major_ has joined #osdev
bradd_ has joined #osdev
vismie_ has joined #osdev
whereiseveryone_ has joined #osdev
rselim_ has joined #osdev
asarandi2 has joined #osdev
bradd has quit [Killed (NickServ (GHOST command used by bradd_))]
bradd_ is now known as bradd
exark_ has joined #osdev
woky- has joined #osdev
geist_ has joined #osdev
dostoyevsky has quit [Ping timeout: 260 seconds]
alexander_ has joined #osdev
meisaka has quit [*.net *.split]
janemba has quit [*.net *.split]
xenos1984 has quit [*.net *.split]
navi has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
asarandi has quit [*.net *.split]
teroshan has quit [*.net *.split]
[Kalisto] has quit [*.net *.split]
dostoyevsky2 has quit [*.net *.split]
gmodena has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
alexander has quit [*.net *.split]
Rubikoid has quit [*.net *.split]
lanodan has quit [*.net *.split]
JTL has quit [*.net *.split]
Mutabah has quit [*.net *.split]
offlinemark_ has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
acidx has quit [*.net *.split]
ecs has quit [*.net *.split]
cultpony has quit [*.net *.split]
nortti has quit [*.net *.split]
friedy has quit [*.net *.split]
teroshan5 is now known as teroshan
meisaka has joined #osdev
air has quit [*.net *.split]
stux has quit [*.net *.split]
patwid has quit [*.net *.split]
rselim has quit [*.net *.split]
froggey has quit [*.net *.split]
ursa-major has quit [*.net *.split]
whereiseveryone has quit [*.net *.split]
Goodbye_Vincent has quit [*.net *.split]
hl_ has quit [*.net *.split]
sskras has quit [*.net *.split]
noeontheend has quit [*.net *.split]
jleightcap has quit [*.net *.split]
tommybomb has quit [*.net *.split]
asymptotically has quit [*.net *.split]
gjn has quit [*.net *.split]
vismie has quit [*.net *.split]
remexre has quit [*.net *.split]
erai has quit [*.net *.split]
PublicWiFi has quit [*.net *.split]
theruran has quit [*.net *.split]
tomaw has quit [*.net *.split]
cow321 has quit [*.net *.split]
exark has quit [*.net *.split]
pounce has quit [*.net *.split]
nohit has quit [*.net *.split]
woky has quit [*.net *.split]
dragestil has quit [*.net *.split]
shikhin has quit [*.net *.split]
marshmallow has quit [*.net *.split]
geist has quit [*.net *.split]
asymptotically_ is now known as asymptotically
vismie_ is now known as vismie
pounce_ is now known as pounce
geist_ is now known as geist
noeontheend_ is now known as noeontheend
rselim_ is now known as rselim
Goodbye_Vincent1 is now known as Goodbye_Vincent
tommybomb_ is now known as tommybomb
remexre_ is now known as remexre
gjn_ is now known as gjn
patwid_ is now known as patwid
sskras_ is now known as sskras
jleightcap_ is now known as jleightcap
nohit_ is now known as nohit
ursa-major_ is now known as ursa-major
whereiseveryone_ is now known as whereiseveryone
lh has joined #osdev
duckworld has quit [Ping timeout: 250 seconds]
DoubleJ has joined #osdev
offlinemark_ has joined #osdev
janemba has joined #osdev
xenos1984 has joined #osdev
[Kalisto] has joined #osdev
dostoyevsky2 has joined #osdev
ZipCPU has joined #osdev
Mutabah has joined #osdev
pieguy128 has joined #osdev
JTL has joined #osdev
ecs has joined #osdev
friedy has joined #osdev
acidx has joined #osdev
cultpony has joined #osdev
nortti has joined #osdev
gmodena has joined #osdev
acidx has quit [Remote host closed the connection]
ecs has quit [Ping timeout: 260 seconds]
acidx_ has joined #osdev
cow321 has joined #osdev
offlinemark_ has quit [Ping timeout: 260 seconds]
Mutabah has quit [Ping timeout: 260 seconds]
Mutabah has joined #osdev
froggey has joined #osdev
gmodena has quit [Remote host closed the connection]
cultpony has quit [Ping timeout: 260 seconds]
ecs has joined #osdev
dragestil has joined #osdev
tomaw has joined #osdev
shikhin has joined #osdev
cultpony has joined #osdev
theruran_ is now known as theruran
Rubikoid has joined #osdev
tomaw_ has joined #osdev
duckworld has joined #osdev
tomaw has quit [Ping timeout: 612 seconds]
tomaw_ is now known as tomaw
pieguy128 has quit [Max SendQ exceeded]
JTL has quit [Max SendQ exceeded]
pieguy128 has joined #osdev
JTL has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
PublicWiFi has joined #osdev
rustyy has quit [Quit: leaving]
agent314 has quit [Remote host closed the connection]
FreeFull has joined #osdev
rustyy has joined #osdev
zetef has joined #osdev
kristinam has quit [Ping timeout: 268 seconds]
Gooberpatrol66 has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
ThinkT510 has quit [Quit: WeeChat 4.2.2]
ThinkT510 has joined #osdev
<geist>
huh thats cute: the ODS-2 (VMS file systems) directory entries are pretty much like standard ffs/ext2 style
<geist>
except to handle the multiple file version numbers it's a packed list of versions and inode numbers in descending order
<geist>
so something like <record length, name length, "name", [ [version, inode], [version, inode], [version, inode] ]>
<geist>
the number of items are deduced by the record length. cute.
<kazinsal>
ooh, neat
<geist>
been writing some code to walk an ODS-2 disk image. there's been some attempts at it in the past, but it's always fun to figure it out on your own
<geist>
there's some definite wonkiness in the way it handles VBN (virtual block numbers) and LBN (logical block numbers)
<kazinsal>
the files-11 path spec has always fascinated me
<geist>
has some of the standard nonsense about stuff being 1 indexed, and the weird thing is the allocation unit in ODS2 is not a power of 2 of the sector size
<geist>
so in this case it's cluster factor 5, which means each cluster is 0xa00 bytes lone
xenos1984 has quit [Read error: Connection reset by peer]
<kazinsal>
something odd like node"username password"::device:[dir1.dir2.dir3]filename.ext;version
<kazinsal>
clearly made for vax clustering
<geist>
yep. the key to exploring it manually is directory [000000] is always the root one
<geist>
the MFD (master file directory) is always inode 4 and it's always called 000000, and all files, including the master index file (INDEXF.SYS, file ID 1) is in it
<geist>
the 000000 i think is historical, since RSX-11 used an earlier precursor to FILES-11 that i think was only 2 levels deep
<kazinsal>
yeah I think ODS-1 was more like flat MFS
<geist>
and each user+group combination had a 'workspace' to fiddle around with
<kazinsal>
or like CP/M "users"
<geist>
which was in practce assigned to a directory in the MFD named [UUUGGG]
<geist>
from what i understand early VMSes (maybe later ones too) could mount an ODS-1 volume, maybe only read only though
<geist>
but makes sense, because in early VAX-11 you had PDP-11 hardware emulation, so i think there was some way to try to directly run RSX-11m binaries or whatnot
<geist>
it's also kinda interesting to see how under the hood the record based file structure works. 'stream' based files, like you get on a posix or windows systems are just a special case of a variable sized record
<geist>
otherwise it's described in the FILE record what the record structure is
<dasabhi>
hey i just noticed xv6 .h headers dont have page guards
<dasabhi>
matter of fact, even little kernel doesnt have page guards in all headers
<dasabhi>
is this by choice?
<geist>
page guard?
<kazinsal>
oh yeah xv6 still exists
<dasabhi>
as in stopping the headers for being double added
<geist>
oh? point me where there's a missing one in LK and i'll fix it
<dasabhi>
yeah hold on i just saw one
<kazinsal>
I kinda forgot about xv6 when they decided to drop x86
<dasabhi>
yeah riscv is ezz
<kazinsal>
rv64 is cute but when the major companies doing cores for it decided to fire 90% of their engineering staff I lost interest
<geist>
also using this somewhat as a n opportunity to try to use vscode to program a thing from scratch. kinda a mixed bag, but i'm not too upset with it today
<kazinsal>
vscode is nice but it takes some finagling
<kazinsal>
some of the bits in the C extension are very clearly cl.exe focused but you can usually wrangle them to be gcc/clang friendly
<kazinsal>
definitely not great for working with any other compiler though. anything I write for openwatcom has a LOT of red squigglies
<dasabhi>
geist: nvm i must of hallucinated, you use the #pragma once, havent seen that before as a page guard, i have only seen the default #ifndef.....#endif
<geist>
yah i switched to only using `#pragma once` henceforth
<geist>
it's so nice
<kazinsal>
yeah I need to switch over to that for my next project
<dasabhi>
i guess #pragma once does the same thing right?
<dasabhi>
its the simplest page guard, preventing double adds
<geist>
at the time i was kinda protesting the decision at work to actually replace all the LK pragma onces with the silly old header guard for zircon, because it was the company policy
<kazinsal>
much easier than copying and pasting stuff like `__KERNEL__INCLUDE__DEVICES__PCI__NET__XL710_H`
<geist>
so stupid, so many bugs have existed because it
<geist>
guards get out of date when things move around, tools have to be made to maintain it, etc. #pragma once just solves it all
<dasabhi>
anyways yeah really surprised to see no page guards on xv6
<geist>
only reason cited not to use it is because some old toolchains dont support it, which is precisely not our problem since we mandate modern clang
<kazinsal>
yep
<kazinsal>
every year or so I just go to my toolchain build directory and do `git checkout && ./doit -a "i386 x86_64 aarch64"`
<kazinsal>
my current fiddling about is getting my linux servers joined to my internal AD domain
<kazinsal>
so far it's working pretty well. biggest gripe is that when you ls something that's owned by an AD user or group (or both) it prints the whole damn canonical name of the entity
<geist>
oh interesting, yeah that's something i've never tinkered with, having some sort of centralized user DB
<mjg>
just don't YP it
<mjg>
you may be tempted given all the old boxen ;)
<mjg>
i don't know if YP even works on contemporary linux though
<kazinsal>
heh, no YP here
<kazinsal>
the org I work for used YP waaaaaaaaay back in the early days
<mjg>
it's some telnet-era sit
<kazinsal>
when they were a SunOS shop
<mjg>
ye
<mjg>
i worked at a shop using YP in 2010
<kazinsal>
that was the late 80s/early 90s though
<mjg>
it was YP for $REASONS
<mjg>
it already did not make sense then
<geist>
BANYAN
* geist
throws some VINES everywhere
<geist>
(actually i have no idea if banyan vines had any sort of directory thing)
<mjg>
wtf is banyan vines
<kazinsal>
oh probably
<kazinsal>
I think it had a globally distributed registry of some kind
<geist>
yah wikipedia says that was actually it's forte there for a while when it was a thing
<mjg>
for a moment there i thought you are throwing a tiktok meme around
<mjg>
turns out it was an actual product
<geist>
yeah it was a big thing back in the 80s and 90s. just didn't make it. was a big competitor to novell netware and windows stuff
<kazinsal>
I'm the youngest non-student worker at my current org by about a decade so I get to hear some fun stories of the ol' days
<mjg>
i somehow never heard of it, and i did hear about a lot of werid shit
<kazinsal>
(and even then, I'm about a decade older than the co-op students)
<mjg>
i even managed to use some novel netware on dos in college in 2006
<mjg>
:p
<kazinsal>
the lead net admin has fond memories of everything on the campus network going to shit when shareware doom came out
<mjg>
fuckin' academia larping the world 10 years prior
<geist>
it was old even by the time i first bumped into it. I was interning at Compaq in about 1995 and they still had some Banyan servers floating around, though they were transitioning to something else at the time
<geist>
probably NT
<geist>
since they really wanted to use their own hardware
<dasabhi>
if you scroll down to line 107, you see a bunch of extern declarations for sys call functions
<dasabhi>
which is fine, that should be there
<dasabhi>
but if you scroll down to line 138, you see a myproc(), which is defined in another file called proc.c
<dasabhi>
question is why isnt that proc.c declared as an extern as well
<dasabhi>
its outside the current object file during compile
<dasabhi>
why isnt that myproc() function declared as extern*
gbowne1 has quit [Quit: Leaving]
<kazinsal>
line 97 of defs.h
<dasabhi>
i am dumb
<mjg>
or more to the point, myproc is presumably used all over the place, so it makes sense for it to be declared in a header
<geist>
also a a side note you dont really need to declare things like that extern, it's just sometimes used as a sign that it is
<mjg>
however, it being a full blown func instead of an inline is some crap choice
<dasabhi>
okay i am throwing off some C rust here, why arent they declared as extern?
<dasabhi>
geist: ah okay got it
<kazinsal>
yeah it's more a convention to say "this is kind of a one-off extern function declaration"
<dasabhi>
so i am guessing the syscall needed the extern because of its nature as function pointers?
<dasabhi>
but other external functions dont really need it
<geist>
there's cases where extern is needed, etc. but for a plan function declaration, `void foo();` is as good as `extern void foo();`
<geist>
as long as you dont have the body of it, it's just a function declaration
<dasabhi>
got it thank you
<dasabhi>
guess i am a little rusty on my C
<geist>
well, also keep in mind xv6 is probably not the best codebase to be learning the finer details on
<mjg>
c is crap and full of terrors
<dasabhi>
geist: you got any better suggestions?
<mjg>
ye c gives too much leaway to avoidably do things wrong or otherwise differ from the usual for no reason
<kazinsal>
someone once described c++ as a language full of byzantine footguns waiting to be discovered. from this I extrapolated that c is a language for crafting byzantine footguns
<geist>
not particularly, but just dont get too hung up on the details
<mjg>
dasabhi: what are you trying to do mate
<geist>
as in keep in mind the xv6 codebase is probably not pristine
<dasabhi>
mjg: trying to not have a skill issue
<mjg>
you gonna have to be more specific
<dasabhi>
geist: yeah i am seeing that with the lack of header guards ahah
<geist>
exactly
<kazinsal>
I sometimes wonder why xv6 is written the way it is but it probably makes more sense when you're paying MIT several thousand dollars for someone with tenure to explain it to you
<geist>
can you point me at some of them? I'm a but curious if that's really the case
<geist>
in general lack of header guards will bite you pretty fast, so i'm a bit surprised they can get away with it
<mjg>
maybe they do thanks to recoded declarations elsewhere? :p
<dasabhi>
mjg: i need to train on something before i can go attempt to build pcie passthrough on openbsd or actually contribute to a real OS
<mjg>
> build pcie passthrough on openbsd
<geist>
once the codebase gets sufficiently complicated, not having header guards will cause the same thing get included more than once, boom
<mjg>
am i reading this right
<dasabhi>
geist: yeah hold on
<kazinsal>
iommu shit is way complicated
<dasabhi>
kazinsal: exactly which is why i need to start small
<bslsk05>
github.com: xv6-riscv/kernel/proc.h at riscv · mit-pdos/xv6-riscv · GitHub
<dasabhi>
geist: look at any of the headers in this directory
<mjg>
i don't think you are getting real prep like that for dealing with a legacy codebase like openbsd
<dasabhi>
i was just as surprised as to why there arent header guards in something this complex
<geist>
yeah you're right
<kazinsal>
trying to start with a risc-v teaching reimplementation of a version of unix from 1975 based on a clean room reimplementation of a book from 1976 is not going to teach you how to implement iommu for a full size modern-ish OS
<dasabhi>
mjg: gotta start some where right
<mjg>
specifics of what you are trying to do aside, the bsds come with a lot of technical debt which openbsd failed to cleaned up
<mjg>
well in this particular case i would argue against pursuing pcie passthrough on openbsd to begin with
<geist>
i love the abstraction too: there's a riscv.h header plop in the middle of the generic kernel tree
<mjg>
but should you insist on doing it, i think the least problematic way forward is to dig into openbsd
<geist>
wait, is there any arch abstraction at all here?
<mjg>
i thought xv6 started on i386?
<dasabhi>
geist: no this repo is made just for riscv
<mjg>
perhaps at the time it had all the headers tied to it, now someone did a rename
<kazinsal>
it did, they just threw it all out a while ago because risc-v assembly is "easier" or something
<geist>
so wait when they port it to a new arch they just copy the thing and rip out the old arch?
<geist>
... okay
<kazinsal>
or maybe someone got paid some kickbacks from sifive or something
<mjg>
no ifdefs!
<mjg>
i can sell that as a win
<kazinsal>
geist: yeah they completely discontinued x86 for no stated reason
<mjg>
tbf i would discontinue x86 as well
<dasabhi>
geist: yes they dont maintain the old archs files, yes this is real dumb
* geist
shrugs
<dasabhi>
geist: but its to keep it simple for the zoomers
<mjg>
but would make sure the sucker works on 2 archs
<geist>
well, look whatever floats their boat
<mjg>
so either add arm64 or amd64
<mjg>
as is they are setting a shite example how to do things
<dasabhi>
i guess they leave this as a project for their students
<dasabhi>
port it to arm or x86_64 bro
<geist>
yeah if the purpose is to just teach, then keeping it simple is probably the idea
<geist>
rip out all the hard arches, switch to riscv
<geist>
makes sense in a way
<kazinsal>
yeah, when you're dealing with what's functionally a pure simulation it simplifies things
<dasabhi>
but that is still not a reason to not have fucking header guards lmfao
<kazinsal>
I don't know if xv6 will run on a sifive board. I would assume it does not
<dasabhi>
even first year MIT kids can understand why you need header guards jfc
valshaped7424880 has quit [Quit: Gone]
<kazinsal>
but there are generally a dearth of "active" teaching operating systems
<mjg>
at this point i would expect a rust rewrite of xv6 tbh
<dasabhi>
mjg: okay if you were me, a total beginner, and you had ambitions on building a hypervisor for a big open source code base, what reasonable steps would you take?
<mjg>
ooff
<dasabhi>
mjg: but not a beginner to C
<dasabhi>
mjg: just to kernel space
<mjg>
that is a hard one, but before i even tackle this
<kazinsal>
spend ten years learning operating system development and theory first
<mjg>
you do know openbsd does have a native hypervisor
<mjg>
vmd or something
<kazinsal>
(it's a pretty nice one too)
<dasabhi>
because my ideas was xv6->xv6_hypervisor to learn basics, then dig into a BSD
<geist>
also keep in mind hypervisors are hiiiighy archicturally specific
<geist>
so you also need to pick oneo f em
<dasabhi>
geist: yes
<geist>
so riscv hypervisor is at least architecturally very simple
<dasabhi>
yeah i know about that
<geist>
since there's not much hardware to it
<geist>
though that can be deceptive: that may mean software has to deal with more
<dasabhi>
its just something i am doing for confidence building before jumping to a real thing
<mjg>
arguably you picked something harder to do than to write a toy kernel
<geist>
indeed.
<mjg>
and it is definitely nowhere near as documented either
<geist>
if you just want to do a hello world hypervisor it may be sort of doable, but it's definitely complicated
<mjg>
if i had to do it, i would probably hop over to kvm or qemu channels to ask for guidance
<mjg>
i am definitely not qualified to give anything resembling a roadamp for this one
<dasabhi>
are those channels even active?
<geist>
thing is almost instantly after getting a guest running you have to start dealing with emulating hardware, handling vmexits, etc
<geist>
so it gets complicated super fast
<dasabhi>
geist: well yes why else would any one pay me north of 250k to work in mountainview lmao
<geist>
but like i said if you just want to load something, then handle the first time whatever you loaded wants to output something you have to trap it
<mjg>
dasabhi: i don't know if *channels* are active, but there is definitely hang out spots for developers which you can access
<mjg>
maybe there is a discord or something
<geist>
riscv where you're emulating SBI may be kinda interesting, since there's a console_write call implemented in SBI
<kazinsal>
if building a stable, production-ready hypervisor was easy, there'd be a million vmwares instead of one vmware (a broadcom company)
<mjg>
you could make the same argument for kernels
<mjg>
getting to a self-hosting kernel is *doable* for an individual
zetef has quit [Ping timeout: 240 seconds]
<mjg>
as for hypervisors, stated difficulty aside, how many people are even trying?
<geist>
hah challenge accepted
Nixkernal has joined #osdev
<dasabhi>
anyways gotta start some where, but i will keep this in mind, after riscv hypervisor, i will have to learn all of x86 to do anything meaningful for any of the BSDs
<geist>
but really, no i dont have the time to do that
<mjg>
geist: weekend project innit ;)
valshaped7424880 has joined #osdev
<mjg>
dasabhi: go hassle qemu or kvm folk
<mjg>
the only real bit of advice here
<dasabhi>
geist: havent you guys virtualized zircon
<geist>
yep
<dasabhi>
how long did that take?
<kazinsal>
zircon ain't a one man band homie
<dasabhi>
yeah true i guess
<geist>
oh i dunno, 6 months? but it was a team of folks
<mjg>
fwiw the freebsd hypervisor was created by 2 folks
<geist>
total time was definitely many man years
<dasabhi>
thats pretty good, qnx hypervisor took even longer
<mjg>
i don't know the timeframe tho
<mjg>
and even then it made numerous assumptions about guests
<geist>
yah they were smart folks, i can tell ya
<dasabhi>
i guess i have to ask in kvm or qemu mailing lists after virtualizing xv6
<geist>
i was very impressed with the folks that signed up to do it
<geist>
then google laid them off.
<dasabhi>
is the zircon hypervisor code open source?
<mjg>
:P
<kazinsal>
there's a specific type of person who can hunker down and math that kind of thing out without thinking about things like "sleep" or "showers" or "social interaction"
<mjg>
very corporate of them
<dasabhi>
wait
<kazinsal>
john carmack whipped up the doom engine in a few months but I wouldn't call him someone I'd want to be near in 1993. or ever.
<dasabhi>
geist: kernel guys were laid off?
<kazinsal>
welcome to tech
<geist>
kernel individuals, not kernel guys
node1 has joined #osdev
<dasabhi>
yeah as in people working on the core kernel with you, shit even they were hit in the 2023 layoffs
<dasabhi>
fuck i thought it was just userspace guys
<dasabhi>
i am sorry to hear that
<dasabhi>
userspace folks*
<geist>
keep in mind a lot of a hypervisor is the user space side of it
<node1>
What's the future of os?
<mjg>
are you some kind of ring-ist ;)
<geist>
the virtual machine monitor
<dasabhi>
oh right true, microkernel
<geist>
well, not even that. we implemented the ring0 stuff, and then essentially a QEMU like thing for user space
<mjg>
fwiw i had never seen kernel fork to be safer then the rest
<geist>
a hypervisor without the setup and device emulation is not that useful
<dasabhi>
mjg: i am absolutely a ringist
<geist>
the user space stuff is written in rust, yes
<mjg>
but at the same time you are userspace scum?
<kazinsal>
kernel stuff is a specific subset of general systems programming knowledge
<geist>
the ring0 interface for zircon is pretty similar to most other KVM/etc style things
<geist>
there's only so many ways to do it
<dasabhi>
isnt zircon feature complete now?
<node1>
How is ? [ [os] + AI ] =
<mjg>
i just remembered one guy did a netbsd hypervisor which tied into qemu
<mjg>
nvmm
<dasabhi>
mjg: i wouldnt find looking that nvmm either
<bslsk05>
lore.kernel.org: [RFC PATCH] percpu_counter: reimplement _add_batch with __this_cpu_cmpxchg
<mjg>
you mean on the channel? sure
<mjg>
you are not performance-minded, just do some reading, crap pops up almost immediately
<mjg>
here is a sample shite code i can't bring myself to fix and which you can pick up if you want
<mjg>
see kernel/sys.c and user_auxv handling
<mjg>
code duplication, stupid locking and overall lack of quality
<mjg>
it is broken like this for over 10 years now(!)
<mjg>
here is a specific example of breakage:
<mjg>
task_lock(current);
<mjg>
memcpy(mm->saved_auxv, user_auxv, len);
<mjg>
task_unlock(current);
<geist>
oh no pessimal!
<mjg>
mm is shared between different threads, so locking yourself does not protect against others getting there
<mjg>
it literally does nothing to add correctness
<mjg>
to make it funnier the code doing reads does not even lock anything
<mjg>
and looks like shit on top of it
<mjg>
see auxv_read in fs/proc/base.c
<mjg>
so, if you are looking to start with something easy, this looks like a decent spot
<mjg>
i have to note however this is not my code and i'm not in position to ack whatever you changes you may post there
<dasabhi>
mjg: that looks very interesting, can i email you for details?
<mjg>
sure
<mjg>
i don't think it's interesting, frankly i would offload it to an intern if this was my code to clean up and i had one
<mjg>
;)
<dasabhi>
yeah thats fine, i will eat that shit right up
<mjg>
the name of the game is CRAP man
<mjg>
my email can be found on lnks above
<mjg>
just in case i'll note my last name is NOT garrett
<kazinsal>
"no, no, not THAT mjg"
<kazinsal>
other dumb and bad project: deeply considering making my audio system at home even more complicated than it already is by adding in some classic MIDI gear
<geist>
heh i was thinking of going to goodwill and tyring to find an old CD player
dasabhi has quit [Quit: Lost terminal]
<kazinsal>
which would necessitate a MIDI card, a MIDI synth (preferably an SC-88 Pro if I can find one in 120VAC), and a mixer
<geist>
i was getting nostalgic for all my old CDs which i still have
<kazinsal>
I saw a video of someone playing some songs from Rise of the Triad through an SC-88 Pro and it made me immediately go look at reverb for one haha
<geist>
niice
<geist>
i assume that old Roland MT-32 is basically impossible to find now
<geist>
since that's the gold standard
<geist>
looks like $250-$350 yeah
<kazinsal>
you can sometimes find a few but they tend to ship from japan
<kazinsal>
so often you'll need to get a step-down transformer because they're meant for 100VAC and plugging 'em straight into 120 will negate your purchase rather explosively
<kazinsal>
there's a handful of SC-88 Pros on reverb but they all ship from Australia
<kazinsal>
while oddly also being 100VAC with a Japanese outlet
<kazinsal>
I probably oughta finish the rest of these vintage projects before I go buying myself a synthesizer of unknown provenance from a reverb seller in japan though
<kazinsal>
like recapping this goddamn PS/2
<geist>
yeah
<geist>
do it!
<geist>
and that VAX!!!!
<geist>
you too can run openvms
<kazinsal>
and the VAX!
<kazinsal>
between the two of us we'll one day get an osdev skeleton for VAX working
<geist>
i actually popped open one of the Vaxstation 4000/VLCs that doesn't work i got
<kazinsal>
in 2029
<geist>
the power supply just doesn't start
<geist>
completely fails to start, but nothing obvious
<geist>
need to dive in
<kazinsal>
yeah I need to open the PSU of the 3100/40
<kazinsal>
I think the ol' rifa RFI filter cap went poof
<kazinsal>
worst case I can just unsolder it and it'll work again
<kazinsal>
might annoy anyone around me trying to listen to ham radio
<geist>
yeah that's an easy one. i was hoping for exactly that in this case
<kazinsal>
also got a couple dead caps on this compact mac as well, though the only thing it's affecting is sound
<kazinsal>
would still love to find an LC580/Performa 580CD though. that was the mac I cut my teeth on
<kazinsal>
33 MHz '040, up to 64 megs of RAM, IDE and SCSI capable
<geist>
yeah, the early 90s macs are the toughest ones to get good caps on though
GeDaMo has joined #osdev
<kazinsal>
unfortunately a couple months back one of my other older machines finally gave up the ghost rather violently
<kazinsal>
circa '97 toshiba laptop. battery finally vomited everywhere
<geist>
eep
<geist>
(and i say that in a Wild Eep voice)
<kazinsal>
lol
<kazinsal>
a sound so visceral I can taste it
<geist>
heh
<kazinsal>
only machine I truly regret going missing though was a sparcbook 3GX that disappeared in a move probably 15 years ago
<kazinsal>
not a particularly powerful machine but real neat little box
<kazinsal>
had something like a 75 MHz sparcv8 in it
<geist>
oh yea totally
<geist>
tadpole right?
<kazinsal>
yeah
<geist>
why i remember that i dunno
<geist>
same with the pegasos I and II machiens i had floating around
<geist>
i discoarded them years ago
<kazinsal>
it was my uncle's work machine from like, 94 to 99 when he was at alcatel
<geist>
though frankly they were pretty crappy
<kazinsal>
then he gave the thing to me and taught a barely-sentient me how to unix
<bslsk05>
'The Black Keys - Hard Row (Sons of Anarchy) HD' by Sons of Anarchy (00:03:13)
<geist>
black keys are great, saw them a few years back
<kazinsal>
shame they only made two seasons of sons of anarchy
<mjg>
noice
<mjg>
kazinsal: haha
<mjg>
kazinsal: fwiw i picks up after the 3 fiasco
<kazinsal>
there are good bits peppered throughout the rest of the show
<mjg>
also s3 finale is glorious
<kazinsal>
the last two are not great.
<mjg>
agreed
<mjg>
really wasted opportunity
<geist>
love anything with ron perlman in it
<kazinsal>
I'd like someone to pick it up for a modern remake, without kurt sutter behind the wheel
<geist>
he's one of those character actors i love whatever he's in
<kazinsal>
even if they condense the main arc down into two or three seasons it'd be solid
<kazinsal>
they just need to not make all the same mistakes they did over the course of seven years
<mjg>
i think if they cut out the bullshit
<mjg>
they have like 4 seasons of great story to tell
<kazinsal>
though I'd only be in if walton goggins returns. love him
<kazinsal>
his part is great particularly because of all the genuine care and effort he put in
<mjg>
look if david simon took over that would be A+ for me
<mjg>
less shooting, more talking
<kazinsal>
and how he told all the cast and crew behind the scenes that he wanted to be respectful and develop a great character out of what was supposed to be a bit part
<mjg>
(not that i i expect that to happen)
<kazinsal>
the first two seasons of Mayans was pretty good
<kazinsal>
didn't really click with the third and haven't watched anything newer
<mjg>
i can't be fucked to watch that tbh
<mjg>
i hear there is a soa comic though
<mjg>
maybe i'll bring myself to read that
<kazinsal>
I mostly watched because of our father of FTL manoeuvres Edward James Olmos
<geist>
so say we all
<kazinsal>
still one of the most "oh, *wow*" bits of sci-fi TV
<kazinsal>
flames all screaming out of the viper tubes as Galactica plummets
<geist>
FWIW walton goggins in fallout is pretty great
<geist>
i should add him to the list of character actors i'll watch what they do
<kazinsal>
yeah, I need to watch that
<geist>
jk simmons, stephen root, steve buscemi, etc
<kazinsal>
he's really good in The Shield, which is another Kurt Sutter show
<geist>
oh hell yeah walton goggins steals the show
<geist>
(fallout that is)
<kazinsal>
The Shield is kinda based on the rampart scandal so it's got that dark vibe
<geist>
is that the one with andre braugher?
<geist>
or no, that was uh.
<geist>
Homicide: life on the streets
<kazinsal>
yeah, that was homicide
<mjg>
you binge watch everything david simon? :)
<geist>
i mean The Wire is epic
<kazinsal>
simon knows his shit
<geist>
that's enough to make me want to watch all his shit
<geist>
though i haven't really gotten around to it
<kazinsal>
The Wire is always worth a rewatch
<mjg>
the iwre is the shit, no doubt
<mjg>
Generation Kill was pretty meh
<mjg>
rather skippable unless you insist on war shows
<kazinsal>
oddly I haven't watched generation kill, despite knowing some folks who were in Iraq Part II
<mjg>
"we own this city" is A+
<mjg>
reuses some of the wire actors in different roles tho
<mjg>
some of them funny
<mjg>
Poot is a cop for example
<kazinsal>
yeah, simon really liked just casting b-more locals
<kazinsal>
I do need to put that one on the list though
<kazinsal>
love Jamie Hector
<kazinsal>
fantastic as Marlo, also brilliant in the Bosch series
<mjg>
marlo turned it around, did not he
<mjg>
;)
<mjg>
too bad stringer does not star there
<kazinsal>
if you haven't watched Bosch, it's great. based on Michael Connelly's novels
<kazinsal>
stars Titus Welliver and Jamie Hector
<kazinsal>
and the late great Lance Reddick
<mjg>
i like both dudes
<mjg>
i'll add it to my watchlist
<kazinsal>
same kind of season-wide arc deal as The Wire
<kazinsal>
where each season is a case
<mjg>
i mean the titus and lance dudes
<mjg>
fun fact: both starred in Lost, but their characters never met
<kazinsal>
seven seasons, all on amazon prime or otherwise *y'arrrr*
<kazinsal>
plus a couple spinoffs, one of which is through two seasons but I haven't watched and the other's in development
<mjg>
meh, i ]m a little warry of shows with too much content
<mjg>
quality likes to take a dip
<kazinsal>
well, at least in this case they're working off a series of novels with like 20 entries
<kazinsal>
and they combine elements from a few different novels into each season
<kazinsal>
I'd say the last season of Bosch is probably the weakest but in the same sense that the last season of The Wire is kinda the weakest
<kazinsal>
but it's all still brilliant
<mjg>
well the main plot of the last season was dreamed while high
<kazinsal>
lots of multi-season through lines
<geist>
oh my lance reddick indeed
<kazinsal>
reminds me, I gotta rewatch Argo
<kazinsal>
ben affleck, bryan cranston, john goodman, and titus welliver all in one weird film about the most baffling hostage extraction campaign
<mjg>
that reminds me to check out F Argo
<mjg>
8)
<kazinsal>
neat film, haven't watched the TV series
<mjg>
i hear it is high quality, roughly in line with the movie
<mjg>
ye i loved the film
<kazinsal>
hm. found an archived link about restoring a sparcbook 3. definitely seems to have distinct differences from the 3gx I had
Left_Turn has joined #osdev
<kazinsal>
the 3 seemed to just have HDI30 connectors for expansion but I very very distinctly remember the 3gx having HD50s
<kazinsal>
heh. looks like tadpole got eventually bought by general dynamics and used as their toughbook-esque brand for a bit
node1 has quit [Ping timeout: 250 seconds]
node1 has joined #osdev
node1 has quit [Ping timeout: 250 seconds]
node1 has joined #osdev
dinkelha1 has quit [Quit: WeeChat 3.5]
dinkelhacker has joined #osdev
gsekulski has joined #osdev
gsekulski has left #osdev [#osdev]
netbsduser has joined #osdev
leg7 has joined #osdev
node1 has quit [Ping timeout: 250 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
oldgalileo has quit [Ping timeout: 268 seconds]
oldgalileo has joined #osdev
spare has joined #osdev
Halofreak1990 has joined #osdev
navi has joined #osdev
gog has joined #osdev
<leg7>
Hey do I have to come up with an encoding to translate scan codes to keycodes or can I just use the linux transition table?
<bslsk05>
www.theregister.com: Gentoo and NetBSD ban 'AI' code, but Debian doesn't – yet • The Register
gsekulski has joined #osdev
FreeFull has joined #osdev
vdamewood has joined #osdev
chiselfuse has quit [Remote host closed the connection]
oldgalileo has quit [Ping timeout: 240 seconds]
chiselfuse has joined #osdev
oldgalileo has joined #osdev
gsekulski has quit [Ping timeout: 264 seconds]
node1 has joined #osdev
oldgalileo has quit [Ping timeout: 240 seconds]
oldgalileo has joined #osdev
Halofreak1990 has joined #osdev
leg7 has joined #osdev
<kof673>
> myproc is presumably used all over the place, so it makes sense for it to be declared in a header > however, it being a full blown func instead of an inline is some crap choice
<leg7>
How do you guys handle compilation when standalone header files are modified? Do you recompile everything? I don't see any other solution
<kof673>
eh...i generally always do separate header for functions, one function per .c file :D exception is "main()" let the compiler/etc. deal with inlining :/
<kof673>
well, i just like fine-grained ^^^^ that could be an issue, but if only one function per .c file ....it is just those that use a header presumably (if i was using a real make system)
<kof673>
ditto for "global variables" and such, put them in a separate .c file, if not one per file, isolate from functions, and separate .h declarations as well
<kof673>
not saying this is good, i just settled on dead stupid/simple/fine-grained a long time ago
node1 has quit [Ping timeout: 250 seconds]
masoudd has joined #osdev
<leg7>
I want to have flags that turn certain settings on/off
<leg7>
so I made a `settings.h`
<kof673>
i header guard everything...circular structs i believe needs them and then it "just works" ... again, try to do one struct per .h file :D
<kof673>
yeah i have a defines.h or similar usually :D
<leg7>
that is not my problem
<leg7>
It's about compilation
<kof673>
sure, just saying that is one place i believe header guards are *needed*
<kof673>
at least i could not be bothered to find another solution
<leg7>
I don't know what you're talking about sorry
<kof673>
*header guards help with circular structs
<kof673>
IMO some convention, any convention, is better than haphazard stuff. just pick some style and stick to it IMO
node1 has joined #osdev
node1 has quit [Client Quit]
<kof673>
also there is ccache if it gets to that point :D
node1 has joined #osdev
<kof673>
if the build system is not very smart to find exactly what changed and only rebuild that...that should at least find a roundabout way of avoiding painful slowness
oldgalileo has quit [Ping timeout: 260 seconds]
oldgalileo has joined #osdev
oldgalileo has quit [Ping timeout: 240 seconds]
<kof673>
the thing about C that i can see: #ifdef FOO #include "bar.h" #endif you basically have to run the preprocessor, and know the defines in play, to see what a file actually depends on, because of things like that <<<<<
Halofreak1990 has quit [Ping timeout: 240 seconds]
node1 has quit [Ping timeout: 250 seconds]
Halofreak1990 has joined #osdev
stux has joined #osdev
oldgalileo has joined #osdev
oldgalileo has quit [Ping timeout: 264 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
oldgalileo has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
exark_ has quit [Quit: quit]
exark has joined #osdev
foudfou has quit [Remote host closed the connection]
<geist>
leg7: there's a standard way to get the compiler to emit a .d file per .c file
<geist>
then you have the build system (make in my case) include the .d file
foudfou has joined #osdev
<geist>
that causes dependencies to work at the proper granularity
<geist>
if you modify a .h file it'll only rebuild stuff that included it
<geist>
if you have a global .h file that everything includes? yeah you gotta rebuild everything
<geist>
but if you set up your build system it should do that automatically, it just ends up being a .h that all the .c files dep on
<kof673>
well gcc and clang i believe support that...it is just what about other stuff :D
gbowne1 has joined #osdev
<kof673>
i'm not sure there is a good generic answer...because preprocessor stuff, means having to know where headers are and sizes of things and defines.... :/ nevermind could a generic tool parse compiler-specific stuff :/
<kof673>
i'm not trying to be nitpicky, just there's the rub imo
<leg7>
geist: yeah that's what I'm looking for
<geist>
what build system are you using?
<geist>
and what compiler?
<leg7>
make
<leg7>
I made something hacky
<leg7>
just now
<geist>
good, here's one of my projects, has the example of how to do it
spareproject has quit [Remote host closed the connection]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<kof673>
ftp://ftp.lip6.fr/pub/mach/mach4/knit/1.0.0/manual.pdf i might screw around with that someday, but too much work :/ see 4.1.2 "a unit file". then, to be generic, and "match" the code or header, could generate a "unit file" from an unpreprocessed version lol hairy, but will work with any compiler a bit of work, and i don't need or want the other features for now, nor an ancient haskell version :/ it ...just generates a makefil
<kof673>
e eventually
<kof673>
you could do that with "make" though i guess as well :/ just pipe it through a preprocessor lol
kristinam has joined #osdev
Arthuria has joined #osdev
bitoff__ has joined #osdev
bitoff__ has quit [Max SendQ exceeded]
bitoff_ has quit [Ping timeout: 255 seconds]
bitoff__ has joined #osdev
bitoff__ has quit [Max SendQ exceeded]
bitoff__ has joined #osdev
joe9 has quit [Quit: leaving]
chiselfuse has quit [Remote host closed the connection]