klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
heat has quit [Remote host closed the connection]
heat has joined #osdev
Burgundy has quit [Ping timeout: 245 seconds]
heat has quit [Remote host closed the connection]
Clockface has joined #osdev
gog has quit [Remote host closed the connection]
Matt|home has quit [Quit: Leaving]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<Clockface> can SIGALRM get schedualed within the handler of SIGALRM?
mahmutov has quit [Ping timeout: 260 seconds]
heat has joined #osdev
<heat> Clockface, define scheduled
<heat> can you get a signal queued? yes
<heat> can you get signaled by that same signal? no, when handling a signal it implicitly gets added to the blocked set
<heat> s/signaled/interrupted/
sonny has joined #osdev
<klange> you can always remove it :)
<heat> yeah nothing a good sigprocmask can't solve
nyah has quit [Ping timeout: 272 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<bslsk05> ​twitter: <mjg59> The real reason Open Firmware lost is that the intersection of the people who've learned how to do hardware bringup and the people who know Forth is approximately 0, and UEFI recognised that
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<moon-child> 'Worse is Better, but for your system firmware'
<moon-child> eesh, no need to rub it in
heat has quit [Ping timeout: 260 seconds]
srjek has quit [Ping timeout: 240 seconds]
<geist> yah word
<geist> mjg: truth
<moon-child> that's not the same mjg :P
<geist> well, okay
<mrvn> The goal of forth was to have plugin cards work on any hardware.
<geist> yah and uefi tried to do it with their own bytecode, though i guess that hasn't really caught on
<mrvn> Trying to get PCI cards to work on Alpha was a pain because you couldn't run the rom.
<mrvn> I guess nowadays you would have java or javascript or something.
<mrvn> They should just have a C compiler in the rom and compiler device setup code from source.
<mrvn> Smallest C compiler is below 1k I think.
<geist> well, that's what forth or the uefi bytecode is supposed to solve
<geist> problem is you need to have the will for vendors to do it
<mrvn> Don't give them a choice. :) Only allow compiling C code.
<mrvn> or only bytecode.
<Griwes> actually if sane people were making the decisions today without the baggage of aml and whatnot, you'd make all the bytecodes be webasm or something in that vein
<mrvn> but I guess then we would still have BIOS as primary boot method.
freakazoid343 has quit [Read error: Connection reset by peer]
<mrvn> The idea of using C source would be that existing code will likely be C already so you only have to work around some compiler quirks for the simpler bios C compiler.
<mrvn> Griwes: you think it would be simple to make webasm interact with real hardware and bit banging easily?
<Griwes> maybe not "simple", but I don't think it'd be terrible either
kkd has quit [Ping timeout: 260 seconds]
<Griwes> you'd probably have some sort of an interface in a different webasm module, which also makes you able to switch between s
<Griwes> ...between good perf and safe implementations
<Griwes> on a per-device or per-table basis, probably
<mrvn> screw good perf. This is boot stuff. Saving 0.1s there is irrelevant.
<Griwes> right. I'm just saying it should be trivially possible to have a choice
<mrvn> You probably waste more time on sleeps during bootup than optimization would save.
<Griwes> also it may matter for runtime bytecode services, if any
<Griwes> your OS could also plug different implementations of the hal interface into those
<Griwes> but we all know this will never happen, so... :)
<mrvn> Is anything but toy project actually using EFI services?
<mrvn> they are called boot services for a reasonl.
<Griwes> aren't efivars accessed through runtime services?
<mrvn> Griwes: EFI defines two types of services: boot services and runtime services.
<Griwes> yes, and c is a weakly typed language.
<Griwes> you asked, presumably, about runtime services
<mrvn> No. I was talking about boot services.
<mrvn> Do devices provide runtime services?
<Griwes> oh, i see what you are asking, I lost a bit of context there
<Griwes> by "runtime bytecode services" I didn't necessarily mean uefi
<mrvn> You might have a point about optimizing runtiume services if they include any device drivers.
<Griwes> I mean things like aml bytecode or pieces of device roms
<mrvn> I think nowadays nothing used device roms at runtime. Probably mainly because the 16bit code won't work in long mode and such.
<Griwes> but it would be fine if roms have been implemented in webasm ;>
<Griwes> you'd just load their modules and run them
<mrvn> Or even more readable forms
<mrvn> And once booted you can upload firmware blobs to get optimized performance.
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
bradd has quit [Ping timeout: 256 seconds]
fkrauthan has quit [Quit: ZNC - https://znc.in]
fkrauthan has joined #osdev
bradd has joined #osdev
sonny has quit [Quit: Client closed]
GeDaMo has joined #osdev
CaCode has joined #osdev
mahmutov has joined #osdev
mahmutov has quit [Ping timeout: 272 seconds]
C-Man has quit [Ping timeout: 240 seconds]
Rooftop_Joe has joined #osdev
ravan has quit [Read error: Connection reset by peer]
Jari-- has quit [Ping timeout: 272 seconds]
mahmutov has joined #osdev
CaCode_ has joined #osdev
Ali_A has joined #osdev
CaCode has quit [Ping timeout: 272 seconds]
Rooftop_Joe has quit [Quit: Client closed]
Likorn has joined #osdev
Likorn has quit [Quit: WeeChat 3.4]
Likorn has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
Likorn has quit [Client Quit]
Likorn has joined #osdev
Burgundy has joined #osdev
CaCode- has joined #osdev
CaCode_ has quit [Ping timeout: 260 seconds]
kkd has joined #osdev
kkd has quit [Remote host closed the connection]
kkd has joined #osdev
Ali_A has quit [Quit: Connection closed]
lainon has joined #osdev
lainon has quit [Remote host closed the connection]
nyah has joined #osdev
gog has joined #osdev
CaCode_ has joined #osdev
CaCode_ has quit [Remote host closed the connection]
CaCode- has quit [Ping timeout: 260 seconds]
kingoffrance has quit [Ping timeout: 240 seconds]
C-Man has joined #osdev
Stary has quit [Quit: ZNC - http://znc.in]
CompanionCube has quit [Quit: ZNC - http://znc.in]
kingoffrance has joined #osdev
Stary has joined #osdev
CompanionCube has joined #osdev
srjek has joined #osdev
srjek|home has joined #osdev
mahmutov has joined #osdev
srjek has quit [Ping timeout: 256 seconds]
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
Likorn has quit [Quit: WeeChat 3.4]
Likorn has joined #osdev
Likorn has quit [Client Quit]
Likorn has joined #osdev
Likorn has quit [Quit: WeeChat 3.4]
Likorn has joined #osdev
Likorn has quit [Client Quit]
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
dude12312414 has joined #osdev
<catern> anyone know of a USB driver vulnerability? I want to use it as an example of why you can't trust hardware just because it's on your local bus
<catern> (i'm already mentioning https://en.wikipedia.org/wiki/Thunderspy )
<bslsk05> ​en.wikipedia.org: Thunderspy - Wikipedia
<catern> or other examples of "hardware in a local system can be malicious too, you can't just trust it"
<bslsk05> ​en.wikipedia.org: BadUSB - Wikipedia
<catern> that page only mentions attacks on software
<GeDaMo> It's a USB memory stick that can also appear as keyboard and mouse then access your computer
<catern> yes i'm talking about lower-level vulnerabilities
<catern> if a USB stick just appears as a regular keyboard, you can have your OS just ignore it
<catern> not if it does some protocol-level attack to exploit a vulnerability in your OS's USB implementation, or the USB hardware
<GeDaMo> How do you know to have your OS ignore it?
<catern> for example you could ignore all keyboards plugged in after initial boot
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<catern> or only allow keyboards to be plugged into a specific port
<catern> or only allow the built-in keyboard, if you have one of those
<catern> so that kind of attack ("plug in a keyboard") are frankly pretty boring and easy to mitigate
<geist> iirc there was at least one on playstation 3 i think
<geist> was basically a kernel sploit
<catern> https://en.wikipedia.org/wiki/PlayStation_3_Jailbreak#Inner_workings ah yeah sounds like it, thanks geist !
<bslsk05> ​en.wikipedia.org: PlayStation 3 Jailbreak - Wikipedia
<bauen1> catern: you already know about usbguard i presume, but maybe digging around some of the github issues could give you further ideas
<GeDaMo> Are any of these of interest? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=usb ?
<bslsk05> ​cve.mitre.org: CVE - Search Results
Ali_A has joined #osdev
the_lanetly_052 has quit [Quit: Leaving]
<Ali_A> This might not be an OSdev question but I don't know other places to ask such question
<Ali_A> under x86 linux (SYSV ABI)
<Ali_A> I am trying to understand why do I see a lot of this in linker scripts
<Ali_A> . = 0x1000
<Ali_A> /some stuff goes here
<Ali_A> . = 0x8000000 //other stuff goes here
<Ali_A> I thought the stack size is usually 1MB per process?
<Ali_A> but according to this picture it seems to be 128 MB
<Ali_A> and to quote them >  The stack resides immediately below the text segment, growing toward lower addresses. This arrangement provides a little over 128 MB for the stack and about 2 GB for text and data.
<GeDaMo> The stack size is what you make it
<Ali_A> GeDaMo so there is no convention to make it 1MB or 2 MB or anything? I can make it as big as I want (almost as big as I want, as I know there should be some OS reservation for the process)
<zid> If you're asing for a review of a specific linker script
<zid> it helps to post the specific linker script
srjek|home has quit [Ping timeout: 260 seconds]
Likorn has joined #osdev
srjek has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
nopenope[m] has quit [Quit: You have been kicked for being idle]
scripted has joined #osdev
<scripted> Hello people. I'm stuck with this page frame allocator I tried to write using a tutorial. So the issue is that the both variables (end_mmap_addr and curr_mmap_addr) are 0, so I think I've made a mistake while passing the multiboot structure. The line I'm talking about is 20 https://github.com/ScriptedDeveloper/CrazeOS/blob/unstable/src/pageframe/pageframe.c
<bslsk05> ​github.com: CrazeOS/pageframe.c at unstable · ScriptedDeveloper/CrazeOS · GitHub
dzwdz has joined #osdev
<dzwdz> i hope getting back in this channel will peer pressure me into actually working on my OS lol
<scripted> dzwdz: don't worry, I halted OSdev development for an entire week
<scripted> *my
<dzwdz> > week
<dzwdz> i haven't really worked on mine since november
<scripted> dzwdz: that's bad, get your lazy ass up or help me
<dzwdz> i've got a bunch of work done over the weekend
<scripted> I'd study osdev like 5/7, but school is really stopping me to do so
Likorn has quit [Quit: WeeChat 3.4]
<dzwdz> school is really stopping me from... everything
<dzwdz> i'm too exhausted to do anything once i'm home
Likorn has joined #osdev
<scripted> dzwdz: I know exactly how you feel, it's keeping your energy away from your hobbies
<scripted> but then you still have to do homework, after you finished with that you either have to go to sleep or do some stupid shit like watching youtube or something since you are so exhausted
ephemer0l has quit [Ping timeout: 240 seconds]
<dzwdz> so anyways, does anyone know if i can somehow get GRUB to boot my kernel in the vga text mode?
<GeDaMo> Does adding a vga=3 to the kernel line in grub work?
<GeDaMo> I'm looking at this which is about Linux but it may work https://cromwell-intl.com/open-source/grub-vga-modes.html
<bslsk05> ​cromwell-intl.com: GRUB and VGA Modes
<bslsk05> ​en.wikipedia.org: VGA text mode - Wikipedia
<dzwdz> aren't all those parameters parsed by linux and not by grub?
<dzwdz> i'll try
alpha2023 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<dzwdz> nope, didn't work
<bslsk05> ​pierre.baudu.in: GRUB VGA Modes
<GeDaMo> Maybe it only supports specific modes
<gog> i'm doing it, i'm writing my own EFI headers
<gog> this sucks
<gog> and the spec document is riddles with typos
<zid> my monitor bit flipped again
<gog> ope
<zid> decided that pixel 1024 was the first pixel
<gog> is this your trusty crt?
<zid> fun effect, left and right sides of the display swapped
<zid> no, crts don't have firmware :p
<gog> yes they do
<gog> what is EDID?
<clever> gog: i think originally, just an i2d rom
<clever> i2c rom*
<gog> hm
<gog> i guess that's not quite firmware
<GeDaMo> Does your monitor have a goatee beard? It may be from the mirror universe :|
<gog> just a ROM image you can slurp from
* gog slurps ROM
<clever> and it just tells you what the monitor supports in terms of resolutions
<gog> ye
<clever> you can ignore edid, and just feed it whatever you want
<clever> but i have seen signs of even my old vga crt, having firmware
<clever> both the OSD for configuring it, and how it behaved from malformed signals
<clever> if vsync was out of bounds, the power led would blink orange
<clever> and due to an undefined variable, i wound up configuring the hw for interlaced mode, even field was 1/60th of a second, odd field was 2 seconds, lol
<clever> the screen would see 2 vsync pulses at 1/60th apart, power led would turn green, then it didnt get another vsync, timed out, and turned off
<clever> repeat every 2 seconds
<zid> You can do all that with a cpld or whatever
<zid> doesn't have to be firmware
<clever> yeah
<clever> *looks*
srjek|home has joined #osdev
<clever> and now android is playing games
<clever> i just took a photo, it claims i have zero photos on the phone
sonny has joined #osdev
<clever> zid: it was a CPD-100SX
srjek has quit [Ping timeout: 240 seconds]
<zid> I have a cpd-200es on my desk
<zid> that's like twice as good
<clever> zid: in one of the service manuals i found online, it mentions "microprocessor and sync processing" and an 80c51
freakazoid343 has joined #osdev
<clever> 8k of maskrom, 8051 cpu core, stores the graphics for the OSD, but the bulk of the firmware/config are on an external 8k eeprom
<clever> and it has an rs232 bus as well
sonny has quit [Ping timeout: 256 seconds]
<zid> these are fancy trinitrons though
<zid> I've had crts with wheels to dial things in and not an osd
<clever> yeah
<clever> in theory, all you need to do is turn hsync/vsync into a sawtooth waveform, and your done
<clever> adjusting the rate of change, will stretch the image, and it could auto-adjust some to match up with the next sync
<clever> adding a dc offset will change the xy position
<clever> boom, done
<zid> see: oscilloscope
<zid> I love a good braindead scope that just does what the input signal says to do
<zid> the new ones that take 8 minutes to boot and run windows make me said
<zid> sad*
<clever> ive got an old tektronix 2232
srjek|home has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
scripted has quit [Quit: WeeChat 3.4.1]
sonny has joined #osdev
C-Man has quit [Ping timeout: 256 seconds]
C-Man has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 272 seconds]
Likorn has quit [Quit: WeeChat 3.4]
knusbaum has joined #osdev
jack_rabbit has quit [Ping timeout: 256 seconds]
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 268 seconds]
ephemer0l has joined #osdev
pretty_dumm_guy has joined #osdev
Ali_A has quit [Quit: Connection closed]
wolfshappen has quit [Read error: Connection reset by peer]
Oli has joined #osdev
GeDaMo has quit [Remote host closed the connection]
sonny has quit [Quit: Client closed]
vimal has joined #osdev
vimal has quit [Quit: Leaving]
Likorn has joined #osdev
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
heat has joined #osdev
mavhq has joined #osdev
<heat> mrvn, I'm very late to the party but literally all of UEFI uses boot services
<heat> drivers, apps, all use boot services
<heat> it's not just a cute thing #osdev toy bootloaders play with
sonny has joined #osdev
<j`ey> l i n u x uses boot services
<heat> fax
<heat> j`ey: i'm going to be a mentor in tianocore this gsoc!
<j`ey> I've been playing with runtime services to do PSCI
<j`ey> heat: wew nice!
<j`ey> from mentee to mentore :D
<j`ey> *mentor
<heat> yeah it'll be a fun experience
<heat> definitely out of my comfort zone, but fun :)
<sortie> Anyone else into Unix fan fiction?
<heat> fuck yeah
<heat> who's nailin' netbsd
<j`ey> lmao
<heat> fork their socket
<sortie> I'm shipping dracobsd & linux
<sortie> Documenting my OS feels like writing Unix fan fiction
<heat> steal someone else's man pages
<heat> ez
<sortie> You wouldn't steal someone else's design, it's terrible
* heat looks at his OS
<heat> >budget linux
<heat> haha totally wouldn't
wolfshappen has joined #osdev
<heat> j`ey, how does PSCI play with the runtime services?
sonny has quit [Quit: Client closed]
<j`ey> heat: problem with m1 is that there's no EL3.. which is normally where PSCI code would reside
<j`ey> so we're tryning to do PSCI with an EFI runtime service
<heat> can you still call it with hvc?
<heat> or however you call it
<j`ey> nope
<j`ey> just a normal call
<immibis> Griwes: then you find a ROM that relies on some obscure webasm extension. WebASM doesn't binary compatibility any more. It only did temporarily, because there was only one version
<immibis> but now they are adding extensions like multiple memory regions, shared memory, reference types and garbage collection
<heat> j`ey, do you extend the runtime services table?
<Griwes> None of those extensions seem "obscure"
<j`ey> nah, added a new table kind
<immibis> Griwes: it is obscure to your pre-extension uefi!
<heat> we should all shut up and use efi bytecode
<Griwes> It's not like having to do a bios upgrade from time to time to support new hardware is unheard of
<immibis> not for such a silly reason as "the programmers wanted to use garbage collection"
<immibis> that is how the web works, not hardware
* Griwes shrugs
<immibis> on the web you have to upgrade your browser so javascript programmers can have better syntax
<heat> ban those extensions
<heat> easy
<Griwes> It's "you need bios upgrade to run this hardware" which is not outlandish in my opinion
<Griwes> The user doesn't care about the details, new hardware, need new blob, it's all the same to non nerds
<heat> i mean the status quo is that the bytecode is x86 machine code
<heat> which is fine I guess
<heat> just interpret that
<heat> no need for web asm
<Griwes> "just" interpret that
<Griwes> That's a load bearing "just"
<heat> edk2-non-osi has an embedded qemu interpreter that does that
<bslsk05> ​github.com: edk2-non-osi/Emulator/X86EmulatorDxe at master · tianocore/edk2-non-osi · GitHub
<Griwes> But that only works for boot services when firmware is in control, not later, and is also a gigantically stupid hack for something that should be sane
<Griwes> Also what if the rom uses instructions that your emulator doesn't yet know about?
<Griwes> You're now in the same situation as with bytecode extensions
<heat> what if the rom uses instructions that your CPU doesn't yet know about?
<Griwes> The cpu does, because on x86 it requires a newer cpu
<heat> why do you care about running rom when firmware isn't in control
<Griwes> (which is worse than it would've been if it was using bytecode, because then on x86 it would also just need a new blob)
<Griwes> If the OS is capable of running a portable bytecode from roms, you could probably greatly simplify a number of interactions between the OS and hardware
<heat> like what?
<Griwes> Don't know, ask me again once I started dealing with pcie so that I can have a list of grievances ready
<heat> pcie is simple, hardware isn't
<Griwes> With pcie *devices* is what I meant
<heat> right
<heat> i mean, honestly, I don't see what you should put inside a ROM
<heat> you obviously can't stick a whole driver in there unless you provide standardised interfaces to/from the driver
<heat> (which is what happens with UEFI)
freakazoid343 has quit [Ping timeout: 256 seconds]
freakazoid12345 has joined #osdev
<sortie> https://pub.sortix.org/sortix/release/volatile/man/man7/porting.7.html ← is my new WIP guide on how to port software and package it for my OS's upcoming ports system :)
<bslsk05> ​pub.sortix.org: porting(7)
<catern> i want to vaguely allude to the concept of running programs on a CPU in your NIC or in a CPU in your storage device, to reduce the latency of touching the data
<catern> is there a good introduction to this that I can link to?
<catern> just, anything I could link to, so I don't have to explain it
<immibis> catern: latency or throughput? Because doing that for throughput is basically every accelerator ever, from TCP offload to GPUs
<catern> latency
<immibis> there are NICs with FPGAs on them, or rather, FPGA accelerators with NICs on them
<bslsk05> ​www.netronome.com: Agilio eBPF Software - Netronome
<bslsk05> ​www.usenix.org: Willow: A User-Programmable SSD | USENIX
<catern> but it would be nice to be more explicit and just, y'know, actually explain it
<immibis> can't say I've ever heard of a situation where the couple of light-nanoseconds between a M.2 SSD and a CPU were a problem.
<catern> shrug, well if anyone else is familiar with this area and has a good link, perhaps you can read it
<immibis> maybe just vaguely allude to the word offloading
<catern> i don't think that's enough since I don't mean the form that you're familiar with :)
<catern> so just saying offloading is ambiguous/may give the wrong impression
<immibis> what is a storage device but built-in processing, but a computer?
<immibis> with* built-in processing
<immibis> you just built a computer and put it in a SSD form factor and wrote SSD on the label
<catern> okay, well hopefully someone else is familiar with this since like I said, I don't really want to have to explain this, to you or in the article I'm writing :)
mahmutov has quit [Ping timeout: 260 seconds]
jack_rabbit has quit [Ping timeout: 272 seconds]
knusbaum has joined #osdev
freakazoid12345 has quit [Read error: Connection reset by peer]
<catern> um, unrelated question: I don't really know anything about DMA, is it ever used to communicate directly between two devices without the involvement of the main CPU?
<catern> https://lwn.net/Articles/767281/ nvm this works
<bslsk05> ​lwn.net: Device-to-device memory-transfer offload with P2PDMA [LWN.net]
Arthuria has joined #osdev
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 256 seconds]
Oli has quit [Read error: Connection reset by peer]
Likorn has quit [Quit: WeeChat 3.4]
Oli has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Arthuria has quit [Ping timeout: 240 seconds]
<immibis> catern: usually controlled by the CPU, I think
<immibis> for the obvious reason that most stuff is. but not always
<clever> a framegrabber capture card, i think can be configured to just dump capture frames directly into the gpu's framebuffer
<clever> thats what makes it such a low-cpu way to watch tv
<clever> but only for livetv
<clever> the instant you want to capture, cpu goes thru the roof, because you must encode the video in realtime
<clever> fully in software
<klange> there was a time those worked by having a cable go from the capture card to the GPU
<papaya> afaik DMA transfers have to be initiated by the CPU and then signal the CPU when the transfer is completed
<clever> papaya: pci(e) has bus-mastering, where the card just starts driving the bus on its own
<clever> a NIC for example, has a pre-configured addr for incoming packets, but will decide when it writes, when a packet arrives
<papaya> well there's also direct storage now for gpu access to storage
<heat> how do I, erm, unsee something
<papaya> heat: bleach
<clever> heat: look at more things you want to unsee, google degloving :P
<heat> HOLY FUCK
<clever> there, now you have something worse stuck in your mind!
<papaya> is that kinda like hurting yourself so you dont feel the original pain anymore
<clever> papaya: yes, lol
<moon-child> heat: whaat happened?
<moon-child> *what
<heat> nothing special, it's from a software pov
<heat> context: ext2 block maps. I know the naive way to do things, I also know the efficient, linux way of doing some math
<heat> but I cannot use GPLv2 code.
<moon-child> ohhhh
<moon-child> whelp
<heat> it's nothing special, it's just a few divisions + modulos vs ands and shifts
<kazinsal> once you've sniffed a whiff of GPLv2 your brain is considered tainted and belongs to stallman
<heat> those same ands and shifts would be used in page table code
<heat> and I just can't unsee it
<heat> is logic copyrightable?
<moon-child> gpl: not even once
<kazinsal> I think there were some lawsuits about that and the end result was "ehhhhh probably not"
<papaya> heat: write your own implementation of the logic?
<heat> sure that's what I did
<clever> heat: is this for allocations, to write new blocks?
<heat> no, it's for logical block -> block path for the block map
justyb11 has joined #osdev
<clever> block path?
<heat> getting a logical block into a block_path[4] where you just read your way down
<clever> ah right
<clever> LK is doing the same thing
<heat> yeah I saw that
<clever> and ext4 doesnt do that anymore, with its extent system
<heat> but lk uses divisions and modulos (which make sense) vs ands and shifts
<heat> which also make sense
<heat> i'll go for the divs and modulus
<heat> it's meaningless optimisations anyway
Burgundy has quit [Ping timeout: 240 seconds]
<clever> heat: for ext2/ext3, the indirection is simple, and you can compute a block path like that
<heat> yes, i'm adding ext2/3 to tianocore right now
<clever> but for exth4, each layer, is an array of extents, offset, length, and pointer to either raw data, or another block full of extent array
<heat> i know
<heat> i have implemented all that
<clever> ah
<heat> the issue is that my mind was infected by gplv2 logic :)
<heat> in that particular case, that is
<clever> yeah
<klange> ideas are protected by patents, copyright only covers the actual code
<klange> but also this is why I just don't read linux code
<klange> linux has lots of doc files that explain processes, those are great because you can figure out the ideas without ever seeing code!
<clever> in my case, large chunks of the rpi hw arent documented anywhere, and the source is the only doc
<clever> but i have been translating the linux source into documentation, to make it easier to understand
freakazoid12345 has joined #osdev