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=5&d=22
12:00:36 <eryjus> i'm trying to help here... how recent is "recently"?
12:00:52 <pterp> I'll repost.
12:01:00 <pterp> Kernel code:
12:01:05 <pterp> yield();
12:01:06 <pterp> vga_write_string("KYIELD");
12:01:06 <pterp> yield();
12:01:13 <pterp> Init code:
12:01:27 <pterp> vga_write_string("INIT VGA\n");
12:01:28 <pterp> yield();
12:01:29 <pterp> for(;;) {
12:01:30 <pterp> vga_write_string(" INYIELD");
12:01:31 <pterp> }
12:02:17 <doug16k> and both tasks exist at first?
12:02:33 <pterp> kernel creates init and yields to it
12:02:56 <doug16k> so it should just switch into INYIELD loop and never return
12:03:02 <pterp> Init? yes.
12:03:40 <doug16k> is this what you intend to do?
12:03:51 <doug16k> or just test case for cswitch
12:03:55 <doug16k> good if 2nd one
12:04:01 <pterp> test case
12:04:13 <doug16k> what do you observe it doing?
12:04:20 <doug16k> I didn't quite catch that bit
12:04:38 <pterp> Only line of output: INIT VGA
12:05:05 <pterp> It never gets to kyield, and I see it going to the return address of kmain(), which should not happen.
12:06:10 <doug16k> breakpoint at yield after init vga
12:06:17 <pterp> ok.
12:06:48 <pterp> hit it.
12:07:04 <doug16k> you can si step until you get into context save code
12:07:11 <doug16k> it calls some compiled code eventually right?
12:07:41 <doug16k> to pick next task. that is my 1st guess for where it goes into weeds
12:07:47 <pterp> context save? you mean switch_to_task?
12:07:54 <doug16k> ya
12:08:07 <doug16k> that saves outgoing context and loads incoming context right?
12:08:30 <pterp> essentialy.
12:08:39 <doug16k> essentially "yield" returns when someone switches back
12:08:44 <pterp> See the brendan multiasking tutorial on the wiki.
12:09:02 <doug16k> if this is what it says I don't really want to read it
12:09:02 <pterp> Link: https://wiki.osdev.org/Brendan%27s_Multi-tasking_Tutorial
12:09:15 <pterp> I'm in switch to task.
12:09:31 <doug16k> but I do what it says in a different but equivalent way when voluntarily switching
12:11:25 <doug16k> in my implementation, I push the context in a very specific layout and pass the stack pointer to a scheduling function which returns the new stack pointer (or the same one if not context switching)
12:11:49 <doug16k> then restore context and return on that stack
12:12:05 <pterp> i'm in the kernel task's tasking_yield, right after the call to switch_to_task
12:12:16 <pterp> i'm going instruction by instruction, BTW.
12:12:27 <doug16k> are you in compiled code?
12:12:33 <pterp> yes.
12:12:34 <doug16k> layout src will show you where you are better
12:12:46 <pterp> done.
12:12:56 <doug16k> does it step to the next task correctly?
12:13:13 <doug16k> that part must be the problem right? doesn't wrap around back to 1st one?
12:13:37 <pterp> i fixed it.
12:13:40 <doug16k> maybe it does, maybe it doesn't restore the other tasks stack
12:13:47 <doug16k> nice
12:14:06 <pterp> Three lines, that wrre making all interrupts iret to a usermode cs/ds.
12:14:39 <pterp> i completely fforgot they were there, as i never looked at the source code for that file with layout src.
12:15:06 <doug16k> layout asm plus layout regs is good for non-compiled code
12:15:16 <doug16k> you can assemble with -g and step at source level there though
12:15:26 <doug16k> it's not perfect though
12:16:07 <doug16k> I have seen step take off and set the program free in -g source level assembly a few times
12:16:42 <doug16k> it thought it was placing the right breakpoint / range-step-range for the step, apparently not
12:19:59 <pterp> i now have proper permission for kernel-space code and data!
12:20:07 <doug16k> nice
12:20:12 <doug16k> protection is a huge debugging aid
01:50:22 <ybyourmom> Ok, I'm feeling motivated about this current task I've been assigned again
01:50:30 <ybyourmom> Looks like I'll be learning a *lot*
01:50:45 <ybyourmom> Bringing up a bunch of stuff on the ZynqMPSoC
02:01:51 <bluezinc> o/
02:04:44 <AerodynamicBrick> o/
02:22:26 <adu> ybyourmom: what kind of stuff?
02:25:06 <ybyourmom> I'm writing SMMU support for a microkernel
02:25:17 <ybyourmom> So that requires me to pick a board to test it on while developing
02:25:36 <ybyourmom> And also requires me to choose and write a random driver for a device which is able to generate DMA requests
02:25:42 <ybyourmom> then bring up DMA controllers
02:25:46 <ybyourmom> And finally bring up the SMMU
02:26:05 <ybyourmom> Along the way, I'll have to also do clocks/resets/power gating etc
02:26:10 <ybyourmom> So, lots to learn
02:26:28 <adu> I have never heard of SMMU
02:26:33 <adu> I've heard of MMU
02:26:48 <adu> so, it's just System MMU?
02:27:05 <ybyourmom> Yes, but it's not the same as the processor's MMU
02:27:16 <adu> is that anything like TrustZone(TM) Real-ish Mode?
02:27:33 <ybyourmom> It's part of trust zone, but not related to Monitor mode
02:27:47 <ybyourmom> It's an MMU that is meant to allow you to create page tables for DMA requests from devices
02:28:12 <ybyourmom> In the same way that the CPU's MMU allows you to create page tables for bus transactions from the CPU
02:28:20 <geist> SMMU is arms name for intels IOMMU
02:28:31 <geist> it's a spec, secondary page table that looks a lot like ARM's page tables
02:28:32 * ybyourmom nods
02:29:08 <geist> ybyourmom: might take a look, i though i remember seeing some mention about SMMU emulation in the latest qemu update
02:29:31 <geist> though i might be wrong
02:29:33 <adu> is that a replacement for DMA?
02:29:47 <ybyourmom> That'd be pretty interesting in the sense of how accurate it could be
02:29:58 <Mutabah> adu: It's a translation layer for DMA addresses
02:30:10 <adu> ah, ok
02:30:19 <ybyourmom> adu: It's like an intermediate layer between DMA and RAM that allows you to control what parts of RAM can be accessed by DMA requests
02:30:53 <geist> right
02:31:06 <geist> modern x86 machines have this too, it's just called something else (iommu)
02:31:11 <geist> intel and amd both have implementations
02:31:27 <geist> if it's enabled linux and presumably windows 10 or so are already using it
02:31:44 <geist> (as background info for anyone watching)
02:32:20 <adu> fascinating, I just learned about paging, I've been trying to write my own bootloader
02:32:58 <ybyourmom> Have fun
02:34:02 <adu> I've been looking at dos, edk2, syslinux
03:59:21 <doug16k> in case it's not obvious, the really interesting thing about iommu (or equivalent) is allowing a user mode process to manipulate some device for dma, and even that is restricted by the iommu page tables, so even a malicious driver can't use dma to read kernel memory or elsewhere, it can only DMA where the kernel allowed the device to access
04:00:12 <doug16k> perfect for microkernels
04:01:58 <doug16k> the mainstream use right now is pass thru - you can pass thru a pci device to a guest and have the DMA it commands be redirected to guest physical memory
04:02:47 <doug16k> guest will command device to dma the guest physical, which isn't really the physical memory layout in a VM, IOMMU redirects the DMA to guest physical to host physical
04:28:42 <clever> doug16k: i think iommu is also used to restrict firewire, because the protocol is stupid and lets the remote peer choose the phys addr
04:29:06 <doug16k> sounds like a good idea :)
04:31:44 <bcos> Sadly; sometimes an IOMMU can only be configured for a group of devices, and I don't think there's a way for an OS to determine if a device is thunderbolt or not
04:32:21 <bcos> (and there's plenty of systems without IOMMU, and Intel and AMD aren't compatible)
04:33:11 <clever> my only guess as to why firewire was designed like that, is to basically emulate pci to an extend
04:33:20 <clever> the remote device can have as many dma buffers configured as you want
04:33:34 <clever> and when you trigger an action, the remote device does all the requests, just like pci would
04:33:48 <clever> and the firewire card doesnt have to care about how many buffers the remote end supports
04:34:31 <clever> but its just dumb, that you can just plug in, and read any ram you want, without even being given permission
04:34:45 <clever> at least put some windowing into the firewire card, lol
04:35:21 * clever heads off to bed
04:38:13 <bcos> It's worse than that - firwewire/thunderbolt device can diddle with whatever it likes before OS sets up IOMMU, including changing the code that sets up IOMMU
04:38:38 <bcos> (it's literally impossible to make it secure)
04:52:05 <geist> it was a simpler time
07:02:52 <NeoX> Hello, I am taking part in an osdev project and wanted to know what to do to make the project I'm part of mentioned on https://wiki.osdev.org/Projects?
07:08:25 <Mutabah> Edit the wiki :)
09:29:01 <Mikaku> JFYI: retro computer store is shutting down: <https://www.youtube.com/watch?v=7l7iU3wvT9o>
09:29:29 <Mikaku> there are a ton of old stuff, the place is huge and they need to get rid of everything
06:09:13 <bauen1> is there a more robust (uncomplicated) way of "iowait" than what is on the wiki ?
06:09:38 <glauxosdever> bauen1: Which page?
06:10:13 <bauen1> https://wiki.osdev.org/Inline_Assembly/Examples#IO_WAIT both don't seem exactly good
06:13:33 <glauxosdever> I don't know unfortunately. :-(
06:13:41 <glauxosdever> But hopefully someone else does
06:15:35 <bauen1> well, linux doesn't seem to care about iowait so i guess i don't need it yet lol
06:15:42 <glauxosdever> Hm, how does writing to port 0x80 help though?
06:16:51 <glauxosdever> (In any way better than a series of jumps, i.e. just wasting CPU cycles)
06:18:01 <bcos> bauen1: How about, don't bother at all?
06:19:03 <bauen1> yeah
06:19:08 <bauen1> that's the way i'll go
06:19:14 <glauxosdever> bcos: Then why is it on the wiki? And why Linux uses it?
06:19:59 <bcos> Originally the "IO_WAIT" was needed for problems with ancient <= 80286 systems where motherboard was slower than CPU expects. The problem was fixed in 80386 and later
06:20:29 <bcos> Linux probably uses because "better to be safe than sorry (in 1990s)" followed by "too scared to touch working code"
06:20:53 <bcos> ..although I'd expect it's configurable in Linux
06:21:11 <glauxosdever> If it's been fixed, then it's probably ok. But then we can stop recommending it maybe
06:22:25 <bauen1> the pic code in linux doesn't use it (the wiki recommends it)
06:23:02 <bcos> Configuring PICs during initialisation is one case where it's never needed - you can just alternate (write to master, write to slave, write to master, ...)
06:30:27 <bauen1> ah and now the design issues of IRQs, why can't kernel development be plug and play and easy like playing with lego ...
06:37:54 <glauxosdever> So, concerning the file format abstraction layers I've been talking about yesterday, I think it would make sense to allow "streaming" and not only importing/exporting from/to files. E.g. There is a continuous flac audio stream and you want to decode it in real time, then send the result to the audio driver. Or you have some .wav/.flac/anything audio files in the filesystem that you want to stream
06:38:00 <glauxosdever> through icecast or something. Or directly stream microphone input in real time. Or..
06:38:34 <bcos> For streaming, you'd not using a file format
06:38:47 <glauxosdever> True
06:39:08 <glauxosdever> But streams can be flac-encoded or ogg-encoded or mp3-encoded
06:39:15 <glauxosdever> Or something-else-encoded
06:40:07 <glauxosdever> It's not a file format (in the literal sense)
06:40:13 <glauxosdever> But it's still an encoding
06:45:23 <glauxosdever> As I realise this it not osdev-related, if anyone would like to suggest me something, you can join #audiocodinglayer
08:00:22 <elderK> Guys, how long do you think it will take before IOMMU is pretty much a standard feature?
08:00:52 <elderK> Does VT-d mean you have IOMMU?
08:01:25 <sortie> Not sure how widespread it is in modern hardware. Might be a lot. Although not sure about ARM, think it has something similar too. Someone else would know.
08:01:46 <sortie> The bigger question is how long old hardware will be relevant, meaning that one can't rely on its existence.
08:02:13 <sortie> Where older hardware might be more relevant the more successful a project is
08:02:31 <zid> forever, for some definition of relevent
08:02:40 <zid> There are working VAXes all over
08:05:18 <Bitweasil> What are you looking to use the IOMMU for, and why does it matter to your use cases?
08:05:35 <Bitweasil> With Intel differentiating between lines with stuff like that, I'd expect it to be "not standard on everything" for a very, very long time.
08:05:55 <Bitweasil> I believe VT-d is Intel's term for an IOMMU, but double check that.
08:05:58 <zid> yes
08:06:12 <zid> what chips don't have vt-d?
08:07:24 <Bitweasil> https://ark.intel.com/content/www/us/en/ark.html Feel free to poke. ;)
08:07:30 <zid> also is it part of vmx
08:08:17 <zid> my 2011 cpu has vmx feature bit in linux, at least
08:08:51 <Bitweasil> VMX is separate from VT-d.
08:09:00 <Bitweasil> Atoms don't have VT-d in general.
08:09:00 <zid> any idea what the feature bit is called
08:09:14 <Bitweasil> No, sorry. I'd look up the chip model.
08:09:21 <zid> I knwo what my cpu has
08:09:28 <zid> I want to know what the feature bit in linux is called
08:09:53 <Bitweasil> https://wiki.xenproject.org/wiki/VTd_HowTo
08:10:01 <bcos> IOMMU isn't a CPU feature - more like a chipset feature (that got dragged onto same package)
08:10:22 <zid> no vt-d on K versions? weird
08:11:14 <Bitweasil> https://stackoverflow.com/questions/51261999/check-if-vt-d-iommu-has-been-enabled-in-the-bios-uefi also has some ways to look.
08:11:18 <Bitweasil> Yeah, it's not really a CPU flag.
08:12:47 <zid> That's annoying
08:13:52 <Bitweasil> Given Intel's ongoing engineering trainwrecks of recent, it's not high on my list of concerns.
08:13:57 <dormito> IOMMU's are (more or less) a DRAM/memory controller thing (that's where they are ~implemented, and that also gives an idea of their limitations)
08:14:06 <zid> which are inside the cpu these days, last I checked?
08:14:15 <Bitweasil> Yes.
08:14:37 <zid> It was rhetorical but nice to have the confirmation :D
08:15:10 <zid> It'd be interesting to set my desktop up as everything passthrough'd to a windows inside a VM
08:15:22 <zid> and then I could reboot windows without rebooting the machine
08:15:27 <dormito> PCI reserves address space for PCI devices that are memory controllers... though I've never heard of an actual chip|card that implements that
08:15:30 <zid> put a spare network card in that doesn't get passed through etc
08:15:43 <dormito> *reserved device class space
08:17:31 <Bitweasil> TBH, with the way things are going, physicalization of machines is likely a good path. Have separate hardware for separate tasks, instead of relying on VMs.
08:18:08 <zid> I have intel ME and all that crap available on the cpu, but my board doesn't have anything nice like kvm crap
08:18:09 <dormito> last I check virtualization crazes come cyclically
08:18:14 <zid> I should get a ncie supermicro board :P
08:18:25 <Bitweasil> I run many tasks on cheap ARM boards now.
08:26:47 <elderK> :) Anyone here also interested in capability-based security?
08:43:53 <geist> fairly certain that pretty much all consumer intel hardware has vt-d now, but it has been phased in over time
08:44:01 <geist> so go back to 5 years ago and 10 and it's different
08:44:15 <geist> AMD has had full iommu for i think 5 years at least
08:45:12 <geist> in ARM it's very scattershot, and though there is the SMMU standard, lots of vendors have implemented non standard versions
09:01:56 <Bitweasil> elderK, as in Linux capabilities?
09:25:17 <elderK> No. Object capability based security.
09:29:34 <Bitweasil> Unfamiliar.
09:36:57 <elderK> It's kind of hard to describe them in a nutshell but basically this: It's like time and space. People used to think time and space were independent. Then Einstein came along and showed that time and space are really the same, space-time.
09:36:57 <elderK> Capabilities are a little like that. The idea is, is that having a reference to some capability implies the authority to use the resource referenced by the capability. I.e. Naming and privilege are linked. If you have the capability, you have the authority to fully exercise the resource it represents.
09:37:27 <elderK> You can pass them around, shake them in a jar, etc.
09:38:30 <elderK> "Objects" are a useful way to ponder them because there are a lot of practices in the OO world which turn out to be useful for managing security with capabilities.
09:39:49 <elderK> I.e. I have some capability to mess with a File. I can read, write, truncate, whatever. But I want to give some other program access to that file, but read only access. So, instead of transferring the capability I have, I create a new one that wraps the one I have. The wrapper either only provides "Read" functionality. It may provide the same interface as the "File" capability, but ensure that attempts to "Write" or "Truncate" generate errors.
09:40:18 <elderK> Most importantly, and easy to forget: Capabilities must be unforgeable. You can't just come up with a valid capability by munging bits.
09:40:57 <elderK> Likewise, if you have a capability that wraps another to modulate access, the user of that wrapped capability must not be able to retrieve the wrapped capability.
09:41:24 <elderK> There will be people here, no doubt, who can explain this much better than I can. But, that's my best shot at capability-based security in a nutshell.
09:41:30 <Bitweasil> This sounds tricky to handle corner cases in.
09:42:04 <elderK> What corner cases do you have in mind? Revocation is something that people tend to ask about, that can be achieved my suitable wrapping.
09:42:33 <elderK> I'm no expert. I'd love to discuss corner cases. Helps to better explore the concept :)
09:42:57 <Bitweasil> I rarely come up from ring 0 long enough to even know what people use computers for, so... bad person to ask.
09:43:35 <elderK> It's definitely a chicken-egg kind of thing, though. Capabilities all the way down.
09:44:12 <elderK> From the literature I've read. Like, to send a message to some process, you need to have a capability for that. Either a capability to the process, or a capability to the mailbox that the process monitors.
09:44:54 <elderK> So, performing a send or receive, is invoking a capability. But then, if you need a capability to send messages, how do you give something a capability in the first place?
09:45:19 <elderK> Assuming you use messaging for everything. I.e. The only system calls are send, receive, send_receive and maybe some asynchronous variants.
09:45:47 <Bitweasil> This sounds like the sort of thing you study in the "history of OSes and why we don't use this particular OS" classes. :)
09:45:56 <elderK> So, at a minimum, a process needs some basic capabilities to say, talk to the kernel, or to create certain kinds of objects.
09:46:27 <elderK> Heh. It's less OS, more paradigm. It's actually a very neat concept, I think.
09:46:41 <elderK> I think it's the future. But to take real advantage of it, you need to have it designed in from the start. And that's the problem.
09:46:57 <elderK> The DoD has done a lot of studies regarding it though, and how to use it even on systems that are not "capability-based."
09:47:00 <Bitweasil> Quite.
09:47:05 <elderK> There's a lot of research still being done on it.
09:47:46 <elderK> Of course, the problems I see may be due to me trying to do something "pure." Purity can often make things a lot tougher than they need to be :P
09:48:22 <elderK> Maybe you use capabilities for most things, but send/receive are basic primitives? It's like, anything taken to the extreme, you know.
09:49:26 <elderK> There are a lot of things to consider. Like, how do you implement it? Store them? How do you make it so that new capabilities can be defined by userspace, and those made available to other programs? Does the kernel just provide the basics for creating "unforgeable references that userspace can't mess with", and it lets userspace programs worry about what they mean, etc.
09:49:47 <elderK> Or does the kernel have some way of letting userspace programs define a new "Capability Object", specify what it holds, how to invoke it, etc.
09:50:08 <Bitweasil> Go to school, get your PhD, implement this as your Thesis. :)
09:51:09 <elderK> Say, when you invoke it, what process is called, how it is called. That comes back to the messaging thing. If invoking a capability is effectively the same as sending a message to special process, the process that "defines the capability", then how can messaging be a capability? Would it need to be a "primitive" capability that's treated specially? Would it not be a capability at all?
09:51:11 <elderK> Heh.
09:51:15 <elderK> :P I'm just about to graduate, actually.
09:51:29 <elderK> :) And there are smarter people at me working away on these problems.
09:51:33 <elderK> *than me
09:53:03 <Bitweasil> As I said, I don't come up to that level. :) I just lurk in ring 0.
09:53:28 <elderK> Fair enough :)
09:53:48 <Bitweasil> I know how computers work at a deep hardware level. I don't know what people use them for.
09:53:55 <Bitweasil> I use them for IRC, and writing firmware code, mostly.
09:54:07 <Bitweasil> (so it is a nice tight loop of using computers to write code for computers)
09:54:12 <Bitweasil> (rarely being bothered by the real world)
09:54:22 <elderK> :) I can relate to that.
09:54:40 <Bitweasil> To the best of my knowledge, people use computers to run browser to surf porn and Facebook.
09:54:53 <elderK> I haven't done any real OSDev in a long, long time. What I had, years ago, was a half-baked microkernel that didn't really do all that much. I was more interested in learning about memory management and IPC than actually say, implementing drivers to do neat things :P
09:54:59 <zid> sometimes they run webservers, for porn
09:55:15 <elderK> So, you had the problem of showing someone and they're like: Dude, it's just printing gibberish. I can do that in C. Or a bootdisk with autoexec :P
09:55:30 <Bitweasil> Nah, you don't need a computer for that. You use the cloud to host that stuff. It's probably a person with a notebook writing out data with toggle switches. :)
09:55:49 <Bitweasil> You should write your own multitasking environment in DOS or something.
09:55:54 <Bitweasil> Which gives you the primatives of drivers.
09:56:43 <elderK> These days I'm interested in writing something that someone can get use out of, in some way. Like, if I built something that someone could learn from, or use as an aid to help them build something, then I'd be pretty content with that.
09:57:35 <elderK> Recently I implemented a PCI enumerator / configurer-thing. I was thinking of posting on OSDev in the hope that newcomers might find it useful. I'm aware we already have a good deal of material on it on the wiki, but, maybe it'd be useful to someone to see how to implement nonrecursive enumeration and stuff.
09:58:06 <Bitweasil> Certainly update it or make forum posts.
09:58:07 <elderK> :P Problem is, I wound up using a ton of magic numbers (instead of defining symbols for masks, etc). And I don't have the time or inclination to improve that at the moment :P
09:58:12 <Bitweasil> I write PCI parsers every few years, it seems.
09:58:18 <elderK> It was a fun exercise :)
09:58:27 <elderK> I wouldn't do it the same, if I had to do it again. But it was fun.
09:59:14 <elderK> :P I also have a pretty peculiar way of writing code, at least in terms of indentation and stuff. I write a slightly modified form of K&R, due to having serious issues with eyesight.
09:59:31 <elderK> A lot of people I've worked for in the past had a major bone with that.
10:00:18 <elderK> Bitweasil: What are you working on? :) It sounds like you're writing your own BIOS or something!
10:00:26 <elderK> That sounds like it would be really fun
10:00:58 <Bitweasil> I lurk in the weird corners of x86.
10:01:01 <Bitweasil> It's horrifying.
10:01:07 <elderK> :P What corners? :D Color me curious.
10:01:15 <Bitweasil> But, in general, I spend my time in the EFI codebase, hypervisors, introspection, and SMM.
10:01:28 <Bitweasil> (I say this from a light ARM desktop I use for things I care about)
10:03:30 <Bitweasil> So mostly ring 0, mostly below OSes.
10:03:57 <elderK> Interesting :) SMM seems to be one of those black magic thins
10:06:09 <Bitweasil> It's not particularly black magic, but the hypervisor capability over there is a fun space to play. :)
10:06:24 <Bitweasil> Second half of SDM3's chapter on SMM should be a fun read.
10:26:17 <elderK> :) I'll check it out when I have time.
10:26:47 <elderK> Man, I can't believe my time at University is almost over. For years, it has seemed like one of those nightmares where you're running down an infinitely long hall.
10:27:11 <Bitweasil> Whippersnapper.
10:27:14 <elderK> In two weeks, all that will remain is dust settling.
10:27:29 <Bitweasil> Bachelors, Masters, PhD, ?
10:27:30 <elderK> :) I'm a pretty old whippersnapper :) 32.
10:27:38 <elderK> Just a Bachelors, nothing fancy :)
10:28:06 <Bitweasil> Fair enough. There's good money in the low level stuff, if you can get good at it. A custom OS kernel or so will be a very useful thing to talk about in interviews.
10:28:11 <elderK> A few years ago, after working in the industry for awhile, I decided getting a degree couldn't possible hurt.
10:28:18 <Bitweasil> It's remarkably difficult to find low level people.
10:28:21 <Bitweasil> (and getting harder)
10:28:24 <elderK> That's what I've hoped :)
10:28:35 <zid> hard to find jobs doing it unless you want to write C++ for radio gear
10:28:45 <zid> or have a butt load of linux kernel exp
10:28:46 <elderK> I'm pretty sure that's how I landed the my new job :)
10:28:51 <Bitweasil> zid, disagree. if you can hack on the kernel or hypervisors, there are plenty of people hiring.
10:28:52 <elderK> (It start a few days after my final exam :P)
10:28:53 <Bitweasil> They may be hard to find.
10:28:56 <Bitweasil> But they're out there.
10:29:06 <Kazinsal> If anything having some weird custom kernel hacking under your belt shows you have passion for tech
10:29:17 <elderK> Yup, and the ability to self-manage. Determination, too.
10:29:19 <zid> I jus thave a passion for nice C :P
10:29:19 <Bitweasil> And, better, if it's a personal project, you can talk extensively about it for interviews.
10:29:45 <elderK> Funny you mention radio gear, that - as far as I understand so far - is what I'll be doing.
10:29:47 <elderK> Baseband stuff.
10:29:53 <Bitweasil> I would suggest that some hands on experience with the recent Intel issues would be useful as well.
10:30:01 <zid> If I look at job market near me, everything embedded is radio or medical
10:30:04 <Bitweasil> If you can explain (and, ideally, have implemented) Meltdown/Spectre/L1TF/etc.
10:30:04 <zid> and all C++
10:30:28 <elderK> Actually, that reminds me of a question: Thanks, Bit: What do you need to get access to the Intel errata?
10:30:35 <elderK> Every link I've ever found, mailing lists, etc, is all gated.
10:30:37 <zid> work at intel
10:30:46 <elderK> Damn.
10:30:47 <zid> or have it given to you by intel by being virtue of beeing kees cook
10:30:47 <Bitweasil> Work at Intel or a major cloud provider, pretty much.
10:30:57 <Bitweasil> If you're not Google/Microsoft/Amazon/etc, good luck.
10:30:58 <elderK> That's a shame.
10:31:06 <elderK> I guess I can understand but, that's a shame.
10:31:16 <Bitweasil> Even the Linux kernel and hypervisor devs are NDA'd to hell and back on the stuff they're fixing.
10:31:21 <Bitweasil> (and only the major hypervisors)
10:41:53 <elderK> Curses :P
10:44:02 <aalm> .theo
10:44:03 <glenda> Huh? You've understood incorrectly.
10:47:02 <zid> Look theo, I can explain it to you, but I can't understand it for you
10:48:26 <aalm> .theo
10:48:26 <glenda> If software sucks, say so.
10:49:19 <aalm> oh look, a polite reply:]