channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=8&d=18
01:09:08 <griddle> Does anyone know of any useful scripts I can use to make my rootfs disk image?
01:15:18 <klange> `tar`
01:15:50 <klange> I believe someone also pointed you towards genext2fs if you want a "real" filesystem.
01:32:50 <griddle> Yeah, though i'd like to use grub and an mbr partition for the boot and root fs
01:34:14 <klange> I'd avoid building hard disks as part of your normal process. It's a pain in the butt on every platform.
01:34:27 <klange> Installing Grub to disk images at all is a nightmare.
01:34:48 <bluezinc> well, there is grub-mkrescue
01:34:51 <klange> CDs are way easier to build. Grub has its mkrescue tools for building bootable CDs
01:35:24 <griddle> so have the OS on a cdrom from mkrescue and a filesystem seperate?
01:35:25 <bluezinc> and I guess you might technically be able to just dd an iso to a hard drive and effectively boot a livecd.
01:35:43 <bluezinc> griddle: yes
01:35:53 <klange> My suggestion for your typical build is to make a C with a ramdisk in whatever format you want.
01:35:57 <klange> CD*
01:36:42 <klange> I used to use genext2fs and had ext2 ramdisks, I moved to tar because it was a lot more flexible and I was relocating everything to an in-memory filesystem on boot anyway
01:37:05 <griddle> so you have a tarfs as your initrd?
01:40:46 <klange> My CDs are a bit complicated. I use my own bootloaders and have a BIOS and EFI loader on the same image.
01:42:20 <klange> The contents of the CD are in a FAT image for EFI support, generated with mtools, and the CD filesystem has shadow entries for all the files in the FAT for the BIOS loader which understands ISO9660. The base CD has the kernel, modules, network init, and the ramdisk, which is an uncompressed tarball.
01:42:54 <klange> The bootloaders implement multiboot, and the kernel is loaded as a multiboot image alongside the modules and ramdisk which are provided as multiboot "modules".
01:43:20 <griddle> ah, okay
01:43:56 <klange> The kernel mounts the tarball initially as the read-only root filesystem, and if a kernel commandline "migrate" parameter is present a startup application runs that does a deep copy of the tar image into an in-memory read-write filesystem.
01:47:50 <klange> When I was doing ext2, those were mounted read-write (since they were copies in memory anyway), but you'd effectively have no free space because I built them to be as small as possible.
01:48:36 <klange> But genext2fs is terrible, uses way too much RAM when running, was abandoned before a final release could be cut with a bunch of features that the Debian version ships...
01:49:09 <ybyourmom> No one has ever done that in the history of osdev!
01:49:12 <klange> tarballs were much more flexible for building ramdisks; just tar up a directory, and you know you've got an optimally-sized image and it'll be made quickly.
01:54:16 <griddle> Hmm I am starting to like the tar idea lol
01:54:38 <griddle> though, my kernel isn't very complicated right now, not really sure I need an initrd yet :)
05:34:23 <Ameisen> Interesting - llvm doesn't perform recursive inlining
05:39:35 <izabera> https://github.com/izabera/bsed i was young and naive
05:39:45 <izabera> i think i'm gonna finish it
05:39:48 <Ameisen> now write a bash in sed
05:39:54 <izabera> just need to implement negative commands and addresses
05:40:12 <izabera> Ameisen: i wrote a brainfuck interpreter in sed and that was enough
05:40:27 <Ameisen> I wrote a brainfuck interpreter in order to test my virtual machines :|
05:40:34 <Ameisen> that's how I benchmarked my MIPS emulator
05:40:59 <Ameisen> brainfuck version of the mandelbrot set
05:41:00 <ybyourmom> facts
05:41:17 <Ameisen> write sed in brainfuck
05:41:25 <Ameisen> or anything, really
05:42:30 <izabera> why are you not impressed
05:42:33 * izabera sad
05:42:51 * Ameisen is never impressed
05:42:55 <Ameisen> I want a brainfuck backend for LLVM
05:42:57 <Ameisen> so I can compile to it
05:43:40 <izabera> Ameisen: https://github.com/shinh/elvm
05:44:07 <Ameisen> but does it generate optimal code?
05:44:37 <Ameisen> honestly, the backend that generates C++14 constexpr code could actually be useful
05:48:50 <ybyourmom> Finally getting serious about unit testing in my kernel
05:49:10 <ybyourmom> I'm prolly going to neglect it by next week though
05:49:45 <ybyourmom> But this sense of accomplishment and the high I get from feeling like I'm a disciplined person
05:50:07 <ybyourmom> Unmatched by any other self indulgent delusion
05:54:16 <griddle> Anyone know how to get threadlocal things working in c++?
05:58:28 <griddle> Oh it seems like it uses hte fs segment
10:04:12 <ybyourmom> lalilulelo: the la li lu le lo??!!!
13:08:45 <lalilulelo> ybyourmom, just GW here
19:37:31 <Ameisen> Out of curiosity, what's the rationale for FreeBSD having its libc as part of its kernel source and build, rather than having a separate libc (like glibc or musl)?
19:37:47 <zid`> #freebsd? :P
19:38:04 <Ameisen> never!
19:38:07 <Ameisen> y'
19:38:10 <Ameisen> y'all are smarter.
19:38:31 <zid`> presumably they did a "gnu/linux" but a "freebsd"
19:38:38 <zid`> which is their posix extensions + their kernel
19:39:08 <zid`> whereas for gnu linux you build them seperatately, they're both their projects so they build together
19:39:15 <_mjg> Ameisen: freebsd does not have "libc as its kernel source and build"
19:39:21 <_mjg> it has *everything*
19:39:31 <_mjg> and this is historically how operating systems have been done
19:39:40 <zid`> I bet there's a single build command for windows
19:39:42 <_mjg> if anything it's linux which is separate
19:39:44 <zid`> that makes calculator and the kernel together
19:39:54 <Ameisen> _mjg - if it has everything, it has libc as well...
19:40:05 <_mjg> if it has everything then singling libc is odd
19:40:11 <_mjg> which is part of my point
19:40:42 <_mjg> the /upside/ is that they are both always in sync
19:41:25 <_mjg> glibc always has to worry about running on a very old kernel and has to account for it
19:41:34 <Ameisen> you are a freebsd developer, aren't you?
19:41:40 <_mjg> i am, yes
19:42:00 <zid`> freebsd/freebsd/freebsd doesn't need to be three projects like gnome/gnu/linux
19:42:19 <zid`> so why version them seperately
19:42:28 <Ameisen> I feel like the horrible things I've hacked onto that kernel in the past would infuriate you :P
19:42:49 <_mjg> some people have a mistaken idea that bsd people have sophisticated taste
19:42:54 <_mjg> they really don't
19:43:02 <_mjg> source: i know many
19:43:06 <zid`> bsd is for simple people
19:43:08 <zid`> who can't handle linux :P
19:43:26 <Ameisen> I like hacking the FreeBSD kernel to try things because it's usually easier to hack apart than Linux is.
19:43:35 <_mjg> stupid jokes aside, an argument can be made for developing th ekernel separately from the rest
19:43:51 <_mjg> but it's not the default take, or at least was not until linux started dominating the market
19:44:11 <zid`> it's not even like the linux kernel developers itself together
19:44:16 <zid`> they break each other's shit all the time
19:44:18 <Ameisen> before the dark times, before the gnu/empire
19:44:57 <zid`> linux kernel itself is just a scale down version of a distro internally to itself imo
19:44:59 <zid`> scaled*
19:45:14 <zid`> various 'packages' all trying to loosely stay in sync with each other so it actually works
19:45:16 <Ameisen> the fact that the Linux kernel actually functions is sometimes amazing to me.
19:45:26 <Ameisen> it doesn't have much internal cohesiveness
19:45:32 <_mjg> you know, just becaue i'm affiliated with bsd does not mena i'm going to shit on linux
19:45:53 <Ameisen> sure, but I'm not affiliated with either!
19:45:58 <_mjg> i think for the most part the linux kernel is developed with a higher standard than any of the bsds, at least when it comes to the core kernel
19:46:15 <zid`> that's because they have a linus who has spent 25 years drilling into the maintainers not to break shit
19:46:19 <_mjg> at the very least the code is much beaten up in productoin before it goes in
19:46:25 <Ameisen> Oh, I don't doubt that in terms of functionality it is a high standard. It just seems to lack cohesiveness. One part of it tends to be very different from another.
19:46:31 <Ameisen> Basically like looking at a completely different codebase.
19:46:56 <zid`> It's pretty much the only way to make something that big change so much
19:47:01 <_mjg> well i think if you ignore staging/ it's not THAT off most of the time
19:47:11 <zid`> divide it into corners, everyone works in their own corner, make them work together at the end
19:47:12 <_mjg> apart from maybe cifs which was clearly not written by a standard kernel person
19:47:18 <Ameisen> Yeah, but that's also why I am usually impressed that it _works_
19:48:01 <Ameisen> though I'm presently still fighting with the freebsd build system
19:49:34 <_mjg> when it works it's great
19:49:39 <_mjg> when it does not... well
19:49:45 <Ameisen> Sure, I'm just not doing something that's supported
19:49:50 <Ameisen> so... trying to make it work
19:50:34 <_mjg> if there is one nice thing about bsd it's that you are provided with easy build/test cycles
20:15:55 <moondeck> hello
20:16:02 <moondeck> whem it's been a while :D
20:24:35 <moondeck> so, the wiki says i should make my kernel multithreaded early on, but the article on that is missing. Could anyone tell me more?
20:26:00 <zid`> it may be hard to make things happen you didn't plan to have happen.
20:26:05 <zid`> (duh)
20:28:26 <moondeck> well, hard to plan it if you can't read about it on the wiki
20:30:12 <zid`> why would you need to read about it
20:30:56 <moondeck> i usually read to gain knowledge about a certain thing
20:31:26 <moondeck> and being that i lack knowledge on how threads are supposed to work in a kernel, i'd like to read about that
20:31:40 <moondeck> like, i know how threads work yeah
20:44:19 <Ameisen> _mjg - starting to think that I'm not going to be able to easily get freebsd to build on linux.
20:44:31 <_mjg> uh
20:44:35 <_mjg> no idea about this one
20:45:11 <_mjg> hm now that i said it there was at least one guy who was working on this, give me a sec
20:45:40 <_mjg> why are you trying to do this though?
20:47:18 <mrvn> Why don't you dpkg --add-architecture amd64-kfreebsd; apt update; apt install kernel?
20:48:31 <Ameisen> _mjg - I prefer to have it be buildable from any unix-y environment for what I'm doing
20:49:02 <Ameisen> mrvn - I feel like that wouldn't properly work.
20:49:35 <Ameisen> the main issue is that the freebsd tools available for linux aren't complete (or are outdated) so some parts of the build system are just failing
20:50:08 <mrvn> Ameisen: should install fine. Probably won't boot unless you install some other debs from kfreebsd too
20:50:10 <Ameisen> tsort, mktemp, are acting up atm
20:50:47 <mrvn> Ameisen: you need bsd tools, not linux tools. :)
20:50:51 <Ameisen> I know.
20:51:03 <Ameisen> the bsd versions of those aren't part of the freebsd tools for linux packages
20:51:06 <Ameisen> :(
20:51:12 <mrvn> It's sad that they aren't compatible enough for the kernel to compile
20:51:47 <mrvn> Ameisen: kfreebsd source in debian might be patched
20:52:27 <mrvn> Ameisen: At least they somehow have to build the deb under kfreebsd.
20:53:51 <Ameisen> wow that has a lot of patches
23:59:34 <ybyourmom> 19:39 < zid`> that makes calculator and the kernel together
23:59:38 <ybyourmom> lol