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=7

Tuesday, 7 May 2019

12:39:35 <ZombieChicken> _mjg: I think RMS would rather it was the year of the HURD desktop
12:40:25 <_mjg> i meant the feet
12:40:38 <ZombieChicken> ah
12:40:59 <ZombieChicken> I'm just assuming the penguin was wearing flip-flops or something
12:41:09 <ZombieChicken> or some stick-on sandals
12:43:28 <drakonis_> flipflops maybe?
12:45:41 <aalm> feels like it was a good decision not to open the url above?
12:47:10 <ZombieChicken> aalm: It's just a cartoon
12:47:12 <ZombieChicken> nothing horrible
12:47:19 <ZombieChicken> the feet are ... questionable
01:58:23 <doug16k> when I run `perf top` on a mostly idle machine, it seems mov to cr3 in sysret codepath takes almost 1% of cpu time itself
01:58:37 <doug16k> is moving to cr3 drastically more expensive with PCID on?
02:00:33 <doug16k> somebody needs to measure system instruction performance thoroughly someday
02:01:30 <bcos> PCID shouldn't make CR3 load slower (unless you're running in a VM)
02:01:40 <doug16k> bare machine
02:02:03 <doug16k> just observing linux perf and see a surprising amount of time in that mov to cr3
02:02:38 <bcos> You tested with and without PCID? Might be significantly worse without..
02:03:34 <doug16k> geordi, << 0.6*0.012*2400000000
02:03:34 <geordi> 1.728e+07
02:04:11 <doug16k> that's 60% time in mov to cr3, in sysret function which was 1.2% of cpu time at that moment. 17M cycles right?
02:04:15 <doug16k> per sec
02:04:29 <doug16k> 2.4GHz base clock
02:04:41 <doug16k> I see the freq. it's about that
02:06:03 <bcos> It took an entire second?
02:06:33 <bcos> D'oh - 1.2% of a second
02:06:36 <doug16k> 60 percent of 1.2 percent of 2.4 billion cycles = 17M cycles per second average
02:06:50 <doug16k> unless I screwed something up :)
02:07:20 <bcos> With PCID, the "mov cr3" should do (almost literally) nothing
02:07:49 <doug16k> what if bit 63 is one though
02:08:15 <doug16k> then expensive selective invalidation?
02:11:15 * bcos is still trying to find bit 63 in Intel's manual
02:13:18 <bcos> Ah - opposite (if bit 63 is clear then all stuff associated with the ID is invalidated)
02:13:50 <bcos> ..which confuses me (doesn't it conflict with the "encrypted RAM" feature??)
02:16:35 <doug16k> ah
02:22:28 <bcos> Hrm - AMD's memory encryption uses a "C-bit" in a variable position (not bit 63), and AMD doesn't support PCID yet (!)
11:05:49 <mquy90> not sure that I understand correctly, for example cr3 points to 0xsomewhere (physical address), after paging, when mmu gets memory address from cr3 to calculate, but now cr3 is the virtual address
11:05:58 <mquy90> I think it is the reason we have the first 4MB identity mapping?
11:28:54 <jussihi> What is the irq0?
11:29:12 <jussihi> Ah it's the PIT
11:29:51 <lkurusa> mquy90: the value in CR3 must always be a physical address
11:30:22 <lkurusa> otherwise the MMU wouldn't know where to look for the paging structures... as it would need them in the first place to decode the virtual address in %cr3
11:30:57 <mquy90> yup, it is a physical address, but i wonder after paging, MMU can access physical address?
11:31:04 <lkurusa> Yes
11:31:06 <lkurusa> Of course
11:35:45 <mquy90> I though that when turn on paging, everything becomes virtual?
11:36:28 <lkurusa> mquy90: most things from the software's perspective becomes virtual addressing, correct
11:36:42 <lkurusa> but the MMU is not software and if everything is virtual, then how would you ever access the actual memory?
11:37:10 <lkurusa> the reason you are identity mapping usually is to make sure that code runs after you enable paging
11:37:31 <lkurusa> if suddenly the location where your %rip is, is no longer mapped or worse, mapped to garbage, then the CPU would crash
11:42:56 <mquy90> ah ah lkurusa :+1:
11:45:53 <lkurusa> :-)
01:11:16 <pterp> I'm working on a new taskig system that uses interrupt data to store the registers on the process stack. Here it is: https://pastebin.com/ZEiTp5Jg. What do you guys think?
01:26:12 <pterp> In case no one saw my post, i'll post it again.
01:26:13 <pterp> I'm working on a new tasking system that uses interrupt data to store the registers on the process stack. Here it is: https://pastebin.com/ZEiTp5Jg. What do you guys think?
01:27:46 <mquy90> doug16k, are you there? can I ask you about recursive-page-directory which we discussed yesterday? still confused :D
01:28:08 <pterp> What are you confused about? I know the basics of them.
01:31:02 <mquy90> https://wiki.osdev.org/Paging#Manipulation, page_dir[addr >> 22], page_tables[addr >> 12]. According to that wiki, page_dir and page_tables are virtual addresses which seem not correct. Should it be physical address
01:32:29 <pterp> No. That's the weirdness of recursive page tables.
01:33:23 <pterp> Take a look at thie recursive mapping section of this page: https://os.phil-opp.com/page-tables/
01:34:03 <pterp> It's for 64-bit, but 32 bit ust takes two layers away and uses 10 bit offsets.
01:34:12 <pterp> *just takes two layers
01:36:22 <mquy90> but it seems that everyone does liek that https://forum.osdev.org/viewtopic.php?p=152027#p152027
01:37:37 <pterp> Right. That's 32-bit recursive mapping, That's 64 bit as i noted in my next post, but that was just to give you a graphical representation., not how you'd actually implement it.
01:40:07 <pterp> Basically, when you have the last entry mapped into itself, and you se the top 10 bits to that entry, the processor interprets your page directory as a page table, and the prceesor thinks the next 10 bits set the table enry, so it does that and gets a frame address, What really happens with the mapping is that the next 10 bits set the offset into the directory again, making the table frame be the frame the processor gets.
01:41:08 <pterp> Wen the first 10 bits and the next 10 bits are both on the last entry, it's like before, but instead of a table address, it's the page dirctory address, allowing you to edit that.
01:44:31 <lkurusa> on 64-bit i just map the entire physical address space to a high address
01:45:20 <pterp> Also, you might notice theres a bit of a catch-22 when you're creating a new page diectory. You need the recursive entry to edit it, but you neeed to edit it to make the recursive mapping. Just use the first page (What's usuallyunmapped to catch NULL pointer derefrences), but remember to umap it when done.
01:46:02 <pterp> lkurusa: Yes, that will work on 64-bit, but mquy90 seems to be doing 32-bit.
01:49:20 <mquy90> but what I am confused it that, from my understanding page_dir and page_tables are physical addresses but according to what I read they are virtual address?
01:51:48 <pterp> well the page table entries refer to physical addreses, but with the recursive mapping it makes it possible to access them using virtual addresses without worrying about when you change page directorys like when you map them manually. (One page for the directory, 1024 pages for the page tables.)
01:53:43 <pterp> I'll explain again. CPU reads page dieectory entry, which is the recursive entry, and now thinks the page directory is a page table. So instead of the offset referring to a page table offset like usual, it refers to a directory offset, which then allows you to edit the page table at that offset.
01:54:25 <pterp> When the second index is also the recursive mapping, it sees the page directory as it's frame, allowing you to edit that.
01:56:28 <mquy90> I though that it will only recursive the last one 1023?
01:56:47 <pterp> right. There's only one recursive mapping.
01:57:20 <pterp> But the second index can also be that same recursive index, allowing you to edit the page table.
01:59:36 <mquy90> but if there is only one, what if my virtual address is on not recurisve one (for example 10th pd)
02:00:41 <pterp> What's the problem with that?
02:07:13 <pterp> i have to go now.
02:09:40 <mquy90> still can get my head around how cpu calculates when given a virtual address
02:09:53 <mquy90> btw, thanks pterp
02:11:24 <eryjus> mquy90, that can be difficult to get your head around, but it's really nothing more than some fancy lookups in a couple of tables.. I just joined a bit ago.. can you re-ask your question?
02:11:50 <knebulae> mquy90: the mappings don't have to be recursive. It's just a table. Each part of the virtual address is an index into a table. That's it.
02:13:02 <mquy90> my question is that how cpus use this formula page_dir[addr >> 22], page_tables[addr >> 12], page_dir: 0xFFC00000, page_tables: 0xFFFFF000 (they are virtual addresses)
02:13:28 <knebulae> mquy90: the MMU handles address translation, not the CPU
02:13:45 <mquy90> ah, my bad, MMU :D
02:14:11 <knebulae> It doesn't; it just looks up the address via the page tables
02:14:29 <eryjus> first, you will hand the cr3 register the physical addresses of the tables, not the virtual address... the virtual address is picked apart to determine the index into the table for each address.
02:15:11 <eryjus> each entry in the page directory and the page table will have a physical address (or a frame) in it so the mmu can translate to physical memory
02:16:02 <eryjus> when you recursively map the tables, you are taking the (physical) address of the PD and setting one entry to look at itself (again, at the physical address).
02:17:02 <mquy90> can you explain more about this part "when you recursively map the tables"
02:17:03 <eryjus> Now, when you want to update these tables dynamically, you will be able to access the PTs starting at virtual address FFC00000 and the PD starting at virtual address FFFFF000.
02:20:12 <eryjus> So, you have your page directory at some physical address (it really does not matter where), and you want to update the tables for some address... when you calculate the location of the PDE in your virtual memory (think of it as a management address), you will update the PDE at ((PageTableEntry *)0xFFFFF000)[vaddr>>22]
02:22:37 <eryjus> What this really does is look at entry 1023 of your PD, and sees it is mapped back on itself. So, it uses that very same block of physical memory as a page table (this is the part I'm betting you are struggling with) and then when you calculate (vaddr>>12)&3ff, you will be looking at the same entry in the same table.. 1023, which points back to itself.
02:24:01 <eryjus> Now, you are looking at the very same block of memory as a page that is readable/writable... this is the PD itself based on the recursive mappings. And you can update this PD to check for an existing PT or to add one if you need to -- in order to map this address.
02:24:47 <eryjus> the same goes for the Page Table, bu you will only do that recursion once rather than twice for the Page Directory.
02:32:08 <mquy90> this one too, "What this really does is look at entry 1023 of your PD, and sees it is mapped back on itself", why it looks at entry 1023 of my PD, for example, my virtual address (>4MB) is at 1st PD
02:33:42 <eryjus> it could really be any entry -- but most people work with 1023 to get the concept down because it's at the end of the tables and largely out of the way (and typically in kernel address space).
02:34:31 <eryjus> until you fully understand using index 1023, I would not recommend trying to understand the address space requirements for index 999.
02:37:08 <zid> index 0 is easier ;)
02:37:10 <eryjus> now, if you are asking about how index 1023 is calculated.. FFFFF000>>22 == 3FF (you will need to prove that to yourself..). 0x3FF == 1023
02:38:03 <eryjus> and by the way, FFC00000>>22 == FFFFF000>>22. You should prove that to yourself as well.
02:38:36 <eryjus> zid, except for the whole null pointer de-reference if you were going to actually implement that
02:39:00 <zid> Not like the cpu cares
02:42:28 <mquy90> thanks eryjus, I understand shifting to get page directory index and page table index but, thing gets me confuse is that mmu always does like this pd = cr3(); pt = *(pd+4*PDX); page = *(pt+4*PTX), right? (everthing here is physical address)
02:43:01 <zid> looks vaguely right
02:43:10 <eryjus> it won't.. but if you implement that scheme, you are guaranteed to have address 0 point to your PD. and null pointer de-reference is guaranteed to be reading (or worse updating) your PD, leading to some bad crashes potentially by user space programs. it would be better to force a page fault so you can shut down an offending program before it damages the structures.
02:43:17 <zid> but in your case, pd[0x3FF] == pd
02:45:19 <eryjus> mquy90, yes, the mmu deals exclusively with physical address and your kernel manages the space exclusively with virtual addresses. This is why it can be so difficult to keep them straight -- you need to use the virtual address space to make things look the way the MMU requires it with physical addresses
02:45:41 <zid> yea configuring the mmu has a catch-22
02:45:46 <zid> so you need to poke a hole into it somewhere :P
02:48:24 <mquy90> "it won't.. but if you implement that scheme", that is the only way, right?
02:49:08 <zid> mquy90: he was talking to me about 0 being mapped.
02:49:38 <eryjus> mquy90, zid also reminds me of a point... when you create your CreateNewVirtualSpace() function (this function called from mapped kernel space and not your initialization function), you will allocate a frame from physical memory and clear it. For me, this meant I needed to install that frame into the virtual address space at a temporary location so I could set it up. This included creating the recursive mapping and all the other
02:49:38 <eryjus> kernel mappings you need before you can drop it into the cr3 register... Your InitializeVirtualAddressSpace() function will not run while paging is enabled yet, so you will have 2 flavors of this function.
02:50:19 <zid> https://github.com/zid/boros/blob/master/mem.c#L55 (amd64 so I have 4 tables not 2, but same idea)
02:50:28 <zid> Here's the gross code I wrote to traverse my recursive mapping
02:55:10 <mquy90> do you have 32bits code? :D
02:56:42 <eryjus> Here is my code to dump a page table entry based on the recursive mapping address
02:56:42 <eryjus> https://github.com/eryjus/century-os/blob/master/arch/x86/MmuDumpTables.cc
03:09:02 <mquy90> eryjus, for example my PD points to 0x1000 (physical address), when I try to access 0xA0000000 (virtual address, not present)
03:10:28 <eryjus> well, your PD "is located at"...
03:11:23 <mquy90> 0xA0000000 -> 640th -> 0x1000+640*4 = 0
03:12:06 <zid> Which my calculator says is 0x1A00
03:12:56 <mquy90> quick math, I guess like this https://github.com/MQuy/mos/blob/master/src/kernel/memory/vmm.c#L85
03:12:59 <zid> so if 0x1A00 is also 0x1000, we're back at square one like nothing happened, and the PD will then get used as though it were actually a PT too. Being the theory.
03:13:11 <eryjus> but address A0000000>>22 == 0x280 == 640
03:13:45 <zid> I was lied to
03:13:55 <eryjus> now, the mmu will use address 0x1000 to check if that is mapped... but /you/ will use 0xFFFFF000 to check...
03:14:36 <mquy90> how can I use 0xFFFFF000 to check, because I should do what mmu does? going from 0x1000
03:15:27 <mquy90> from 0x1000+640*4 == 0, call physical allocator to get 4KB and assign it to 0x1000+640*4
03:15:38 <zid> The mmu translates virtual addresses to physical addresses.
03:15:50 <zid> If you want to read physical memory, you need to use a virtual addrss which translates to it.
03:15:54 <zid> That should be a basic fact to you
03:16:12 <eryjus> mquy90 - is this initialization code (before paging is enabled), or will this be called from the kernel?
03:17:15 <mquy90> after paging is enabled and I want to map virtual to physical address
03:17:37 <eryjus> https://github.com/MQuy/mos/blob/master/src/kernel/memory/vmm.c#L104
03:18:07 <zid> mquy90: In which case, you need to edit your page tables, so you need pointers to your page table pages.
03:18:08 <eryjus> This will #PF, unless you are specifically mapping table to be its own physical address (known as identity mapping)
03:18:30 <zid> And now we're back at the start I think :D
03:19:06 <eryjus> zid, the code is close, but I see a hard couple of debugging days ahead with lots of triple faults
03:19:28 <zid> I surprised myself, that early_map thing I showed worked first try
03:19:37 <zid> but it took me a while to get my head around what it was supposed to do I will admit
03:19:38 <mquy90> yeah, it is in identity mapping -> it works
03:19:51 <eryjus> mquy90, you have no code to check for and create a new Page Table if needed. that will be a problem eventually
03:20:27 <mquy90> but I checked it present or not before creating a new page table? https://github.com/MQuy/mos/blob/master/src/kernel/memory/vmm.c#L87
03:20:28 <eryjus> mquy90 -- for now... you will eventually find a situation where it does not
03:21:08 <mquy90> yeah, I think I miss some critical parts :D
03:21:13 <eryjus> you checked if it was 0, not explicitly present
03:22:43 <mquy90> ah ah, makes sense, will fix it. in here https://github.com/MQuy/mos/blob/master/src/kernel/memory/vmm.c#L103
03:23:18 <mquy90> page table is physical address (4kb), and assign it page directory entry (for example 640th)
03:24:54 <eryjus> i have not gotten into all the supporting functions, but it looks reasonable...
03:25:37 <mquy90> saying physical allocator returns 0x5000
03:25:50 <eryjus> again, a few hard debugging days are in your future ;) -- get used to triple faults for a while.. it's a fact of life when you are trying to bring up paging
03:26:16 <zid> apparently I got off easy
03:26:32 <zid> although I did crash a bit trying to add bitmaps
03:26:44 <zid> because I can't do basic addition correctly
03:27:31 <eryjus> zid, I had a hell of a time with the arm -- which does not have this cute recursive mapping trick. i kept a journal of the problems i had (about 6 weeks to debug I think)
03:27:38 <mquy90> I think so, I though paging is not that hard, until recursive :dizzy:
03:28:25 <eryjus> it took me weeks to get my head around that myself... but once I understood it i can now (well, try to) explain it
03:28:37 <bauen1> i never did recursive mapping of the page directory, i just identity mapped the page directory are there any real benefits of recursive mapping ?
03:28:50 <zid> it's funny? :P
03:29:04 <zid> and it shouldn't mess up your TLB entries
03:29:22 <eryjus> zid, it's like watching a train wreck -- you know it's going to be bad but you just can't help yourself
03:31:12 <eryjus> bauen1, with recursive mapping you can control whether user space can update the tables directly by keeping it in kernel address space and marking it for supervisor updates. Eventually, identity mapping will conflict with some portion of memory somewhere and you will be out of luck.
03:31:59 <zid> I actualy have both in my kernel atm, a full identity map of every page, and a recursive entry in the pml4
03:32:14 <zid> I tried my hardest to avoid not having memory in memory
03:32:17 <zid> but eventually I gave up
03:32:36 <zid> writing the memory allocator without having memory in memory was too much of a pain in te ass
03:39:33 <bauen1> true, i just identity mapped the gdt, tss and interrupt trampolins and the page directory
03:39:59 <bauen1> i do forbid virtual memory allocations from those ranges, but i guess for the page directory it could break things
03:56:54 <royal_screwup21> when a user spawns a process, does the kernel keep track of the parent process and the associated child process? Like, I know how the process creation would work, but I'm wondering if there's any reason why it would need a mapping from a parent process to a list of all of its child processes
03:57:20 <zid> royal_screwup21: fork/waitpid/etc if you're doing posix
03:57:41 <zid> err wait() whatever the one is that doesn't take a pid
03:57:54 <zid> and whether something is a zomblie
04:01:21 <royal_screwup21> zid ah I see. As I understand it, when a fork() happens, basically the kernel keeps allocates a new stack for the child, fills it up with the content of the parent stack, then puts the child context into a pcb slot. But these pcb slots can only tell the the kernel the pid/context of a given process -- they didn't specify which of these pids is a p
04:01:21 <royal_screwup21> arent of another...
04:01:28 <royal_screwup21> s/keep/
04:12:42 <bauen1> there is also clone() which has mostly superseeded fork() it basically let's you configure what should be inherited by the new process
04:28:02 <gog> heeeeey i just found a bug that's been my bane for a day
04:28:23 <gog> my bootloader doesn't handle elf segments with p_filesz = 0 correctly
04:28:31 <eryjus> yay!!
04:29:00 <gog> six characters to fix it how little it takes to make a bug
04:29:02 <zid> neat
04:29:06 <zid> bss, I take it?
04:29:15 <gog> yeah
04:29:27 <gog> it was passing 0 to EFI_FILE_PROTOCOL.Read()
04:29:29 <zid> should have stolen mine ;)
04:29:32 <gog> which would try to read the whole file
04:30:02 <gog> then it would overrun its buffer and cause havoc
04:30:40 <zid> yea typically you'd just load it all anyway though
04:31:03 <gog> my loader loads selectively
04:31:23 <zid> There's nothing in my kernel ELF which doesn't get loaded so I don't have to not do that, but it'd handle not doing it just fine
04:31:24 <gog> it's eventually gonna be able to do fixups so i can have modules
04:31:37 <zid> so you still need to load things that don't need loading, symtab etc
04:31:49 <zid> might as well just load the entire file
04:32:03 <zid> at worst you have an extra .comment section or something right
04:33:39 <gog> i was loading the whole image before i might go back to that
04:33:53 <jjuran> Gog's Bane is slain
05:02:37 <stisl> hi
05:03:14 <stisl> does anybody have some simple elf loader which parses multiple sections?
05:03:47 <stisl> mine is loading some shit into the memory
05:04:03 <zid> https://github.com/zid/boros/blob/master/boot/main.c
05:04:07 <stisl> th
05:04:08 <stisl> thx
05:04:53 <zid> technically you want to check for PT_LOAD on 231 before calling map_section, but my kernel elf only has loadable sections
05:05:34 <zid> so technically you'd want to do erm.. if(p->p_type == 1) map_section()
05:08:42 <stisl> It would be easier for debugging purposes to print out the sections while loading
05:08:49 <zid> It does, line 130
05:09:11 <stisl> only the address
05:09:14 <stisl> I mean the name
05:09:23 <zid> That'd require parsing .strtab
05:09:40 <stisl> I need to parse strtab for my debugger
05:09:47 <zid> so add it, it's not easier lol
05:09:48 <stisl> to get sth. readable
05:10:00 <zid> and actually, those don't have names
05:10:03 <zid> only indicies
05:10:14 <stisl> ok
05:10:43 <stisl> the elf format doesn't have normally saved the name of the section?
05:11:06 <zid> sections yes, program header entries no
05:11:16 <zid> there's no mapping from what you load to what has names
05:11:22 <zid> only sections, for tools like debuggers etc
05:12:11 <zid> sections headers decribe the file, program headers describe the memory/environment the file creates
05:13:47 <stisl> so what is for example then .text or .data
05:14:00 <stisl> or .bss
05:14:02 <zid> https://cdn.discordapp.com/attachments/417023075348119556/575369738159521804/unknown.png
05:14:41 <zid> so I end up with two map_section calls, for 00 and 01
05:14:41 <stisl> ok, understand
05:14:57 <zid> which loads .text+.data and .data+.bss, respectively
05:15:11 <stisl> if you have something like .rdata or .xdata or .bladata
05:15:20 <zid> notice how for 01, filesize and memsize don't match
05:15:24 <zid> that's how you know bss is in there
05:15:43 <zid> there are bytes of memory with no bytes of file backing them
05:16:09 <zid> which is handled by the if on line 134
05:16:49 <stisl> could it be that sth. initialized is in the .bss segment?
05:17:09 <zid> bss is for static storage duration objects
05:17:21 <zid> with no initial value
05:17:28 <zid> if you initialize it, it becomes data
05:17:45 <stisl> so this could then be a problem
05:17:50 <zid> for who for what reason
05:18:38 <stisl> when there are some initialized things in
05:18:58 <zid> in... ?
05:19:00 <stisl> I think I saw with a disassembler some initialized .bss segments
05:19:07 <zid> Then they're wrong
05:19:21 <stisl> so that the half of the .bss segment is initialized and the rest of it not
05:19:26 <zid> bss is cleared by the execution environment
05:19:35 <zid> crt0.S for glibc
05:19:37 <zid> etc
05:19:56 <zid> else it isn't a valid execution environment for C, and your C code all explodes despite being conformant
05:20:21 <zid> or the opposite way around
05:20:24 <stisl> ok, so I can assume that .bss is zeroed
05:20:34 <zid> yes, that's sort of the point of it
05:20:46 <zid> so you can have a load of statics but they don't have to appear in the file
05:21:14 <zid> unless you want char global_arr[1*1024*1024]; to consume 1MB of filesize for no reason
05:22:22 <zid> (when they're all just going to be 0)
05:22:30 <stisl> thats maybe why my kernel needs 60 MB of RAM
05:22:54 <zid> well if you tell C that you have a 60MB object full of zeros, someone has to make it exist :p
05:23:33 <stisl> I do this currently, the problem is that it parses too much bullshit so that it will be overwritten
05:23:49 <stisl> with some strange addresses
05:23:58 <zid> time to add shit load of asserts
05:24:04 <zid> and actually understand what it is you're trying to do a bit better
05:25:09 <bauen1> asserts are the way to c heaven
05:25:30 <stisl> I miss really some exception handler for this
05:25:30 <bauen1> actually, they're just a gateway drug to functional programming
05:26:09 <stisl> I found some tiny longjmp implementation for this
05:26:20 <stisl> but don't have time for this
05:26:55 <stisl> I just need some try catch mechanism so that the functions will be stopped
05:27:26 <stisl> just returning without a value is maybe to dangerours
05:28:01 <stisl> thats currently the only thing in C i miss, the exceptions
05:28:10 <zid> 'return'
05:28:21 <zid> it has a special keyword for stopping functions when you detect certain states
05:29:47 <stisl> for a unit test suite this could be also important
05:30:33 <stisl> currently I am asserting in states which I know that the crap is already going on
05:31:00 <stisl> and I am to lazy for if(rerror) return bla
05:31:23 <stisl> and it makes it hard to read when you are doing this arround the call stack
05:31:44 <zid> sounds like a you person
05:31:46 <zid> err
05:31:47 <zid> a you problem
05:32:54 <stisl> maybe, I don't know how expensive a longjmp really is
05:33:21 <stisl> but if you really have to freeze the old state it must be realy expensive
05:35:23 <stisl> so very try must then do sth. like a duplication of the used memory in the worst case
05:35:34 <stisl> so that you can happily go back
05:37:05 <stisl> but memory is cheap nowadays, for this I am also too lazy
05:37:13 <stisl> -o
08:32:53 <mquy90> eryjus, zid I finally understand recursive page directory :D
08:34:10 <eryjus> mquy90 -- outstanding!
08:36:41 <zid> oh good
08:37:45 <zid> [16:13] <zid> so if 0x1A00 is also 0x1000, we're back at square one like nothing happened, and the PD will then get used as though it were actually a PT too. Being the theory.
08:37:50 <mquy90> I missed the point of accessing the last page table and set value to it will modify those physical memories which are assigned to page directory
08:37:52 <zid> so random garbage like this makes sense nose? :P
08:38:09 <zid> nose? now
08:38:16 <zid> freduian slip, I love noses
08:39:40 <doug16k> mquy90, nice
08:40:10 <mquy90> thanks eryjus, zid and doug16k for helping me to figure it out :+1:
08:51:52 <stisl> is an overlapping ELF-Section valid?
08:52:10 <zid> If you can figure out how to load it, go for it :P
08:52:35 <stisl> then maybe sth. with the parser is going on wrong
08:52:48 <zid> print moar
08:53:04 <stisl> it is a bss section
08:53:17 <stisl> there are two bss sections beginning with the same VA
08:53:24 <stisl> but one is longer
08:53:25 <zid> I don't think ld will even let you create such a file
08:53:28 <zid> how did you manage that
08:53:50 <stisl> I will have a look into the linker script
08:56:05 <eryjus> stisl, i wrote a simple loader but I also put some rules in place as to what was valid for what would be loaded... for example, the read only bits and read/write bits need to be on separate pages. it made my life easier for the purposes of getting my kernel loaded.
08:57:13 <stisl> eryjus, thx for the motivation ;)
08:57:46 <stisl> my sections are not page aligned
08:57:48 <stisl> hups
08:58:09 <zid> well that's no good
08:58:10 <stisl> but the linker script says sth. else
08:58:37 <stisl> . = ALIGN(4096); will hopefully align it
08:58:38 <zid> is this because you're loading the file in a billion pieces
08:58:45 <zid> just align the entire section
08:58:47 <zid> no need to mess with
08:58:48 <zid> .
08:59:00 <zid> https://github.com/zid/boros/blob/master/linker.ld Is my kernel's linker script
09:00:04 <stisl> do i need exception frames?
09:00:14 <zid> Isn't that a question for you to answer
09:00:19 <zid> I don't know how your kernel works
09:00:27 <stisl> or other question are they easy to handle
09:00:37 <zid> Couldn't possibly tell you
09:01:13 <stisl> maybe I need them, because of hubsan
09:01:29 <stisl> I don't know
09:01:43 <zid> I don't recommend using tools you don't know how to use
09:01:47 <stisl> but I use actually hubsan,and I catchedsome bugs with it
09:02:52 <eryjus> stisl, my linker script is a bit more involved -- for reference. https://github.com/eryjus/century-os/blob/master/modules/kernel/util/x86-pc.ld
09:03:09 <eryjus> I also know doug16k has a crazy involved one if you get interested in that
09:03:51 <stisl> debugging sections are needed
09:04:19 <zid> don't discard them, put them in a phdr that doesn't load
09:04:21 <zid> gg
09:05:50 <stisl> currently I could live without them,because I build an elf file with debugging symbols, parse them and compiles them into a struct in,compile the kernel again with the struct and then strip the kernel
09:06:31 <stisl> but this is a little bit too complicated I think
09:07:23 <stisl> hubsan can figure out line numbers and so on
09:07:40 <stisl> I don't know exactly how it works internally
09:19:35 <androidirc> Hi, i have a problem. Im trying to do a 64-bit kernel. When i try to return from the lgdt and the cs fix function to my main c code, the system restarts, after thinking, i did actually save the eip, but i cant access the cs register, so my question is: is there a way to access(read, write, push, pop) the cs reg? Thanks!
09:20:28 <zid> jmp
09:20:30 <bcos> androidirc: Were you in 32-bit code before trying to load CS?
09:20:41 <bcos> (e.g. reloading CS to switch to 64-bit)
09:21:02 <androidirc> i was in compatibility mode, so yes
09:21:33 <bcos> Then you can do a far jump or use RETF or IRET
09:22:16 <bcos> However, if it's a function then the 32-bit caller would've given you a 32-bit return address so you can expect that'll never make sense
09:23:23 <androidirc> Well, that doesnt actually work, just triple fault. Thats due im doing call 0x08:flush_cs. Then in flush_cs i have retf. But then i cant return to the c code.
09:23:45 <zid> how are you going to 'return' anywhere, given you're now a different ISA entirely
09:27:07 <androidirc> Ok..? I have a c code, which calls gdt setup gdt. then i set data segments, then flushes the cs reg with a far call. But when i return from the far call, i try to return to the main c code and continue excecution, but in that try for returning to the main c code, it triple faults(#GP)
09:27:27 <zid> you have main compiled for two ISAs simultaneously?
09:28:21 <androidirc> O.o im compiling 32 bit code
09:28:32 <bcos> Typically you want a nice linear ("function-less") piece of code written in assembly and not C, starting from a 32-bit entry point, which sets up page tables and enables long mode, switches to 64-bit then jumps to where the kernel was mapped at about 0xFFFFFFFF80000000
09:28:41 <zid> [22:20] <bcos> (e.g. reloading CS to switch to 64-bit)
09:28:41 <zid> [22:21] <androidirc> i was in compatibility mode, so yes
09:28:58 <zid> how are you going to execute the rest of 'main', if main is 32bit and you are 64bit
09:29:52 <bcos> ..where the first function written in C is 64-bit and linked for that "at about 0xFFFFFFFF80000000" virtual address
09:30:42 <doug16k> androidirc, why call. use jmp instead
09:30:49 <doug16k> to load cs I mean
09:31:25 <androidirc> Yeah, now i remember. If i compile the bootloader.asm(mboot header actually) for 64 bit grub doesnt recognise it, and for 32 bit some things and others for 64 the ld does not link, and gives me an error
09:32:44 <androidirc> Because i wanted to return to main c function and with a far jmp, i dont push cs and eip(or rip, im not sure, i should investigate more)which a far call does
09:33:41 <zid> grub-0.97 can't load 64bit elf files
09:33:45 <doug16k> so you want to load cs and call c in a different mode all in one instruction. good luck with that puzzle
09:34:01 <zid> so I use two stages, grub loads a 32bit elf which loads the real kernel and switches to long mode in assembly then jmp's
09:34:32 <bcos> In theory (if you're brave); you can have a "multi-boot 1" header and a "multiboot 2" header; with 3 entry points (32-bit BIOS, 32-bit UEFI, 64-bit UEFI) where both 32-bit entry points switch to 64-bit and they all end up at the same "main" eventually
09:34:53 <stisl> this doesn't work on my machine
09:35:12 <androidirc> Ok. Does grub 2.0 compile 64-elfs?
09:35:18 <zid> ..compile?
09:35:18 <bcos> Compile?
09:35:26 <androidirc> Compile, my god
09:35:29 <zid> load?
09:35:31 <zid> I believe so
09:35:33 <androidirc> I was saying load
09:35:38 <bcos> GRUB 2.0 supports 64-bit ELF for UEFI at least
09:35:45 <zid> but I personally have never used it
09:35:49 <bcos> ..but not sure about "not UEFI"
09:35:52 <zid> we helped some other guy get it working recently though
09:35:57 <zid> via multiboo2
09:36:08 <stisl> the multiboot efi support isn't so good
09:36:21 <zid> I've also never used efi/eufi
09:36:39 <eryjus> androidirc, just make sure your elf page size is reasonable -- like 4K or 8K
09:37:10 <eryjus> the default will put the mb2 header beyond where grub looks for it
09:37:28 <androidirc> ok. Thanks
09:39:53 <stisl> with multiboot2 they have seperate efi tables, so that you have to mess arround all the different configurations
09:48:56 <stisl> I think I didn't get it: Is it normal that ELF sections are not page aligned?
09:49:50 <zid> not on systems with mmus
09:49:55 <zid> potentially yes on systems without them
09:51:08 <stisl> but they are a little bit aligned it looks like
09:51:19 <zid> For an example binary, my 'ls' on my desktop, the PT_LOAD segments are page aligned (to 2MB pages) and all the NOTE, STACK, INTERP etc segments are byte/word/etc aligned
09:51:50 <zid> the individual sections are erm
09:52:25 <zid> aligned on 1/2/4/8/16/32 byte alignments variously
09:52:56 <stisl> I think I got it: A section is smaller entity than a segment
09:52:57 <zid> which is fine because the parent segment/phdr are aligned in memory, it just means .data and .bss don't have a big gap between them
09:53:21 <zid> PT_LOAD 00: [.data | .bss]
09:53:33 <zid> .bss is 4 byte aligned, so it comes 0-3 bytes after .data depending how long .data is
09:53:48 <zid> but phdr 0 is 4k aligned, so .data starts on a 4k boundary
09:54:14 <zid> They share the same flags in the MMU, hence the grouping in the PHDRS, so it doesn't matter if they share a page in memory
09:55:14 <stisl> So: A program like a kernel contains multiple segments which should be page aligned and a segment contains multiple sections
09:55:31 <zid> On linux machines, .rodata tends to be executable for this reason
09:55:40 <zid> because it's inside the same phdr as .text
09:55:54 <zid> stisl: I showed you my readelf output, that's really all there is to it, on your end
09:56:23 <zid> I showed you my elf loader too
09:56:43 <stisl> zid, thanks
10:08:19 <doug16k> stisl, you have to tell it to align output sections
10:09:05 <doug16k> generally you align at each section where page permissions change. if you have text first it would be r-x, r--, rw- (executable readonly, followed by readonly, followed by readwrite)
10:09:52 <doug16k> so for that you would align text to 4KB, align rodata to 4KB (the first non-executable one, whatever it is), and align .data (the first writable one, whatever it is)
10:10:22 <doug16k> then it is possible to make the rodata and data no-execute permissions, and make only the readwrite section writable
10:10:40 <stisl> that would be a little bit cleaner than under linux
10:11:28 <stisl> I also don't need no self modifiying programs
10:11:39 <stisl> -no
10:13:26 <stisl> but it would be interesting if there are some practical use-cases for it ;) I mean not malware
10:15:03 <doug16k> it can be legitimate for micro-optimizing extremely hot code paths
10:15:36 <stisl> ah, ok
10:15:41 <stisl> I understand
10:15:57 <doug16k> that is a far afield case though. 99.9999% of the time you never modify instructions
10:16:16 <zid> It lets you 'inline' function pointers, most usefully
10:16:34 <stisl> but I don't like JIT-Compilers, they are faster than a pure VM but not so fast in my opinion than the code on the real machine
10:16:48 <zid> so that you don't have to do the level of indirection required, so if you have a dynamic hotpath (say, amd vs intel codepath) you just chang the call instruction, rather than having to do an indirection per invocation
10:17:01 <doug16k> eventually you'll want to make it possible to make a user program JIT code. for that they will need to be making data pages executable
10:17:36 <doug16k> that is "self modifying" in a vague sense, it modifies the garbage code it got from allocating memory into JIT code :)
10:18:11 <stisl> which costs a lot of memory and could also be slow
10:19:11 <stisl> ok,with javascript it is really fast i think
10:19:12 <doug16k> relaxing permissions is usually cheap, architectures will raise a spurious page fault if they have cached more restricted permissions
10:19:39 <doug16k> harmlessly. restricting from executable to not executable would be much more expensive
10:20:12 <doug16k> it would have to ensure that other cpus flush out those entries from TLB in a timely manner
10:21:37 <doug16k> on x86 for example, going from not-present to present, or read only to writable, or not-executable to executable, or user to supervisor does not require any TLB invalidation on any CPU
10:21:43 <stisl> doug16k, there are some bits in a page which can be used by the user
10:22:25 <stisl> sorry
10:22:35 <stisl> I didn't get it to end,
10:23:05 <stisl> I mean can I use these bits in order to manage all my allocations
10:23:22 <stisl> so that I don't need sth. like a seperate Page-Bitmap?
10:23:38 <doug16k> example: let's say the CPU cached that address X is read only. let's say that now you relaxed permission, allowing a thing which was not allowed before (writing/executing/etc), without any invalidation
10:24:39 <doug16k> if you then go write it or execute it or whatever permission you relaxed, the page fault will happen, but the page fault handler will see that it was spurious (unexpected) and it will just return and the cpu will reread the page tables
10:25:09 <doug16k> point is, not all page permission changes are expensive
10:25:21 <doug16k> only restricting permission is nontrivial
10:25:30 <stisl> hmm
10:25:41 <doug16k> going from writable to readonly, or executable to noexecute, supervisor to user
10:25:53 <eryjus> doug16k, isn't that because an interrupt invalidates the TLB?
10:26:59 <doug16k> eryjus, it's because it doesn't matter if it caches that it is readonly after you make it writable. the first time you go to write it the cpu will fault because tlb says it is still readonly, but the page fault handler looks at the actual page table entry and sees it was spurious, so it just returns from the page fault and the cpu rereads those entries
10:27:22 <doug16k> x86 guarantees that it invlpg already for you at fault location when a #PF occurs
10:28:25 <doug16k> so it is ok to get a fault you shouldn't get, we can just ignore it, however, it isn't so simple the other way...
10:29:07 <doug16k> you can't just ignore that it became readonly if it was writble, there won't be any fault, all cpus will keep thinking it is readonly if they had it in TLB
10:29:28 <doug16k> oops, keep thinking it is writable
10:30:38 <doug16k> you have to force all CPUs that may have run code that uses that address space to flush that region from TLB
10:31:04 <doug16k> hopefully soon
10:31:11 <eryjus> Hmmm... so, better to invlpg if you change permissions to ensure that the cpu has the correct flags and know if you get a #PF it's for real, than to get a #PF and try to convince yourself that it was a mistake.
10:32:06 <doug16k> invlpg is pretty expensive. also other cpus have TLBs too
10:32:46 <zid> so your advice is just to not bother, and handle any faults it causes instead? (With the assumption that the faults may NOT happen, and you saved an invplg?)
10:33:36 <eryjus> expensive compared to an exception that will likely involve a permissions change? zid's point might be valid -- what are the changes...??
10:33:37 <doug16k> I am saying that for relaxing permissions, you should do nothing. going from not present to present or readonly to writable or noexecute to executable or supervisor to user
10:33:40 <zid> but only under relaxation, if you're tightening the permissions you don't want some cpu thinking it can write instead of read
10:33:54 <zid> err write instead of not being able to
10:34:12 <eryjus> i c
10:34:19 <doug16k> right, in the other direction you must invalidate, because you can't have this or other cpus thinking it is still okay to write or whatever
10:34:52 <zid> but you MAY get faults in the relaxation case, which you need to ignore
10:34:53 <bcos> Chances are if you're changing page table entries it's because someone is about to access those pages, so for the current CPU INVLPG is better than "likely page fault then INVLPG". You'd only do the lazy TLB invalidation to avoid sending IPIs to other CPUs
10:35:12 <doug16k> if you skip it when relaxing permission, often the program won't even touch that region anymore, so it won't cost a thing
10:35:27 <zid> bcos: Sounds like we need a per-cpu invlpg?
10:35:39 <bcos> If the program won't touch the area, why did it bother asking for the area to be changed in the first place?
10:35:44 <zid> invplg with no qpi nonsense, because we the programmer know that no other cpu holds a tlb entry
10:35:51 <doug16k> bcos, that cpu might not touch it
10:36:04 <doug16k> might be a worker thread's buffer or something
10:37:05 <doug16k> it is tricky though. in some cases eagerly doing it will be faster
10:37:10 <bcos> Also note that "INVPLG + multi-CPU TLB shootdown" is also needed when you change things that have nothing to do with permissions - e.g. accessed/dirty flags, cache type
10:37:53 <bcos> (d'oh - physical address)
10:42:01 <doug16k> zid, saying you save "an" invlpg is a strawman. what if you relaxed permission on 400MB
10:42:39 <zid> wouldn't that potentially cause a thousand page faults, or require a thousand invlpg's either way?
10:42:48 <zid> when is it not 1:1?
10:42:55 <doug16k> oh the program digs through it all immediately does it?
10:42:58 <bcos> In that case, reload CR3 (or diddle CR4) or do a task switch early
10:43:28 <doug16k> rampages through ti all and touches them all right away? no. programs are notorious for doing huge memory operations and touching a few pages
10:43:41 <zid> doug16k: I agreed with your optimization, btw
10:43:52 <zid> bcos was the one devil's advocating against it
10:44:10 <zid> save the 1000 invlpg's and instead service some fraction of that as page faults
10:44:27 <doug16k> right, not personally arguing against anyone, just trying to bring up that programs often don't touch anywhere near as much as their memory calls would imply
10:44:30 <bcos> Note: Usually if you're relaxing permissions it's because of CoW or something and it's only ever a single page
10:45:05 <zid> you can heuristic it maybe
10:45:17 <bcos> ^ the only case I can think of where you relax permissions for a large area is when you fork and one of the processes terminates, so you need to "de-clone" everything; but fork is a hideous pile of crap anyway so...
10:45:18 <zid> or have the person doing it announce it in advance
10:45:41 <zid> like VirtualProtectEx or something
10:47:54 <zid> FAULT_LIKELY there we go I named you a flag for it ;)
10:48:35 <bcos> :-)
10:50:53 <stisl> is anybody using the page flags which are reserved for the user?
10:51:11 <bcos> Those marked "available"? Yes
11:26:21 <eryjus> well, crap!! my usb-to-serial cable does not work in an xhci port...
11:26:55 <doug16k> eryjus, try putting a hub in between
11:27:11 <doug16k> easier for that to work
11:27:29 <eryjus> i saw that option -- just need to find a hub
11:28:07 <geist> dont forget if your monitor happens to have one
11:29:07 <eryjus> ok, hang on....
11:29:50 <doug16k> I mean serial thing -> hub -> computer
11:30:36 <doug16k> will hide any 2.x issue your main controller has, it will be usb 3 between computer and hub, hub will TT it
11:31:05 <doug16k> could hide*
11:31:45 <eryjus> doug16k, i have several switches but no hubs.... hahaha
11:32:02 <doug16k> you tried several ports?
11:32:06 <mischief> :slightly-nauseous-face:
11:33:27 <doug16k> keyboards have hubs sometimes too. any ports on there?
11:34:15 <eryjus> logitech wireless...\
11:34:20 <doug16k> nothing happens at all when you plug it in?
11:34:24 <doug16k> it = serial thing
11:34:40 <zid> I use my monitor when I need that
11:34:42 <doug16k> lsusb
11:35:46 <doug16k> or just `watch lsusb` and try different ports
11:35:56 <eryjus> lsusb reports it -- nothing when i try to use it
11:36:10 <doug16k> how do you use it?
11:36:55 <zid> I'd laugh if it's UHCI or something
11:36:57 <doug16k> /dev/ttySn?
11:37:03 <eryjus> 1 sec -- one more box of cables and whatnots to look through
11:37:06 <zid> it'll show up on other usb controller types, but won't work
11:37:22 <doug16k> eryjus, is this a usb debug cable?
11:37:29 <doug16k> or rs-232
11:40:01 <geist> if it's a rs232 thing yu should also see something in dmesg (assuming you're on finix)
11:40:17 <geist> usually says something about finding it and publishing ttyFOOBAR and whatnot
11:40:56 <geist> typically usb serial dongles will show up as ttyUSB<N> but sometimes they show up as ttyACM<N> for some sort of historical reason
11:41:28 <eryjus> lsusb output: https://gist.github.com/eryjus/f97a9e9312791bae8d41c2ca68f8dcda
11:41:51 <geist> that standard FTDI tingy. does it have a DE9 on it?
11:42:02 <eryjus> this is a usb to serial cable that I use to load my rpi and as a debug console for the pi.
11:42:11 <geist> should work then. dunno why you dont see it
11:42:23 <doug16k> check dmesg like geist said
11:42:26 <geist> look in dmesg, it should say something about finding it (or usb transport error)
11:42:57 <doug16k> that one looks like mine, which works fine
11:43:07 <eryjus> ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
11:43:15 <geist> ah ha
11:43:45 <geist> now it's probably fully in the land of software configuration
11:43:48 <eryjus> oops wrong message
11:44:20 <eryjus> ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
11:44:30 <eryjus> ftdi_sio 1-1.3.2.4:1.0: FTDI USB Serial Device converter detected
11:44:30 <eryjus> [ 1074.503286] usb 1-1.3.2.4: Detected FT232RL
11:44:30 <eryjus> [ 1074.504892] usb 1-1.3.2.4: FTDI USB Serial Device converter now attached to ttyUSB0
11:44:31 <Kazinsal> those things own pretty hard if you can get 'em working right
11:44:43 <Kazinsal> the PLL clock on them is like 48 MHz
11:45:04 <geist> Kazinsal: yah. they're actually non cheap. iirc a 2232 is somethig around $10 on digikey
11:45:17 <doug16k> better than fine. I run mine at 115,200 with a long (10 foot?) cable
11:45:40 <doug16k> 115200 is probably a laugh for it
11:46:02 <geist> anyway, the trick is they can also be used as a gpio bit banger, so sometimes you find it in jtag dongles and whatnot
11:46:06 <doug16k> goes > 1M IIRC
11:46:22 <eryjus> yup, doug16k, i think we have the same, if not very similar
11:46:29 <geist> or, a dual port version where one is a DE9 and the other port bottoms out on a JTAG, which can cause a little bit of trouble since you'll end up with two ttyUSB*s and only one of them is 'real'
11:47:03 <geist> the debug port on one of my FPGA boards does exactly that. you have to remember to use ttyUSB1 for serial because USB0 is fake and only used for jtag stuff
11:47:47 <Kazinsal> yea we've got like 10 of them at work that we use for consoling into routers and the like in the field
11:47:48 <geist> iirc there's a way to configure a intended-to-be-gpio one as something that wont report itself as serial, as some SWD debugger dongles do
11:47:54 <Kazinsal> hilariously they always run at like, 9600 baud because of that
11:48:05 <eryjus> https://gist.github.com/eryjus/a887cede10a14c2fcd51dd2468923132
11:48:17 <eryjus> that's a clean dmesg output when i plug it in...
11:48:20 <geist> yah fairly certain you can easily get them up to 1mbit or so. at some point you start running out of headroom with the divider off of 48
11:48:22 <zid> looks good
11:48:37 <chrisf> put a lot of those in products, they're pretty solid
11:48:37 <zid> in what way does it not work
11:48:38 <geist> but since you usually 16x oversample, you should be able to get up to 3mbit with 48/16
11:48:56 <geist> yah was about to say, we should rewind and figure out how 'does not work' applies
11:49:14 <zid> l
11:49:25 <zid> wrong window, I wanted to look at the room I was in
11:49:32 <geist> we are 1
11:49:41 <zid> geist buy a font
11:49:50 <geist> looks different on this one
11:49:54 <geist> l1
11:50:05 <eryjus> https://github.com/eryjus/pi-bootloader/blob/master/server/pbl-server.c#L577 never actually opens the device...
11:50:22 <eryjus> starting to think I should be able to debug my loader and make it work...
11:50:32 <geist> possible you dont have permission on the /dev/tty* nodes
11:50:48 <zid> is there like, a serialcat or something simple
11:50:50 <zid> to test it with
11:50:57 <geist> generally speaking unless you fiddle with groups or udev rules joe-blow users can't open any serial and go to town on most distros
11:50:59 <zid> I don't usually play with serial devices
11:51:10 <geist> i usually use minicom, though screen also works
11:51:12 <zid> or just strace it and grep for open o that device
11:51:15 <geist> 'screen /dev/ttyUSB0 115200'
11:51:17 <zid> see if it returns EPERM
11:51:34 <geist> to exit out of it you need to do ctrl-a \
11:51:38 <geist> and terminate the session
11:53:35 <eryjus> damned new laptop.. stand by I gotta load some tools. but I do notice /dev/ttyUSB0 is not o+rw....
11:54:22 <geist> i think the debian/ubuntu distros at least usually set them to be group rw by a group called plugdev
11:54:30 <geist> so i usually just add myself to that and relog
11:54:53 <geist> in a pinch i just chmod 666 the node, which sticks around until next time it gets generated
11:57:08 <_mjg> you know what's worsethan a linear scan? a loop over it
11:59:24 <zid> not on my cpu
11:59:36 <eryjus> ok, it's a permissions thing. I can get it to open and listen with a command line chmod and then it resets. I will just need to add myself to the dialout group or somethign like that
11:59:51 <geist> we dont serve those kinda scans around here