<jimbzy>
Right on, geist. Keep us posted on how it goes.
<geist>
already did all the resisters and caps. now it's a crapton of sockets to solder
<geist>
i noticed onthe rosco github they have a separate WIP project to build a 'pro' version with an 030
<jimbzy>
Interesting
<geist>
i'm tempted to look at it but i'd kinda like to figure it out on my own
<geist>
but otoh, well, i'll almost certainly never actually get to it
<geist>
this 68c681 is an interesting find though. i was kinda wondering what to do about uarts, etc
<jimbzy>
That's the dual UART isn't it?
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 260 seconds]
vinleod is now known as vdamewood
<heat>
i feel ridiculously bored doing anything wrt my os
<heat>
*sigh*
<heat>
permanent /me yawns
<Griwes>
That's why having projects to cycle through is important
<geist>
jimbzy: yah also seems to be able to do SPI
<geist>
since some lines come out of it and go to the SD card pins on the board
<heat>
Griwes, I don't have many side projects but I also don't see how that's the issue
<heat>
I just kinda feel uninspired these past few days
<heat>
i like to see it run and do stuff, that's always fun
<Griwes>
That feeling is when I know to cycle through the projects
<heat>
but lately I've been on the yearly "i should redo my build system" debacle
<heat>
and this is unproductive as shit
<heat>
i took fuchsia's whole build/ and sticked it onto my OS, started deleting pieces of it piece by piece until I ended up with nothing
<heat>
10/10
<raggi>
If you set a goal of "I must have a pristine build system" that's your project for life
knusbaum has quit [Ping timeout: 256 seconds]
eddof13 has joined #osdev
<heat>
yeah but right now my build system is actually two build systems + 2 projects with ./configure & make but one invokes the others
<heat>
and I hate it
knusbaum has joined #osdev
<klange>
still running a makefile with an attached python script that automagics library dependencies, something I set up before I had a dynamic linker when it was more of a pain to specify all of the required archives
<klange>
that python script runs in kuroko now, though
<Griwes>
My build system is cmake that invokes build systems for components and I'm pretty happy about it
<heat>
i like the idea of using gn because it doesn't assume much from the project but it's so unbelievably generic and vast that I can never find out how to do things
<Griwes>
All the things that I write have pretty dumb cmake build systems themselves
<heat>
i could use bazel but then I need to port java when I eventually self-host
<heat>
cmake... yeah I don't like cmake much
<Griwes>
But I'll be able to just invoke whatever when I want to build 3rd party stuff eventually
<Griwes>
Eh, it works
<Griwes>
And externalproject hides a lot of the complexity from you
<kingoffrance>
agree with raggi. either go full mel or don't :)
<heat>
I've never really worked with cmake tbh
<heat>
most of my impression of cmake has been from llvm
<heat>
and that's, erm, fun :P
<Griwes>
All build systems suck
<heat>
i looked at meson which seems to be the big new thing for OSS/free-desktop but as soon as you start doing compiler tests and stuff... yeah not a fan in this particular case
<Griwes>
I've done some cmake hackery for my OS project but I should not need much more of it now that all the infrastructure is in place
<dh`>
I can't imagine trying to manage a full OS build in cmake
* dh`
runs screaming
<heat>
isn't netbsd just makefiles? :P
<dh`>
"just"
<dh`>
but yeah, netbsd's build system is written in bmake
<dh`>
it is complicated enough to be a maintenance problem
<kingoffrance>
dont forget pkgsrc/ports/etc.
<dh`>
but that's partly because it was done wrong a long time ago and drastic changes are hugely expensive
<Griwes>
My cmake is a meta meta build system
<Griwes>
And since an OS is a bunch of different things stiched together, it works ok
<heat>
dh`, what alternatives are there?
freakazoid343 has quit [Ping timeout: 272 seconds]
<dh`>
for an OS build?
<heat>
yup
<dh`>
same as anything else, except it's big and complicated and needs to do a lot of unorthodox things
<heat>
it's big and complicated and needs to build other things that have other build systems and builds everything from the bootloader to chromium
<dh`>
and there's a strong tendency for build tools to be inadequate or non-general such that they'll only do simple things
eddof13 has quit [Ping timeout: 248 seconds]
<dh`>
my recommendation at this point is bmake; while bmake has many issues it's at least powerful enough
toulene has quit [Read error: Connection reset by peer]
<dh`>
and it will mostly not overtly get in your way
<heat>
makefile-based OS builds tend to end up in the here-be-dragons part of makefiles
toulene has joined #osdev
<dh`>
yes, which is why I said "bmake" and not "make" or "gmake" :-/
<heat>
is there a big difference?
<dh`>
yes
<dh`>
bmake's macro language has working loops and conditionals
<dh`>
gmake's is halfassed like everything in make has traditionally always been
<zid>
My recommendation is not to take recommendations on bu ild systems
<dh`>
(if you want a starting point, take from OS/161, not from netbsd; my advisor complains that OS/161's build system is far too complicated but it's meant for production based on long experience with netbsd's)
<zid>
that's why there's 80 of them and none of them have managed dominance
<dh`>
most people seem to begin by proclaiming that make is too complicated and ripping half of it out, thus ending up with something uselessly weak
<dh`>
(begin writing new build tools, that is)
<heat>
i like ninja because it's fast
<zid>
or 100x more complicated
<heat>
i like tools that build on top of ninja because they're easy to use and the build is fast
<zid>
make is also fast
<dh`>
didn't someone come out with something ninja-compatible and faster recently because they were tired of ninja being slow?
<heat>
make is way slower than ninja
<heat>
idk
<zid>
If you can measure how long your makefile takes to run, what the hell are you doing in your build
<heat>
incremental builds
<dh`>
bmake can be horribly slow because the implementation quality of the macro system is ... not what one wants
<dh`>
but it's a really big deal to make it better so it hasn't happened :-(
<bslsk05>
google/kati - An experimental GNU make clone (110 forks/757 stargazers/Apache-2.0)
<dh`>
make is too dynamic for that to be likely to work real well
srjek has quit [Ping timeout: 268 seconds]
<heat>
they used it in aosp I think
<heat>
before the soong thing they're using right now
<zid>
What project do you have that's more complex than say, the linux kernel
<zid>
where I'm yet to notice how long make takes to execute
<dh`>
pkgsrc
<heat>
i have a thing that builds a lot of things
<zid>
and make causes a bunch of latencies to stack up somehow because of how make is written?
<dh`>
oh that reminds me, the other thing about bmake is that -j mode actually works
<dh`>
yeah, pkgsrc is written in bmake's macro language and bmake's macro language is slow
<dh`>
it is slow because the implementation goes around parsing the same strings over and over again instead of doing any kind of intelligent text processing
<dh`>
and fixing this properly in the internals is Hard
<dh`>
anyway, this is not going to be an issue for ordinary OS builds except on very slow machines
<heat>
or very big builds
<dh`>
even then; it takes _large_ quantities of makefile text to make it a problem
<dh`>
OS/161's build system core is ~1500 lines of bmake; pkgsrc is at least 3x that
<dh`>
er
<dh`>
at least 30x that
<heat>
1500 lines is a lot of makefile
<dh`>
pkgsrc/mk/**.mk is ~38000 lines and many of the makefile fragments are not named *.mk
<heat>
anyway build systems are crap and we should build everything with a build.sh
<heat>
as written in the bible
<dh`>
that 1500 lines transparently covers stuff like cross-building and building outside the source tree and using alternate compilers and whatnot
<dh`>
good luck doing parallel builds with a sh script :-)
elastic_dog has quit [Ping timeout: 240 seconds]
<klange>
~200 for my base Makefile, ~200 for the x86-64 arch Makefile that does the bootloaders and CD ISOs, ~200 for the automatic dependency script, and... lots of 2-line generated makefiles for each of the libraries and apps.
<heat>
make is just a wrapper over some kconfig stuff and a literal make.sh script which builds it
<dh`>
netbsd's core makefiles are 7400 lines
<heat>
if that's the minimum you need for a solid build system then it's kind of a good proof that makefile just isn't it
<dh`>
it is not, netbsd's is overcomplicated
<heat>
yes but even os/161's is 1500 lines
<dh`>
well, my advisor thinks it's overcomplicated too
elastic_dog has joined #osdev
<dh`>
(I remain unconvinced, but it was meant as a dry run for making netbsd's better and it supports a lot of things nobody using os161 actually needs)
<heat>
like what?
<dh`>
also if you strip comments and blank lines it's 468 lines
<dh`>
(netbsd's is 5374)
<dh`>
building into a scratch dir from a readonly source tree is probably the biggest one
<dh`>
exact control over compiler paths, too
<heat>
os/161 looks cool
<dh`>
represents a lot of work my advisor was nice enough to pay for :-)
<heat>
way better than freakin xv6 at least
<dh`>
really needs a maintenance release
<heat>
did you work on it?
<dh`>
I wrote it
<heat>
oh nice
<dh`>
it's 10x larger than xv6 and serves a different purpose
<heat>
so you wrote a bsd-like all by yourself?
<heat>
hmm I guess that's not too hard considering you're a netbsd dev :P
<dh`>
well, sort of, the purpose of both is teaching, but the emphasis is very different
<dh`>
yeah
<heat>
dh`, how's the emphasis different?
<dh`>
xv6 is (AIUI) much more about low-level stuff
<dh`>
OS/161 comes with all the cpu-level code and it's about designing and building high-level subsystems
<heat>
maybe xv6 is changing?
<heat>
i know they switched to riscv
<dh`>
I dunno
<heat>
which is way way simpler
<dh`>
I haven't looked at it in a while
<dh`>
I have riscv code for os161, it's not that different
<dh`>
oh yeah that's another thing, last I remember xv6 wasn't meant to be portable
<heat>
yikes the toolchain is gcc 4.8.3
<heat>
that needs updating :P
<heat>
yah
<dh`>
<dh`> really needs a maintenance release
<dh`>
I actually did newer gcc and binutils last year and they haven't gotten posted yet because I didn't finish with gdb
<dh`>
:-|
<heat>
can't you just use a bsd/linux targetted gdb?
<klange>
I got 10.3 set up riiiight before 11 went through ;-;
<dh`>
one of the other things that distinguishes os161 from most teaching stuff is that it has a vfs layer
<dh`>
that was a very intentional decision based on experience with prior teaching systems where if you were trying to write a fs and it didn't work you couldn't boot
<dh`>
not to mention where copying stuff on and off the VM disk image was a giant pain
<heat>
i'd say it's also pretty important for a unix to have a vfs
<heat>
s/unix/unix-like/
<dh`>
any os you want to actually do anything with, even
<dh`>
OS/161 also uses device:path names like amigados so that nobody has to think about mount points
<heat>
around here our os-level courses have no operating systems, they're just basic POSIX tutorials + some really boring theory on schedulers & co.
<heat>
i think it's kinda sad but i'm also very biased :P
<klange>
time to spam the channel with links no one asked for and give a detailed explanation of my entirely boring build system
<dh`>
yeah, OS classes tend to divide into that kind of thing (which tend to be guts) and "write one" which tends to be highly nontrivial
<bslsk05>
github.com: toaruos/Makefile at master · klange/toaruos · GitHub
<klange>
basically half of it is building kuroko... three times...
<dh`>
you're missing a hook for the user to override stuff
<klange>
(host, normal interpreter build, and shared library build - on toaru, I build bim against the shared version, though normally on linux I'll statically link the interpreter)
<dh`>
and it doesn't support building outside the tree :-)
<klange>
I don't do out-of-tree, it complicates things with how my sysroot works.
<dh`>
I really need to post an unpacked os/161 tree somewhere so I can link into it at times like this
<bslsk05>
github.com: toaruos/auto-dep.krk at master · klange/toaruos · GitHub
<dh`>
but basically all my build systems include an optionally-existing and non-source-controlled file $(TOP)/defs.mk where things can be configured/controlled
<dh`>
because I have learned that this is important and usually overlooked :-)
<klange>
my makefile is simple enough my expectation is it should be modified directly
<dh`>
but because it's checked in, then you have uncommitted changes, or local unpushable changes
<klange>
outside of the convenience targets for launching qemu, there's not really anything to configure
<dh`>
location of the sysroot is a big one
<dh`>
but maybe you don't care :-)
<klange>
that's embedded in the compiler, normally
<dh`>
it's better if it isn't
<dh`>
I mean, the compiler has to have one compiled into it but you're better off not using that
<klange>
it can be overidden
<dh`>
because if you do then you need multiple compilers to maintain multiple sysroots
<klange>
admittedly, I see your point, and I did actually have to do a thing for exactly that
<dh`>
for OS/161 because it's for teaching I have to maintain not just the base system you can download but a string of assignment solutions as well
<bslsk05>
github.com: Onyx/Makefile at master · heatd/Onyx · GitHub
<heat>
my less horrible but half finished part of the OS where I switched build systems and now a third of it uses make, another third uses whatever dash/musl use, and another third uses gn: https://github.com/heatd/Onyx/tree/master/usystem
<bslsk05>
github.com: Onyx/usystem at master · heatd/Onyx · GitHub
<heat>
^^my builds also never have a "Nothing to do"
<heat>
there's always something that needs to be partially rebuilt
<klange>
i take some pride in the fact that my autogenerated stuff works correctly and I can have no-op make calls :P
<dh`>
recommendation: don't use dirs as make targets
<dh`>
klange: I vaguely remember something technical (not just pony stuff)
<klange>
you can use directories as make targets... if the recipe creates the directory
<dh`>
iirc somebody that year had called their own system "pony"
<dh`>
yes, but it's not a great idea to use them otherwise
<dh`>
since they get touched unpredictably
<dh`>
if you mark the targets phony so they don't actually look at the directory, it's more or less safe, but it's easy to mess that up and I _think_ I have seen makes where phony didn't work properly (though probably not in a long time)
<heat>
you see what I mean?
<dh`>
about make sucking? yeah
<dh`>
but everything else is worse
<heat>
I was talking about my build system lol
<heat>
it's (almost) a war crime
<dh`>
I have seen far worse
<heat>
oh there's worse for sure, but they're not trying to build an OS with it
<dh`>
just means they have less excuse
<dh`>
the absolute worst was a research project I had to fix up once that was written in modula-3
<dh`>
modula-3 came with its own closed-world build tool
<dh`>
because interoperability with anything else was not in their concept inventory
<dh`>
and this build tool was a custom language clearly inspired by fortran
<dh`>
actually that's giving it too much credit. more like the worst parts of pascal and csh
<dh`>
and it was totally inadequate, so the guy who'd done this research project had hacked into its internals extensively in order to be able to build his thing
<dh`>
but when I got the thing all his custom stuff had bitrotted because the current version of modula-3 had changed all the build stuff around (just churn, no significant improvements)
<dh`>
so none of it worked at all and it couldn't really be fixed because you couldn't run the damn compiler except through this garbage
<dh`>
and you had to build as root because the project consisted of several libraries as well as a program or two, and there was no way to link to the libraries without installing them first
<dh`>
and they had to go in /usr/local for some idiot reason, you couldn't build into ~/tmp or anything
<klange>
ponyos 1 and 2 were pretty shit, but at least shipped with a vaguely working compositor and had a Vim port; ponyos 3 had the new compositor and came with a prboom port, but I think still no networking...
<dh`>
OS/161 has no networking
xenos1984 has quit [Read error: Connection reset by peer]
<dh`>
there's some network hardware stuff in sys161 and I've had students write simple network code, but it doesn't come with a network stack
<dh`>
basically another question of priorities (file systems rate higher)
<klange>
PonyOS 3 was 2015; 4 skipped a year because I was moving internationally, came out in 2017, had a shoddy network stack, a package manager, came with Python, had a lot of apps written in Python, and had GCC as an available package
<heat>
building as root is so fucking cursed
<dh`>
can't remember what year it was my students ran into it
<heat>
no student should ever criticise an OS
<heat>
even if it's an elaborate april fools joke
<heat>
shits hard yo
<dh`>
they were doing their own at the time though
<dh`>
to some extent that confers privilege
<klange>
PonyOS 4 is basically ToaruOS 1.1.2; 5 is basically ToaruOS 1.2.3, the last Newlib-based build.
<dh`>
I think it was 2013
<dh`>
maybe 2011
<klange>
The first release was 2013.
<dh`>
must have been 2013 then
<klange>
And I may be _slightly_ forgiving, as ToaruOS was still pretty shit then.
<klange>
That was even before the era of equaiting it with the "tin foil Porsche".
<klange>
(shiny from a distance, but when you get up close...)
elastic_dog has quit [Ping timeout: 268 seconds]
<kazinsal>
ah, the ol "pontiac fiero in a ferrari F40 body kit"
<klange>
PonyOS actually partially exists _because_ of how not-ready-to-actually-be-released ToaruOS was for so long.
<dh`>
anyway we all wrote crap when we were learning
<dh`>
for me that was just fortunately a long way back :-)
<klange>
It was an excuse to release something that was shit because the whole thing was a joke.
<kazinsal>
for a few years in a row now I've been saying I should write some dumb and bad unix clone as an april fools joke but I never get around to it
<klange>
Still, even by PonyOS 1.0 I had a fancy compositing GUI and a not-completely-broken ext2 driver, which leaps and bounds beyond what the OS course at _my_ uni had been doing, so your students are probably little shits
<bslsk05>
www.wired.com: Tinfoil Porsche Runs on Pedal Power | WIRED
<dh`>
dunno
<klange>
The Ferdinand GT3 RS
<heat>
you should all write poor man's linux like I do
<kazinsal>
at this rate it'd be more reasonable for me to "complete" a release-ready version of my OS and release it on april fools day just to screw with people
<dh`>
if it was april they were probably doing journaling fses at the time
<klange>
Journaling FSes? In a university course? Were they in an OS-specific degree program, or were they grad students?
<kazinsal>
some days I wish I had done a full fancy university program but on the other hand I do like my job and field and also I'd want to try to get my ass a masters degree in something stupid for no good reason
<dh`>
nope, marquee/prestige class though (pretty much)
<kazinsal>
and the lady I've been seeing is finishing up her degree and has been fuckin streeessssed for the last couple weeks so I think I made the right choice
<klange>
My uni's "build an OS from scratch" course [which I infamously did not take] used a horrible little custom filesystem that students invariably referred to as "shitfs"
<kazinsal>
sometimes you just gotta clone fat16 and bolt on inodes
<dh`>
heh
<kazinsal>
(editor's note: you in fact, do not, just gotta do this)
<heat>
of course not
<heat>
you just gotta clone fat*12* and bolt on inodes
<klange>
not a single one of those systems had GUIs or even enabled graphics, and they were all team projects with a handful of devs
<dh`>
there's a reason for that: graphics is a giant pain
<dh`>
as you are doubtless aware having done it :-)
<heat>
2 options
<heat>
1) port DRM
<heat>
2) use a llvm-accelerated software renderer
<heat>
graphics are ez
xenos1984 has joined #osdev
<klange>
Back when I had a Mesa port, it was the pre-llvm swrast :)
<heat>
back in my day
<heat>
they use llvmpipe now
<heat>
you also have swiftshader which gives you llvm-accelerated vulkan
<klange>
I _think_ swrast still exists, as it's a better verification target? but I don't know, it's been ages since I looked at Mesa
<dh`>
the last time I did any low-level graphics programming was in the days of 800x600 SVGA in dos
<heat>
klange, I think they removed it
<kazinsal>
if I ever want graphics for my OS, I'm just going to find some way to port my OS to toaru
<bslsk05>
www.phoronix.com: Mesa 21.0 Has Finally Killed The Classic "SWRAST" Software Rasterizer - Phoronix
<kazinsal>
shit I don't even have a VGA console
<dh`>
OS/161 is serial console only
<kazinsal>
38400 baud serial ought to be enough for-- *is shot from offscreen*
<klange>
oh dec 2020 that's recent enough I don't feel too bad about being wrong
<dh`>
should really do something about that one of these years but it's not a priority and so will never happen
<kazinsal>
yeah my next step up will likely just end up being telnet
vimal has quit [Ping timeout: 248 seconds]
<kazinsal>
SSH will come down the line when I have a handful of other requirements sorted
<dh`>
tip: do not go near telnet itself (either the protocol or the off-the-shelf bsd implementation)
<kazinsal>
notably a new kernel core and userspace support
<klange>
I got my TTY stuff setup to have a userspace terminal emulator very early.
<dh`>
worst code I have ever handled in my life
<kazinsal>
yeah the whole telnet protocol is baffling
<kazinsal>
realistically what I'll end up with is virtual-serial-over-netcat
<dh`>
if you want to implement something like that, use rlogin
<heat>
ya got me curious now
<kazinsal>
just need me some TCP
<heat>
>rfc15????
<klange>
I did the initial handshake stuff in `nyancat` ages ago, at least enough to communicate size and terminal name
elastic_dog has joined #osdev
<kazinsal>
heat: telnet is OLD
<heat>
oh boy, 1969
<kazinsal>
the latest standard iteration of telnet is STD8, which corresponds to RFCS 854 and 855
<klange>
telnet is basically some escape sequences to send 'out of band' data over what is otherwise a dumb pipe that sort of emulates a serial line
<kazinsal>
in May 1983
<dh`>
there are assorted RFCs with extensions much later than that
<dh`>
even if you ignore the (multiple) April 1 extensions
<kazinsal>
rlogin is... 1282 it looks like
<kazinsal>
there's some interesting telnet extensions for authentication
<dh`>
at one point I collected up copies of all the telnet-related RFCs
<kazinsal>
I kinda want to fiddle with those on my VAX and see if I can build a working automatic SSH to Telnet bridge with it
<dh`>
there's a lot
<dh`>
I eventually came to the conclusion that the existing bsd telnet code is unsalvageable
<heat>
they should make an april 1 rfc that says "officially delete telnet" but accidentally publish it on april 2nd
<dh`>
if anyone needs a telnet implementation enough to spend more than five seconds on it, that code should be burned at the stake; it will be much cheaper to start over
<dh`>
even given all the hacks and special cases and undocumented bug compat bits
<klange>
frankly, if you need anything more out of a telnet implementation that what you would get by literally just throwing a normal tty session over the wire, you probably want _a lot_ more and need ssh...
<dh`>
yeah
<dh`>
at this point telnet is firmly dead and it should stay that way
<kazinsal>
yeah
<klange>
you want authentication on your unencrypted pipe? sweet mother of mercy...
mahmutov has quit [Ping timeout: 246 seconds]
<kazinsal>
telnet's existence is a security hole
<heat>
but router tho
<heat>
:(
<kazinsal>
rlogin's existence is a security through obscurity hole
<dh`>
any router old enough that you need telnet to talk to it is too old and slow to be useful
<clever>
i think ive only owned 2 devices that where telnet only
<clever>
my dsl modem, and a cisco 100mbit managed switch
<clever>
the dsl modem was 600kb/sec down
<clever>
and both have been retired because they became bottlenecks
<kazinsal>
yeah, you've gotta find some real old ios images to not have ssh
<clever>
this ios image has a major security hole
<kazinsal>
I think the oldest I've got is a 2600 series router and even it's got ssh
<kazinsal>
albeit really slow
<clever>
you can download the entire config file without authentication
<kazinsal>
it's running 12.0 iirc
<clever>
the password is in the config file....
<heat>
my router (technicolor) is modern and you can use either http or telnet
<dh`>
much of the horror in the telnet code is because it tries to handle flow control
<dh`>
which is mostly pointless now
<kazinsal>
hmm. UTF-8 will never actually encode anything as an FF byte... this makes it rlogin-compatible
<kazinsal>
also, big fan of rlogin using the URG TCP flag
<dh`>
(also if you look at the telnet code, be advised that you will not discover most of the awful until you try to modify it)
<kazinsal>
not sure if I've ever seen a protocol use URG in a meaningful way
<dh`>
telnet does
<kazinsal>
rlogin uses it to mean "this byte in this segment is a control byte; act upon it but do not echo it to the display"
<dh`>
telnet uses it as part of the flow-control goo
<dh`>
iirc if you have the right things hooked up it will send URG to mean "the regular data you are about to receive is now junk so you can throw it out instead of displaying it"
<dh`>
...I think
the_lanetly_052 has joined #osdev
<kazinsal>
god this has me diving into a TCP rabbit hole
<kazinsal>
which is making me remember I need to go recert my CCNP and there's probably going to be godawful questions about FECN and BECN on it eeuuuugh
<kazinsal>
because lol frame relay stuff is still relevant to the people at the cisco certification think tank
the_lanetly_052_ has quit [Ping timeout: 268 seconds]
heat has quit [Ping timeout: 260 seconds]
ThinkT510 has quit [Quit: WeeChat 3.5]
ThinkT510 has joined #osdev
nyah has joined #osdev
jeaye has quit [Quit: WeeChat 3.3]
jeaye has joined #osdev
mahmutov has joined #osdev
Likorn has joined #osdev
mahmutov has quit [Ping timeout: 248 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vimal has joined #osdev
mahmutov has joined #osdev
GeDaMo has joined #osdev
enkeyz has joined #osdev
Burgundy has joined #osdev
mahmutov has quit [Ping timeout: 272 seconds]
the_lanetly_052 has quit [Ping timeout: 248 seconds]
the_lanetly_052 has joined #osdev
pretty_dumm_guy has joined #osdev
the_lanetly_052 has quit [Ping timeout: 268 seconds]
pretty_d1 has joined #osdev
pretty_d1 has quit [Client Quit]
pretty_dumm_guy has quit [Ping timeout: 246 seconds]
mahmutov has joined #osdev
vimal has quit [Ping timeout: 260 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
srjek has joined #osdev
Likorn has joined #osdev
vimal has joined #osdev
srjek has quit [Ping timeout: 268 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
the_lanetly_052 has joined #osdev
gog has joined #osdev
gog has quit [Client Quit]
hbag has quit [Remote host closed the connection]
gog has joined #osdev
enkeyz is now known as l33tc0d3r
l33tc0d3r is now known as enkeyz
friedy10- has joined #osdev
freakazoid333 has joined #osdev
enkeyz has quit [Quit: WeeChat 3.4]
enkeyz has joined #osdev
heat has joined #osdev
freakazoid333 has quit [Ping timeout: 260 seconds]
gildasio has quit [Remote host closed the connection]
theseb has joined #osdev
<theseb>
C include files typically include just function defintions but can you also INVOKE FUNCTIONS in a C include file?
<j`ey>
yes
<theseb>
yea!
<theseb>
thanks!
<bauen1>
theseb: `#include` in C does little more than literally copy-paste the included file at that location
<theseb>
j`ey: so really code in an include file is "just like" code in regular files!
<j`ey>
yep
<theseb>
in fact...i'm guessing after the preprocessor does the including...the compiler doesn't even see the includes
<j`ey>
yep
<theseb>
bauen1: thanks...good 2 no
<heat>
it does see includes for debugging purposes
<heat>
__FILE__ for instance will be the header afaik
<j`ey>
yeah
<theseb>
oh wait...suppose you have an init function invoked in an include with function definitions....now suppose you include that include file in multiple places.....you just invoked your init function multiples times....that may be bad
<heat>
static inline
gog has quit [Quit: byee]
<heat>
wait huh?
<heat>
you can't invoke a function outside of a function
<heat>
so unless you invoke that function multiple times, that will only run once
<theseb>
heat: if you invoke a function in an include file that is included in 10 places....you'll invoke said function 10x yes?
<heat>
no
<heat>
can you give me an example?
<theseb>
int f() { printf("hello\n"); } ....f();
fwg has joined #osdev
<theseb>
the include file defines f and invokes f later
<heat>
you cannot do that
<heat>
that is not valid C
<theseb>
if i do #include "f.h" in different places I'll see "hello\n" multiples times!
<theseb>
heat: what is wrong w/ it?
<heat>
you can't have a function call outside of a function?
<theseb>
heat: wait...you have to define functions to use them later? am i missing something?
<theseb>
heat: does "function call" = "invoke function" = use it?
<geist>
that's the lower/higher memory fields. that's the legacy stuff
<geist>
that's not the array of entries part, which is the actual interesting stuff
<scripted>
how do I get that? is there an osdev article for that?
<geist>
cripes we went through this *whole thing* the other day
<geist>
it's where the mmap has a pointer to an array of fields
<geist>
array of structs, each with a type and base and length thing
<geist>
you parse those till you hit the end
<geist>
it's in th emultibootspec. it's what we were *talking about* the other day
<scripted>
yeah sorry I concentrated on hex numbers instead
<geist>
frankly if this is too difficult i'd highly suggest finding another hobby for now. this sort of stuff is... extremely basic compared to what you're signing yoursel fup for
<geist>
this is kinda like saying you're going to build a train and having trouble figuring out what a screwdriver is
vin has quit [Remote host closed the connection]
<geist>
look in the multiboot spec it describes it
<scripted>
geist: its fine
<geist>
that *should* be enough, if you're ready for this sort of thing. if you can't read the spec and figure it out from there, then probably you should work on something a little simpler for now
<geist>
since *most* of early osdev is reading docs, specs, etc and trying to figure out how to use the complex hardware/software in front of you
<scripted>
I will read the spec
<geist>
having an osdev article or tutorial is nice but it should *not* be a requirement for forward progress
<geist>
dont rely on them as crutches. specs and directed questions should be good, but please dont ask us 'what should i do' questions, since that just implies you are looking for someone to hold your hand
<scripted>
okay
<geist>
anyway, nuff said
scripted has quit [Quit: WeeChat 3.5]
<geist>
just had to get that off my chest out of last weekend where we spent like 3 hours here on hex numbers
<geist>
maybe that'll get em on track. hate to be hard on em but sometimes they need some tough love
<jimbzy>
Neat. I got an 15" HP craptop on sale today. Ryzen 5 5500U for $300+tax
<geist>
oh noice
<geist>
if it has a decent keyboard and a workable trackpad, lots of low to mid range laptops are pretty usable nowadays
<geist>
just got a Thinkpad E15 yesterday for work to hack fuchsia onto it, and it's a half decent computer. just kinda cheap, but the keyboard is nice
<Ermine>
congrats!
<jimbzy>
They're not terrible.
<jimbzy>
It only has 8gb of ram, so I'll double that and it should be a nifty little laptop.
<jimbzy>
I hate to give up my Lenovo, but it's just falling apart on me. Batteries are shot, memory is failing and it's only 14"
<jimbzy>
Been a good little machine, tho.
<geist>
yah
<heat>
kind of a weird question but is there a way to get a normal keyboard layout on a macbook?
<jimbzy>
I was gonna build a desktop, but the price and availability of components made me weary. It was going to be Ryzen 5-based, too, so I figured what the hay.
<geist>
yah the gpus are the hard one, though you can use the builtin gpu if you want
<geist>
heat: hmm, whatcha mean?
<zid>
2nd hand prices are nothing and chips have been more or less the same for 10 years
<zid>
it's just gpus
<jimbzy>
CPU's with decent integrated graphics are crazy expensive.
<zid>
if you can secure a gpu, the rest is damn near free in comparison :P
freakazoid333 has quit [Ping timeout: 240 seconds]
<heat>
geist, at least with the pt layout, the layout is slightly different from the regular layout you see on "normal" keyboards
<zid>
I think my entire machine without the gpu costs $200
<zid>
case, psu, mobo, cpu
<geist>
lemme guess, zid is... talking about a 10 year old xeon machine
<jimbzy>
Yeah I was looking at $500 for everything but the GPU and like $800-infinity with one.
<zid>
yea sounds about right
<heat>
work asked me for my preferred work laptop, I asked for a macbook pro, but a few weeks back I tried out a pal's macbook and I couldn't even find the {}
<geist>
heat: alas no. i dont know
<zid>
500 if you include storage or maybe something zen3 not zen2
<zid>
and then infinity dollars for a gpu
<zid>
adds up
<heat>
how am I going to write C++ without curly braces ;_;
<zid>
do macbooks come in iso
<geist>
heat: i dunnot what the 'pt' layout is. is that country code pt?
<heat>
yes
<zid>
portugal
<zid>
is a silly country
<heat>
no u
<j`ey>
heat: where did you take the job in the end?
<jimbzy>
I think I was looking at the Zen 5 5600G because it has the Vega gpu which isn't terrible.
<zid>
It's like better spain
<jimbzy>
Like $200 more than the 5600X
<geist>
aah. well, i think you can just change the layout in the settings panel
<geist>
though it wont line up with the key labels
<geist>
and yeah i think they come in ISO
<geist>
but they come in all sorts of layouts
<zid>
I don't care what's on the keys, but I need iso
<heat>
j`ey, cloudflare
<heat>
fully/mostly remote, close to home and I don't need to move to london for 3 months
<j`ey>
heat: nice
<zid>
(otherwise ' transposes to enter, and enter transposes to \)
<geist>
huh i thought you were in the western hemipshere, heat
<geist>
i lose track of who is where
<jimbzy>
The Internet: Bringing People Together
<heat>
i'm technically in the western hemisphere :P
<geist>
well, okay in the Americas
<heat>
that might be because I frequently do late night irc :P
Brnocrist has quit [Ping timeout: 246 seconds]
freakazoid333 has joined #osdev
Brnocrist has joined #osdev
<jimbzy>
geist, you finish up your rosco?
<geist>
nah got it about halfway
<geist>
about to get started on it some more
<geist>
got all the passive stuff on yesterday, now will start on the sockets
<zid>
when I was a kid the housewives used to screw PVC elbow joints together by the sackful for a bit of extra money
<zid>
I'd like that but for soldering up boards
iomonad has joined #osdev
freakazoid333 has quit [Ping timeout: 256 seconds]
wootehfoot has joined #osdev
demimos has joined #osdev
Burgundy has joined #osdev
freakazoid12345 has joined #osdev
freakazoid12345 has quit [Read error: Connection reset by peer]