channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=8&d=17
00:22:48 <griddle> How do you guys store your inode structures in your OSs?
00:23:17 <griddle> do multiple processes share the same inode instance if two processes open the same file?
00:33:53 <griddle> Im thinking of having some kind of global structure for inodes that is indexed by the fs id and the inode index and it gives you back the inode at that index. If the structure doesnt contain that inode, it asks the filesystem at the fs index for the inode instead and caches it
00:34:08 <griddle> that way I could possibly have a daemon that walks dirty inodes and flushes them
00:35:38 <Mutabah> I use vnode handles, inodes indexes are per-volume
00:35:48 <Mutabah> and yes, inherently, they're shared
00:36:17 <griddle> so a vnode is a virtual inode? Each filesystem has their own style of vnode?
00:36:23 <Mutabah> Yes.
00:36:45 <Mutabah> a vnode in my designs is the metadata for a single file/directory
00:36:57 <griddle> Hmm I like the name 'vnode'. I currently have an inode and an inode_id class
00:37:09 <griddle> inode_id is just two ints that has a reify method to get the inode
00:37:30 <griddle> my inode seems to be your vnode
02:46:07 <azonenberg> ok this is fun, i'm trying to get newlib up and running on a (currently bare metal) embedded target
02:47:31 <azonenberg> when i call puts() i can see it calls fstat(STDOUT_FILENO), _sbrk twice, and _isatty(STDOUT_FILENO
02:47:44 <azonenberg> But it never calls write() so i never actually see any output
02:47:47 <azonenberg> same thing happens with printf etc
02:49:34 <klange> use the source, luke
02:49:40 <azonenberg> I'm doing that now, lol
02:50:02 <klange> (though this is one of the big reasons I moved to my own libc - the newlib sources are spaghetti)
02:50:21 <azonenberg> this is my first time using someone else's libc
02:50:29 <azonenberg> largely because i didn't want to have to write my own printf again
02:50:44 <azonenberg> It's early enough that i could still do my own if i wanted, though
02:51:17 <klange> again? you mean you don't just keep reusing the same shitty one you built 8 hears ago?
02:51:37 <azonenberg> well i already am using my own crt0/startup code
02:51:44 <azonenberg> i couldnt reuse the old b/c that was for mips and now i'm on arm
03:04:08 <azonenberg> yeah now that i am getting deep in newlib i am starting to hate it
03:06:07 <adu> azonenberg: join the oxidation movement
03:06:34 <azonenberg> ?
03:06:37 <adu> Rust
03:06:40 <azonenberg> oh lol
03:06:47 <azonenberg> no i'm doing this firmware in C++
03:06:58 <adu> I'm writing firmware in Rust
03:11:19 <graphitemaster> Oh god the Rust Evangelical Strike Force has crossed into here now.
03:11:44 <adu> nope
03:12:06 <adu> just me
03:12:18 <graphitemaster> One too many
03:12:34 <azonenberg> anyway, this is annoying especially since right now i dont have full gdb debug available on this platform
03:13:17 <adu> have you tried musl?
03:13:26 <azonenberg> no i was gonna try that next
03:17:16 <graphitemaster> musl is a lot more difficult to port
03:20:29 <azonenberg> well musl builds in seconds with -j vs newlib's very serial build process
03:20:52 <azonenberg> But it seems to want a filesystem
03:32:55 <azonenberg> welp, back to my own libraries it is i guess
04:04:10 <geist> azonenberg: it's probably caching up the data
04:04:17 <geist> which is why it's doing the isatty and whatnot
04:04:28 <geist> fflush(stdout); i bet will force it to write
04:08:44 <azonenberg> geist: well i'm still dumping it
04:08:54 <azonenberg> a libc that does dynamic allocation under the hood is a non-starter
04:09:22 <azonenberg> i don't plan to have any dynamic allocation anywhere in this firmware
04:09:29 <azonenberg> not going for MISRA certification or anything but reliability is important to me
04:13:25 <azonenberg> And printf is one of those functions that should simply not be capable of failing
07:22:04 <geist> azonenberg: nod. note that that's generally what libcs do, so it's not like newlib is doing anything particularly weird
07:22:24 <geist> fopen and whatnot needs to allocate memory, FILE structures usually contain a local buffer
07:22:42 <geist> 'real' libcs do that sort of thing because that's what they do
07:22:57 <azonenberg> geist: this is a bare metal deeply embedded system with no filesystem etc
07:22:59 <geist> newlib being that it can run on bare metal may have a switch to disable some of that behavior
07:23:04 <azonenberg> i guess my mistake was thinking newlib was meant for that
07:23:18 <geist> yes, i know. but there are a ton of compile switches for newlib
07:23:27 <azonenberg> i didnt see any that let you turn off that sort of stuff
07:23:33 <geist> it may be that that sort of behavior can be disabled, at the expense of not being as libc compliant
07:23:38 <azonenberg> (my printf has a tiny stack based buffer just for itoa-type conversion)
07:25:20 <geist> yes, as do most printf implementations *until* you get to proper floating point printing
07:25:24 <geist> then it becomes a nightmare
07:26:32 <azonenberg> even putc() in newlib mallocs
07:26:35 <azonenberg> somehow
07:26:41 <azonenberg> i was using iprintf too
07:27:03 <geist> well, trace it through to find out
07:27:04 <azonenberg> also you should be able to bound the memory usage of %f
07:27:13 <azonenberg> i got lost after like ten levels of function calls
07:27:15 <azonenberg> it was just way too complex
07:27:25 <azonenberg> it also bloated my firmware by 20+ kB
07:27:29 <geist> i dont think so, there are some edge cases in float where you need lots of buffer
07:27:34 <azonenberg> oh?
07:27:44 <geist> denormalized stuff, etc
07:28:02 <geist> iirc without denormalized the worst case was something like 300 or so chars
07:28:09 <azonenberg> o_O
07:28:17 <azonenberg> i would just fall back to scientific notation :p
07:28:17 <geist> float is a pain
07:28:36 <geist> my printf only handles normalized forms, and yeah its much simpler
07:28:59 <azonenberg> and for a normal embedded system i'd only be doing like %6.3f or something anyway if i did do float
07:30:56 <geist> yah
07:31:32 <azonenberg> Right now though, i'm using my printf and my own minimal implementations of the few libc functions i need like strlen
07:31:40 <azonenberg> most of what i have is C++
07:31:49 <azonenberg> I'm trying to create a CLI similar to cisco IOS
07:32:04 <azonenberg> that lets you type partial commands and use them as shortcuts if it's unambiguous
07:32:07 <azonenberg> This is... nontrivial
07:32:20 <zid`> my printf doesn't have a buffer except for float yea
07:32:45 <azonenberg> zid`: mine has a small buffer for %d since i go K&R and generate it backwards then reverse before printing
07:32:54 <azonenberg> But its like 16 chars or something tiny on the stack
07:33:09 <azonenberg> because i can trivially bound the max number of digits based on sizeof(int)
07:33:12 <zid`> oh right I do have that in some versions
07:33:24 <zid`> https://github.com/zid/boros/blob/master/print.c#L65 here's one I did it in
07:34:32 <azonenberg> The point is more, i want it to be easily to statically reason about max stack usage etc
07:34:38 <azonenberg> and heap makes that problematic
07:34:49 <zid`> there are gcc plugins for that I think
07:35:30 <azonenberg> sure but figuring out max heap usage is the halting problem basically
07:35:38 <azonenberg> max stack usage if you dont have recursion is a tractable problem
07:35:55 <zid`> yea
07:36:02 <zid`> I'd just compile newlib without an allocator
07:36:11 <zid`> did you get your interrupts working btw
07:36:37 <azonenberg> yes
07:36:52 <azonenberg> it was an incredibly obscure quirk of armv7-m combined with a bug in my jtag flash tool
07:36:54 <zid`> nice, what was it, global disable or something?
07:37:01 <azonenberg> i wish it was that easy, no
07:37:03 <zid`> oh, sounds fun
07:37:06 <zid`> do tell
07:37:25 <azonenberg> so i halted the CPU before flashing to prevent it from going haywire and potentially corrupting external memory or something as flash changed under the core
07:38:04 <azonenberg> I did this by setting C_DEBUGEN, C_HALT, C_MASKINTS in DHCSR via the JTAG MEM-AP
07:38:15 <azonenberg> Then when flashing was complete, I reset the CPU
07:38:38 <zid`> guessing hard reset would have made your interrupts work then?
07:38:42 <azonenberg> Yes
07:38:45 <azonenberg> Turns out a) none of those three bits are cleared by a warm reset
07:38:47 <zid`> silly bastard :P
07:38:51 <zid`> glad you got it figured out
07:39:09 <zid`> are they software resettable?
07:39:13 <zid`> or do you *have* to power cycle
07:39:20 <azonenberg> b) setting C_DEBUGEN and C_MASKINTS in certain orders are undefined
07:39:33 <azonenberg> oh, it's resettable via jtag
07:39:44 <zid`> software resettable is better, just make sure they're in the state you want at boot
07:39:49 <zid`> in your bootloader code
07:39:54 <zid`> before you enable interrupts and stuff
07:39:56 <azonenberg> I dont think it's software writable
07:40:02 <zid`> shame
07:40:04 <azonenberg> it has to be external since when the cpu is halted it cant touhc itself
07:40:10 <zid`> can you read it out at least?
07:40:10 <azonenberg> anyway, i set the bits one at a time on consecutive writes
07:40:15 <azonenberg> yeah i think so
07:40:25 <zid`> might be worth throwing in an assert() for it in the interrupt init path then
07:40:26 <azonenberg> But these are registers that are normally not touched unless you have a jtag probe attached
07:40:38 <azonenberg> I patched my flasher and its fine now
07:40:44 <azonenberg> to exit debug mode after reset
07:40:49 <zid`> always worth documenting it physically somewhere
07:40:52 <azonenberg> also i shouldn't have set C_MASKINTS in the first place
07:41:03 <azonenberg> apparently halting debug + that bit is undefined
07:41:10 <zid`> an assert statement is a good place to do so
07:41:18 <azonenberg> halting alone is sufficient to mask interrupts
07:41:47 <zid`> it'd be a pretty useless halt I guess, if it just carried on doing interrupts
07:42:10 <zid`> given how most code is timer irq driven
07:42:19 <azonenberg> yeah exactly
07:42:39 <azonenberg> i just assumed, i guess, that you had to do both bits to halt it fully
07:42:42 <azonenberg> turns out no :p
07:43:34 <azonenberg> I think the reason the bits arent cleared by warm reset is intentional
07:43:46 <azonenberg> they want you to be able to set C_DEBUGEN / C_HALT and reset
07:43:54 <azonenberg> then have the CPU halt at the beginning of the startup code
07:43:56 <zid`> that and it never lost power
07:44:03 <zid`> the cpu's reset pin would have to drive that circuit
07:44:06 <zid`> and that'd be gross
07:44:23 <azonenberg> i mean yeah warm resets that clear thesmelves is a fun chicken/egg problem
07:44:23 <zid`> It'd be a very x86 thing to do, but a very anti-arm thing to do :P
07:44:25 <azonenberg> lol
07:44:38 <azonenberg> and well i didnt reset with the cpu reset pin
07:44:57 <zid`> so you didn't even do a warm reboot, you just poked the program counter or something?
07:45:17 <zid`> That's not even a reboot that's a.. reset vector call? :P hot reboot?
07:45:26 <zid`> boiling hot reboot with 3rd degree burns
07:45:50 <azonenberg> i did a soft reset by writing to AIRCR.SYSRESETREQ
07:46:08 <zid`> that's a bit like a software invoked reset pin?
07:46:20 <azonenberg> it causes the ARM core to begin executing from its internal rom reset vector
07:46:35 <azonenberg> that rom does a soft reset of all peripherals, puts stuff in known states, then jumps to your entry point
07:46:45 <zid`> sounds like it yea
07:46:49 <azonenberg> by reading the vector table from the start of flash
07:52:32 <graphitemaster> geist, note that in the case of puts, which adds a newline, the contents have to be flushed, since there's a newline
07:52:59 <graphitemaster> so he shouldn't need to flush the stream at all, it's implied by how stdio is required to flush contents when a newline is encountered
07:53:26 <azonenberg> yeah i think there is something else going on - write(2) never got called
07:53:33 <azonenberg> it was easier to drop in my existing printf than to debug further
15:22:10 <bluezinc> azonenberg: dodm
15:22:20 <bluezinc> azonenberg: didn't expect to see you here.
15:57:56 <geist> graphitemaster: yah but that also has somethign to do with if it thinks it's a tty or not
15:58:02 <geist> and i forget what the details are
22:06:32 <azonenberg> bluezinc: i was a regular here years ago when i was doing PICnix stuff and then occasionally while working on antikernel
22:06:46 <azonenberg> Then kinda disappeared for a while but now i'm back doing low level software and not just 100% FPGA like i was for a while