00:45:46 best option to query how many pages in and pages out swap has done recently? vmstat # outputs a ton of info not just paging, vmstat -s outputs lots of paging info but totals, not recent 00:46:38 and if vmstat is my best option, what's the best way to smooth the paging pi po values? second by second sucks because it's erratic. would i run vmstat 60 to get the total per minute then divide pi and po by 60 to get the secondly avg? 01:20:34 oh it looks like vmstat 60 does its own smoothing! 01:24:34 what does -w / wait do? i read the man page entry for it a few times but i don't get it 01:27:24 See the EXAMPLES section. 01:29:21 oh i had them mixed up, now i get it ty! 01:30:25 is there no way to limit the output to just the 'page' info, or more specifically just pi/po ? 01:34:22 Maybe with the --libxo option? 01:35:37 ya but that doesn't let me filter the output, just gives me json output i can then filter myself 01:35:43 which i'll do if i have to i was jc 01:37:28 * V_PauAmma_V nods. 01:38:09 btw the vmstat first output is since machine boot up i guess? there a way to skip that? 02:24:39 is there a way i can see if my disk io is clogged? 02:29:13 gstat 02:32:52 ty zi! do you know what %busy means? does it mean that 100% is when disk io is maxed out and less than that means it has more io capacity? 02:33:16 man gstat? 02:33:38 nothing for "busy" 02:36:50 ok found some info on a webpage 02:38:41 damn i wish gstat supported libxo output 02:38:46 it's a great util 02:50:29 Koston I haven't in much detail, the logs are pretty sparse: https://gist.github.com/Davis-A/1eddd07d8ca84b7ce8ae979b230ec11f 04:32:55 kerneldove: there is a thread on dev-commits-src-all@ about your unbound problem: https://lists.freebsd.org/archives/dev-commits-src-all/2025-October/061576.html 04:42:41 thx for DISTDIR fixes 05:54:08 ivy where in that page does it talk about the issue i had? or was it in response to what i brought up or? i searched page for SNDBUF and SOCKOPT but didn't get matches 05:54:46 https://lists.freebsd.org/archives/dev-commits-src-all/2025-October/061591.html oh there we go! 05:56:34 right, i linked the first message in the thread, jlduran's reply mentions your issue 05:59:14 "it's not just you, a user on IRC also reported this issue on a system 05:59:14 with 256GB memory. i would be inclined to add so-sndbuf: 0 to the 05:59:14 default configuration, but i haven't looked at the actual problem 05:59:14 here in detail (i don't use local_unbound myself)." fwiw, i pkg install unbound, not local_unbound 06:01:19 i kept the leaf threads open, https://lists.freebsd.org/archives/dev-commits-src-all/2025-October/061613.html and https://lists.freebsd.org/archives/dev-commits-src-all/2025-October/061612.html 06:01:31 if more info is requested i'll provide it or help out where i can 06:02:08 sorry i didn'topen a pr, i've just been burned so many times by so many software projects where i open really nice bug reports that i put a lot of time into and nothing ever happens that i'm nihilistic 06:02:45 you're helping to fix me tho so ty 06:36:32 Is anyone daily driving BSD? 06:36:46 On PC or laptop? 06:37:06 for desktop? not currently, i have in the past. assuming you mean FreeBSD 06:43:12 I am 06:50:00 innk i use fbsd daily on desktop and server 06:50:25 have for like 5 years now 07:10:47 i need recent swap paging info. is there no way to make vmstat not output stats since last reboot for the first output? i've read over the man page and don't see a way 07:13:01 kerneldove: vmstat 1 2 | tail -1 ? 07:13:52 this makes me wonder: 07:13:52 procs memory page disks faults cpu 07:13:53 r b w avm fre flt re pi po fr sr ada0 ada1 in sy cs us sy id 07:13:53 0 0 0 4.6T 3.6G 1.6k 5 1 0 1.8k 4.6k 0 0 273 22k 11k 1 7 91 07:14:08 is it reporting free virtual address space as avm? i do not have 4.6TB of memory, so this doesn't seem accurate 07:14:37 that seems to work, ty, but it's pretty convoluted to not be able to just pass an option and not get the 'since reboot' data 07:14:50 ah, avm is "mapped virtual memory" 07:15:18 kerneldove: vmstat reports counter data, so it has to run at least twice if you want real-time data 07:15:48 weirdly the output with the tail part looks diff than when the tail part isn't on there. without tail, stuff like avm has G suffix, with tail, avm looks to be in bytes 07:15:50 like wtf 07:16:07 kerneldove: refer to the description of -h in vmstat(1) 07:16:07 but why can't it do that internally and suppress the 'since reboot' part 07:16:30 well, you're welcome to add a flag to do that, although i'm not sure i really see the utility 07:16:40 s/vmstat(1)/vmstat(8) 07:17:03 but in general, the answer to "why doesn't it do X?" is that you didn't submit a patch to make it do X yet :-) 07:17:09 historical reasons:) 07:17:13 because i'm trying to parse json output of, say, last 60 seconds rather than since reboot, for system monitoring. so i gotta pass -c 2 and ignore first row 07:18:27 it's wtf, but allwinner h3 r*ALSO* boots with uboot at 128k, not 8k as everyone but 1 says 07:19:20 doh i fingered the red colodcode off 07:20:49 IMO, even for human interface the counter value "since boot" is useless, so it has to be artefact from initial implementation and noone cared to drop it... 07:20:59 if i would have knew this before, i would have went direct gpt eh 07:22:11 tsoome_, ya it would be great if there was an -o(ption) to suppress the 'since reboot' data. then it atleast preserves historical behavior 07:23:27 tsoome_, do you know what -w wait does? obviously it throttles readings for # seconds, but how does it affect the values? i've tested and it doesn't sum the values up. it seems more like it kinda averages/smoothes them over the period of time? 07:23:27 ok well, if you build your statistics collector by using absolute values (and calculating difference from last run), then vmstat 1 1 would make sense... 07:23:56 that doesn't really make sense in context of pi po data 07:26:08 -w and -c are same as wait and count arguments. 07:26:23 ya i know 07:26:45 will -w average 5 seconds of pi/po data? 07:26:51 it doesn't sum it i know that 07:29:14 ivy, there is no such thing as "free virtual memory" 07:29:46 Koston: i disagree, there is a limit to the size of virtual memory, so used (mapped) virtual memory subtracted from total vm size would be free virtual memory :-) 07:29:55 kerneldove its just counter value during 5 seconds. 07:30:21 tsoome_, not of pi po it isn't 07:30:27 ivy, well technically you're correct, but that's hardly meaningful on any 64bit architecture 07:30:36 otherwise they'd continually grow or smth 07:31:19 ivy, and even then it would only apply per process 07:31:55 Koston: it somewhat is, since no 64-bit architecture (that i'm aware of) actually supports a 64-bit virtual address space. i think at least on amd64, typical limits are 48 bits or 52 bits, depending on how new the hardware is. although in practice, yes, this isn't something most people run into 07:33:15 tsoome_, with a box that's using swap and hence has some pi/po action, run 2 cmds: vmstat 1, and vmstat -w 15, and you'll see what i mean 07:34:06 ivy: any process that gets even close to exhausting the limit is most likely defective anyway 07:34:43 Koston: are you sure? mmap() can use a lot of VM and disk arrays are pretty big nowadays. 48 bits is only 256TB 07:35:18 hence the "most likely" 07:36:42 but I guess it also depends what you consider defective. many scripting languages seem to make a habit of reserving insane amounts of VM with little beyond hello world 07:36:58 (memory overcommit was a mistake) 07:37:03 sorry to fanboy but rust ftw, every time 07:37:18 i've done c and a bunch of other langs. rust ftw every time 07:38:59 rust is very attractive on paper, but in practice I haven't yet decided if its complexity is worth it 07:40:27 the learning curve is steep, but it pays dividends for the investment. thing of the other things it eases as a smoothing function over the lang complexity. the cargo/crates ecosystem is awesome, and the maintainability it adds to code is insane. to say nothing of the bug elimination which is usually the first thing ppl praise 07:40:46 i like the idea of rust but i am extremely dubious about cargo. i realise you don't *have* to use cargo, but... 07:41:14 why? 07:41:14 kerneldove: what do you mean by "maintainability" ? 07:41:43 to be able to jump into code i wrote a year ago, make some mods, and if it compiles it's usually correct, makes it SO much easier to maintain code over time than any other lang i've used 07:41:54 ...but you said you've used C 07:41:57 yea 07:42:00 which is ISO standardised 07:42:11 kerneldove: what we've learned from npm is that having a bunch of tiny packages such that every project depends of hundreds of independent packages is a terrible way to build software, especially when it relies on some central infrastructure to distribute them (see: Ruby Central) 07:42:17 rust has and is changing at breakneck pace compared to C 07:42:26 nah not anymore 07:42:53 i'm finally tracking -stable as of a year ago, first time since i started using it over 5 years ago 07:43:05 was using -nightly since starting up till then 07:43:54 ivy well you can run your own crates server so you don't /need/ to rely on crates.io. and the bunch of tiny code made by others issue is resolved by it being a more correct, rigorous lang. npm i s aprob because it's js 07:44:05 and actually lots of tiny crates is a good thing for fast compiles 07:44:34 kerneldove: "running your own creates server" doesn't really fix everything if everyone assumes you will be using crates. compare this to how C and C++ libraries usually work: they're typically larger and more self-contained 07:44:38 ivy: nowadays there are mechanisms in place to mitigate biggest problems with centralised mound of packages, namely forced versioning and checksumming. but tracking down bugs in a dependency hell is still hell. 07:44:41 s/creates/crates 07:45:36 ya i mean i'm with you on crates.io centralization, but in practice, using rust including with its crates ecosystem, is so f'ing nice i'll never go back to anything else 07:45:54 i make better, faster, less buggy code, that's more maintainable, than any other lang/ecosystem i've ever used 07:46:13 i don't doubt it's nice to use or they wouldn't have designed it this way. my concern is the less obvious implications of that 07:46:14 i FEEL better as a dev, the anxiety of dev and bugs is mostly melted away. i actually enjoy dev again 07:46:24 i used to have to beat off all the time to release stress and now i dont 07:46:36 there are also big benefits to the approach, especially from portability point of view. a lot of things related to differences between bsd, gnu, osx etc. can be outsourced to upstream with significant save in effort 07:46:40 well like i said, i'm with you on the centralization 07:47:13 having everyone rely on crates is the same problem as having everyone rely on Github (Go) or Ruby Central (npm) or Microsoft (vcpkg)... sure, it's nice to use, but is this really how we want to build software? 07:47:34 well again, you don't have to. so if you do, you're choosing to, not forced 07:47:55 you are forced if you can't use any third-party code because everyone who writes code assumes you're using crates 07:48:00 how would it be different with say c? 07:48:09 how do you share c code 07:48:18 yes, you are not *literally* forced to do this, but the amount of available third-party libraries is pretty important when choosing a language 07:48:24 and rust being so wickedly complex comes with an implicit benefit of it being used mostly by rather intelligent people with a lot of attention to detail, so the packages overall are quite high quality and well maintained 07:48:25 kerneldove: i put it on my website and people can download it 07:48:39 you can do same with rust 07:48:45 you're missing my point 07:48:51 help me understand pls 07:48:53 i am aware you are not *literally forced* to use crates 07:49:05 you mean the culture of rust devs is to just shit it onto crates.io? 07:49:14 my point is that if all the third-party libraries assume you are using crates, and depend on crates, you are *practically* forced to interact with that ecosystem 07:49:49 like, in C++ we have Boost. you can download and use Boost from boost.org, and vendor it if you like, and it's completely self-contained. what would Boost for Rust look like? 07:50:03 well if you dl 3rd party c (from webpage), why can't you just dl 3rd party rust? (from crates.io) in both cases you dl to vendor it locally, then never have to again 07:50:13 hmm 07:50:23 i think you can vendor dl a whole crate and its tree of deps 07:50:32 would that be a solution for you? i can check 07:50:46 yes, and now you're forced to interact with the crates ecosystem, and you have to deal with all the problems caused by centralised infrastructure 07:51:14 do you see what i mean? you can't just say "you don't have to use crates" when the answer to any practical questions about not using crates is "just use crates" 07:51:21 imho it would be foolish anyway, then you'd only get the problems and none of the benefits 07:51:22 so crates are inseparable from Rust itself, as a language 07:51:27 i just don't see how it's a prob. if it became a prob, rust devs would create alternative avenues 07:51:44 ivy: that's untrue, C stdlib isn't inseparable from the language either 07:51:55 not really true, i have private local code that doesn't use any crates.io, only my private crates 07:51:57 and Rust stdlib isn't a crate 07:52:00 Koston: ? you don't have to download or vendor the C standard library, it comes with the compiler 07:52:08 Koston: obviously i'm not talking about things which are part of the Rust stdlib 07:52:15 core/std come with compiler too 07:52:46 (although i understand Go are moving towards downloading the Go standard library from github.com, which seems terrible, but i don't think Rust is doing that) 07:53:47 honestly I really think some people are trying to create unnecessary languages out of their own agenda 07:54:12 if you're talking about rust, it was needed and no equivalent existed or exists 07:54:30 "we need to do something, this is something, therefore we must do this" 07:54:31 i use rust to make web apps, cli tools, server daemons, everything. 1 lang, everything 07:54:39 nah it solves real world problems 07:54:43 rust and go are fine per se. but to divide the devs based on things that people could easily circumvent is an extra cost. 07:54:44 i'm not telling you not to use rust, if you want to use rust, use rust 07:54:45 and it does a quite good job 07:54:57 ya ofc i don't take it that way 07:55:07 but i am extremely dubious about importing Rust into FreeBSD for example, and crates are the sole reason for that. the language itself actually seems quite nice 07:55:53 ya i can see that. even i wouldn't want freebsd dependent on a centralized service. what if fbsd maintained its own crate mirror for any crate used in rust-in-base? 07:56:11 have you guys ever tried nodejs and php? out my very personal opinions they don't do much benefits in either scenarios 07:56:20 ya i've used both 07:56:25 and typescript 07:56:35 nightmares comparatively 07:56:44 and the most obvious one to get my point from is the instance of c# 07:56:52 ivy: it's a problem to be solved for the ports system. for kernel Rust support, obviously crates are not involved. 07:57:14 and like it or not, centralised packaging is a thing for most modern languages these days 07:57:36 Koston, but what about a middleground where fbsd maintains a crate mirror for any crates used in rust-in-base? 07:57:50 I fully expect the would 07:57:55 *they 07:57:59 i think that would be really nice 07:58:42 that's what Ports does already with all software 07:58:53 ya 07:59:09 so adding a crates.freebsd.org could follow the same spirit 07:59:55 Koston: there is a bunch of source code in src outside of ports and kernel, you know 08:00:06 and we wouldn't add crates.freebsd.org, we'd vendor the code 08:00:20 rust in base though, I don't like the idea much and definitely not the idea of it supporting any crate business 08:00:20 k 08:00:29 you need to be able to build src without any external dependencies, vendoring is the only way to do that 08:01:25 well obv i'd love rust in base but it's not my call. rust to me is the legit successor to C, whereas c++ failed to become that 08:01:38 i'm not opposed to vendoring a few Rust packages, we do plenty of that for C/C++ right now, but is we need to vendor 200 packages to build one library that's going to be a nightmare to manage 08:01:56 kerneldove: why c++ failed to do that? 08:02:10 because rust is better and more popular and far younger 08:02:25 but functionally? 08:02:26 if it didn't fail to do that rust wouldn't have had a vacuum to fill, but it did 08:02:29 i am dubious that Rust is "more popular" 08:02:41 maybe more popular in stack overflow surveys, but in actual software that is shipping today? 08:02:42 ivy: it's a tricky problem indeed. but if you think about it from the rust language devs perspective, if they didn't centralise the infrastructure then *they* would have portability as the "nightmare to manage" 08:03:16 although, i also don't think we should pick languages based on what's "more popular"; if rust is better than C++ we should switch based on technical merit 08:03:21 c++ suffers from the same problem as c, putting too much mental load on the dev. humans are error prone. putting the rigor into compiler and code makes it easier for the dev to not fuck up 08:03:49 that's my point, it's more popular /because/ it's better on technical merit 08:03:50 I still kind of consider rust to be under the "amateur" and "experimental" categories despite recent popularity 08:03:55 ivy: but then we'd be all writing haskell or lisp 08:04:02 recent btw 08:04:04 ivy: just that, at least I'm far too stupid for either of those 08:04:22 vs 50 years of C, sure, but it's about a decade old now from 1.0 08:04:26 kerneldove: but it's not more popular. how many video games written in Rust shipped in 2025 compared to video games written in C++? what about productivity applications? what % of ports applications are written in Rust? 08:04:31 black: me too tbh, but it is interesting 08:04:53 how much of Linux is written in Rust? Windows? macOS? FreeBSD? 08:04:54 rust is only popular among rust developers, he he 08:05:07 and how much of that code was created before rust existed? compare new projects and i'll bet rust is more popular than c++ 08:05:22 it is not, lol 08:05:31 kerneldove: sure, and if we could simply throw out all existing code, a lot of things would be much easier. meanwhile, in the real world... 08:05:31 C++ is overwhelmingly more popular 08:05:36 if there is ever a language beyond the machine code, I want it to give me as much detail as possible in plain text. 08:05:39 only from inertia, if it is 08:05:57 you wouldn't believe how popular even Java still is today 08:06:07 btw, i would bet money that more lines of C++ will be written today than lines of Rust 08:06:15 just because some morons decided a few decades ago that Java should now be taught in unis as primary first language 08:06:30 so my point, from many years of dev in many langs, is rust is not only better than all alternatives, but so much better than i actually love dev again after decades of hating it, and it will swallow the world 08:06:50 you can only argue that Rust is "more popular" if you just aren't familiar with how embedded C++ is in literally everything 08:06:59 kerneldove: rust devs have been making that same argument for nearly a decade now btw 08:07:02 ok so inertia, not technical merit 08:07:06 you can't say that omitting keywords and typedefs like python is a legitimate "good feature" 08:07:20 ya and it's happening all the time. this isn't wayland 08:07:24 'any day now' 08:07:51 by the point c++ got out I think in the sphere of programming languages the peak was already reached 08:08:05 absurd 08:08:32 literature is the basis for any human language. at least virtualbox is a very nice example of things written in c++ 08:08:36 well the peak being functional programming, but vast majority of devs aren't smart enough for it 08:08:47 kerneldove: when you say you "love dev again", you're talking here about personal projects, right? let's say there may be concerns for larger projects which are different from people's personal projects 08:08:56 I'm pretty sure rust is also too complex for most people to learn properly 08:09:08 well i have personal projects that are upwards of 50k LoC, so not toys 08:09:33 and i'm 1 dev and i can manage it just fine 08:09:39 multiple of them 08:09:49 yes, but when you are 1 dev, you do not have issues which apply to a project with 400 devs 08:09:51 kerneldove: the reason *why* you can manage it fine is because you're 1 dev 08:09:57 i have problem with merely running the rust 08:09:57 ^^ 08:10:01 nah it's because rust is great 08:10:08 heh 08:10:09 let alone write it 08:10:13 it's a power multiplier like AI 08:10:20 I'm going to play super mario now, have fun ;) 08:10:31 ever heard of them, java, rust, qt 08:11:16 i understand the pushback, but you'll eventually be convinced or age out and be replaced by someone who is convinced. that's not because of hype, but because of technical superiority 08:11:32 same with freebsd and any other non-rust code 08:11:35 I think in Gosling's days it was the dusk of "creating additional syntax for a new programming language" already 08:12:10 kerneldove: by the time i'm "aged out" there will be 37 more languages which are newer and better than rust 08:12:17 Java did have its own merit at least because Sun played an important part in the development of personal computers 08:12:40 but will they be better enough to supplant the inertia rust has already built up by then? if so then i'll switch too, but i doubt it 08:12:43 i like Rust (the language), i would like to see more of it, but people like you are simplying trying to deny reality when it comes to practical adoption 08:12:51 no u 08:13:24 i'll try to get a job working on large rust codebases and teams then see what i can comment about that 08:13:36 btw, why are we talking about C/C++ when all new code nowadays in written in Ada, a language which is objectively superior to C/C++ on techincal merit? 08:14:38 imo c/c++ was already the peak... anything after that was "re-inventing the wheel" ivy 08:14:44 i never understood how languages are, sometimes it feels like fashion thing 08:15:00 :/ 08:15:13 it had its merit in being the first, and in the code base of various OS kernels 08:15:42 why c didn't die out if it was so bad? 08:15:52 or if was too big to fail? 08:15:59 no alternatives that were better enough 08:16:14 black: i like C++ and also hate it. it has many advantage that Rust also does, but because of its history and the requirement for C compatibility, it can be extremely confusing to work with sometimes 08:16:17 guarantee you rust will essentially kill C if it hasn't already (going off new proj's being started) 08:16:21 and now they are... how and why? 08:16:42 ketas: yeah I try not to understand it as "fashion" 08:16:44 because now you can afford 1g for rust 08:16:48 ? 08:16:59 like, i am fully on board with rewriting as much of FreeBSD as we can in C++ (i've written a bunch of C++ code in base) and if we adopt Rust, i'll argue for writing new code in Rust 08:17:14 since Rust seems like basically, C++ but done without the weird historical bits 08:17:30 unsure how much of that 1g is compiler and how much the "libs" 08:17:31 but i am still concerned about that crates crap 08:19:02 why are they bad? 08:19:17 they are modules for rust 08:19:51 or libs should we say 08:20:42 surely lib per se isn't bad? 08:21:32 Rust has memory safety and a relatively easy to use build and package system 08:22:26 ease of use is sometimes at conflict with greater control over what you do 08:22:53 it's nice to have something that's easy but NOT any easier. 08:23:43 Rust has poor generic programming and fairly spectacularly trait syntax 08:24:31 in what sense is the C and C++ build and package system "easy"? 08:26:02 On FreeBSD hundreds or port maintainers have to fight with umpteen underlying build systems to coerce them into a whole that works sorta OK 08:27:57 kind of fun yeah 08:28:42 ketas: please read scrollabck where i went into detail on my concerns about crates, no reason to repeat all that 08:30:33 hmm unsure where to even start reading 08:31:30 i tried in some parts 08:32:10 there's dev part of things, admin part, and user part 08:33:13 imo best place to start is https://doc.rust-lang.org/book/ 08:33:22 then write some code, see what the hubub is about 08:33:31 ##rust is really helpful too 08:35:19 i hope that wasn't to me 08:35:22 :p 08:35:30 nvm :) 08:42:14 ivy: your concerns towards embedding centralised package management in programming languages are largely valid from OS point of view and shared by many others, but imho ultimately they're mostly just semantics issues 08:42:22 because i write shell, if it's not enough i write perl, if that's not doing it i write that part in c, if it doesn't run any of this, it probably runs js 08:47:47 ivy: I see much bigger challenge with rust itself as a language vs. projects with hundreds of contributors spanning over decades of effort. the language is absolutely not at all like C/C++ in many crucial ways 08:47:59 Koston: my response to "this is just semantics" is that "semantics" means "meaning", and nothing could be more important than the actual meaning of our words 08:57:40 sometimes people have written libs in other languages, then i need to endure this and build a bridge eh 08:58:24 i haven't much thought about all of this at all 08:59:06 you know the whole "cs" thing 09:29:18 vmstat's --libxo output kinda sucks. it doesn't line delimit each display so i can't run it once and parse each output 09:29:32 so instead i gotta loop over running it over and over lol wtf 09:30:09 if i give it -c 5, there should be 5 json wads (lines) outputted but instead it outputs the 5 wads on 1 line 09:30:27 anyone know a fix? 09:31:27 uptime/w xo is broken btw 09:31:38 huh? 09:31:40 unless it's intended 09:32:54 what is "uptime/w"? 09:33:21 w(1) 09:33:33 tells 09:33:35 "uptime-human": " 4:57,", 09:33:50 why the padding? 09:34:00 that's a bug, please file a PR 09:34:28 :) 09:37:09 ivy: by semantics in this case I mean issues around handling of code, not the code itself 09:40:33 for the ports collection anyway 09:42:08 for the base OS, such concerns are more just FUD at this point. even linux dweebs haven't yet done anything meaningful with rust and there's nothing interesting beyond the language itself from an OS point of view that I'm aware of 09:42:25 bug file but 09:42:31 filed 09:42:58 spmzt: because bcmp was deprecated 40 years ago 09:43:15 otherwise, it's fine, but you may perhaps be running into issues with padding 09:43:33 since sockaddr_storage is usually larger than the relevent data it contains 09:43:43 so what should I use instead? in kernel there are a lot of bcmp comparison between sockaddr structs 09:44:01 even when using ss_len? 09:44:32 add a printf() showing the ss_len and make sure it matches what you expect for the af 09:45:11 depending on the context, ss_len could be the size of the stuct itself, which is wrong if you intend to pass it to bcmp/memcpy 09:45:18 or use a breakpoint in the debugger ;) 09:45:44 s/memcpy/memcmp 09:45:53 I see people converting sockaddr_storage to sockaddr_in[6] and using bcmp for comparison. I can't see why they don't check their ss_family to be equal and then directly compare them instead of converting to sockaddr_in[6] 09:46:08 Koston: but basically no one does this because having to attach a serial debug console is way more annoying than just adding printf 09:46:38 ivy: why it's wrong if their family matches? 09:46:47 spmzt: are you asking about a bug you're running into in code you are writing, or are you asking why existing code works in a particular way? 09:48:46 I'm in the middle of writing a network driver (geneve protocol) and I don't know which approach should I use. 09:48:54 ivy: and as we can see from linux, it's entirely possible for that excuse to transform into "I've invested too much into my printf() debug system to bother with a debugger" 09:49:28 Koston: cool story 09:49:46 it's a miserable story 09:49:48 ketas can you confirm that libxo works counterintuitively with vmstat and -c #? vmstat -c 5 --libxo=json. notice it doesn't output per line, but instead outputs all to 1 line, making parsing harder 09:50:24 spmzt: this really depends on the context, like if you just copyin()d a sockaddr_storage from userland, you can't assume ss_len is set to anything sensible 09:50:26 I know it's better to use sockaddr_storage instead of union of sockaddr[_in[6]], however, I'm not sure how to compare them. 09:51:09 kerneldove: yeah misses \n? 09:51:17 that's cursed 09:51:27 sad 09:51:39 at least in that place 09:52:09 because how do you delimit json "packets" 09:52:11 so i guess i'll just run the command over and over in a loop 09:52:28 ivy: seems like sockaddr_storage is behave way more different that I thought. I have both scenario which I get my address from ifconfig in userland (copyin/out 09:52:49 is there any documentation to read about its behaviour? 09:53:15 there's nothing special about sockaddr_storage, it's just a workaround for the shitty sockets API 09:53:26 kerneldove: you need it fast? 09:53:36 it lets userland code allocate a large enough buffer to store any sort of address, except AF_UNIX, because reasons 09:53:39 wym? 09:54:01 actually it outputs neverending json 09:54:05 if you need to accept a socket address in the kernel, you should accept a sockaddr* pointer and a socklen, where the socklen is the length of the address 09:54:07 which is weird 09:54:20 can't even parse it 09:54:39 ya 09:54:41 then you can just use the provided socklen and don't need to care what ss_len says 09:54:43 infinite line 09:54:46 json never ends until the end 09:54:49 :) 09:55:08 ya so not usable with vmstat -w # (infinite output) which is what i wanted 09:55:14 like wtf 09:55:57 spmzt: kernel interfaces should not use sockaddr_storage 09:56:06 see bind(2), accept(2), etc 09:56:25 i love the vmstat 1 --libxo=json 09:56:45 json never ends :} 09:56:47 :) 09:57:48 ivy: but, if_ovpn, if_lagg, and a lot of pf interfaces (pflow, if_pfsync,.. ) use the sockaddr_storage in kernel 09:57:51 but it should be line delimited for each output of -w 09:58:01 i'm unsure if json streaming is a thing 09:58:11 spmzt: there are plenty of kernel interfaces that should be better than they are 09:58:19 my own things i delimites it with \n 09:58:36 actual \n not json "\n" 09:58:48 ya ofc, anyone that doesn't hate users does so 09:59:00 it's json but still line-oriented interface 09:59:20 if nothing else make it a libxo token that can be configured. there's pretty formatting afterall. no-top, all kinds of stuff 09:59:28 well i love how it breaka json in ^c 09:59:29 but no linedelimit-objects token? 09:59:34 breaks 09:59:43 xo is fun thing 09:59:53 So it's better to use sockaddr itself? or use an union of sockaddr[_in[6]] like the one in vxlan_sockaddr? 09:59:59 it's a great idea and has massive potential, just needs some love 10:00:07 hard to maintain in code too 10:00:38 vmstat -c 3 1 --libxo=json makes triple json 10:00:50 all elements are thrice eh 10:00:57 spmzt: ideally, never embed the size of any struct in a kernel interface, because this makes it more difficult to maintain backward compatibility 10:01:03 or, wait 10:01:46 yeah that's a bug 10:02:14 i get where this comes of 10:02:22 Ok, ty, I use the vxlan approach and use an union for sockaddr[_in[6]]. 10:02:25 xo just does all you tell it to do 10:02:58 it works in part and whole modes 10:04:26 spmzt: a union of structs is still embedding the size of a struct in a kernel interface. but if you want to that it's up to you 10:04:32 file that bug too kerneldove ? 10:04:46 who's patching that tho 10:04:53 unless you do 10:05:59 while here, i needed simple seconds out of w(1), i couldn't figure out how to do it, so i just ended up doing uptime-secs.c :/ 10:07:19 my head wanted to explode on attempt to implement -s option that only works if w is uptime 10:07:26 i only use rust heh 10:07:36 if that's even a good idea? 10:07:36 kerneldove: like only? 10:07:50 any foundation in some other languages? 10:08:10 i used it in embedded, in watchdog system check mode as nice comparative value 10:08:25 ya it's the only lang i use now 10:08:27 * ivy never trusts people who "only use" one language 10:08:44 most developers have practical reasons to learn several languages 10:08:45 5iq take but ok 10:08:47 xo has seconds but what to parse it with :) 10:09:07 i used to juggle multiple langs, now i use 1 superior lang for all the stuff i do 10:09:16 my experiences with nodejs was the most painful 10:09:17 focusing on 1 lets me get better with it 10:09:17 where's base json parser 10:09:29 ketas: libprivateucl 10:09:31 json is nice data format tho 10:09:42 hmm yeah i heard 10:10:14 and write lua script? 10:10:20 i mean... 10:10:37