| sam_ | yeah | 00:11 |
|---|---|---|
| sam_ | [09:13:24] <minime> I have a very bad feeling about how Gentoo is handling this... I'm surprised Gentoo is working so hard to remove eudev noe that the development issue has been solved. | 00:11 |
| sam_ | well, someone had to maintain it | 00:11 |
| sam_ | (you're welcome to help!) | 00:12 |
| sam_ | on our side | 00:12 |
| sam_ | i'm sorry you have a bad feeling but in any case i've added 3.2.11 which is what you're now using | 00:12 |
| sam_ | i keyworded it last night and i'll be unmasking eudev shortly given it seems to work well now | 00:12 |
| sam_ | (3.2.11 is already in the Gentoo repo) | 00:12 |
| sam_ | basically: we started planning to drop it, then the new project (this) started, but someone still needed to pick it up on the Gentoo side | 00:13 |
| sam_ | nothing nefarious | 00:13 |
| genr8eofl | merry christmas eudev | 00:28 |
| sam_ | yes :) | 00:30 |
| sam_ | kurly is to blame here for making sure I got it done | 00:30 |
| bb|hcb | sam_: thanks for the explanation - at least 3 (maybe) different people asked about that recently | 00:31 |
| sam_ | no problem bb|hcb, and sorry I'd not been great with communication recently. the last 2 months or so have been pretty rough after my dog got hit by a car and he's been in/out of the vets a lot. he's luckily doing well now but it's been draining and I've only really been able to focus on bare essentials | 00:32 |
| sam_ | (it's been draining on everybody in the house, etc) | 00:32 |
| bb|hcb | oh, ouch... good to know dogo is fine :) | 00:33 |
| bb|hcb | sam_, let's clarify something - now gentoo offers choice - udev or eudev, right? | 00:35 |
| sam_ | yes! | 00:35 |
| sam_ | as of a few minutes ago | 00:35 |
| Arsen | <3 thanks for doing my job sam_ | 00:36 |
| sam_ | you did the real work wrt hwids and stuff, I just updated the ebuilds and tested a bit | 00:36 |
| sam_ | I'm sure I can rope you in if anything breaks ;) | 00:36 |
| Ariadne | excellent | 00:37 |
| Ariadne | at some point, we will rebase on systemd-udev, maybe, or maybe not | 00:37 |
| kurly | ya i'll be around, more like "around-ish" in the next few days but around | 00:37 |
| bb|hcb | very good - choice is base for freedom :) | 00:37 |
| Ariadne | i have mixed feelings | 00:37 |
| Ariadne | the systemd codebase is not one i find "good" | 00:37 |
| sam_ | one of the things that bothers me is e.g. this hesitancy to properly fix VLA usage | 00:38 |
| sam_ | even though people have made PRs for it a few times | 00:38 |
| bb|hcb | VLA? | 00:38 |
| Ariadne | i'm open to seeing what Arsen has in mind in that regard, but | 00:38 |
| Ariadne | i am also kind of in the mindset of "if it's not broken, don't fix it" | 00:38 |
| Ariadne | and there are changes systemd has made to udev that i disagree with, but not strongly enough to say "this is not something we should do" | 00:39 |
| sam_ | e.g. https://github.com/systemd/systemd/pull/19973 but variable length arrays (VLAs) are a common C footgun and they were the source of the most recent CVEs for systemd. it'd make more sense to just not bother using alloca rather than trying to make it safe which is harder to do. | 00:39 |
| sam_ | yeha | 00:39 |
| sam_ | yeah | 00:39 |
| Ariadne | VLAs are also bad for portability | 00:39 |
| Ariadne | i mean, admittedly, eudev only targets Linux (and i guess Mangaarm, but that is somebody's toy) | 00:40 |
| Ariadne | so portability to say, MSVC is kind of not interesting | 00:40 |
| Ariadne | but they are still a GNU-ism | 00:40 |
| bb|hcb | sam_: ok, this one... i agree that unless properly guarded somewhere that is not a good idea | 00:42 |
| Arsen | the biggest issue with VLAs is that they can't fail nonfatally | 00:42 |
| bb|hcb | anyways that makes verification very hard and bugs may (will) creep in | 00:43 |
| Ariadne | the biggest issue with VLAs is that they make verifying stack space requirements difficult | 00:43 |
| Arsen | well, yeah | 00:43 |
| Arsen | that manifests as fatal failures | 00:43 |
| Ariadne | anyway lets rewrite udev in rust | 00:44 |
| Ariadne | fuck yeah | 00:44 |
| Arsen | lol | 00:44 |
| Arsen | simultaneously drop 3 or 4 arches from the support list | 00:44 |
| Arsen | say they were never supported | 00:44 |
| Ariadne | what is anything other than aarch64 or x86 | 00:45 |
| bb|hcb | about compilers, even tcc supports that | 00:45 |
| bb|hcb | seriously, i am not sure which path would be more proper - deviating and rewriting the ugly code parts (parser, greedy_*alloc, etc) or keeping closer to upstream | 00:48 |
| bb|hcb | my gut feeling says the former, but i may be wrong :P | 00:49 |
| Arsen | latter + upstreaming seems more maintainable to me | 00:50 |
| Ariadne | former | 00:51 |
| Ariadne | its ultimately bb|hcb's call, he is doing much of the maintenance :P | 00:51 |
| Ariadne | but i would prefer to go with his plan of just rewriting the bad code | 00:51 |
| Ariadne | and maybe offering it to systemd, but who cares honestly | 00:52 |
| bb|hcb | do you really think upstreaming possible? i have doubts; and in case the effort for upstreaming is too much, it is pointless | 00:52 |
| Arsen | I'd not be that pessimistic about it | 00:52 |
| Arsen | what code do you mean specifically? | 00:53 |
| bb|hcb | search for realloc in the code; then check how in case of NULL there is leak | 00:53 |
| Arsen | the code that i'd like to keep as close to upstream as possible is only about 16k lines | 00:53 |
| Arsen | yeah, much of this is removed or inside the scope of libsystemd | 00:54 |
| bb|hcb | i tried to merge cdrom_id.c - the version is eudev uses fixed memory to fit the known data in it; upstream that is rewritten to greedy_alloced dynamic array; it is still pending on my list to verify that the old code is not missing some feature | 00:55 |
| bb|hcb | ...version in eudev... | 00:55 |
| bb|hcb | ...in upstream... | 00:55 |
| bb|hcb | that adds effort to sync, but the old code is much better; that one makes me doubtful that upstreaming such a change is a no go | 00:57 |
| bb|hcb | or we may talk about parsers and grammars - current code does some quick hack that conforms to no specification, has rough edges (most probably buggy in 1000 ways on edge cases) and can not be verified in any way | 00:59 |
| bb|hcb | fine folks invented yacc in the 60s | 00:59 |
| Arsen | surely, one would accept objectively better code | 01:10 |
| bb|hcb | now as i read the comments in pull/19973 - the plan is to replace stack allocation with a check + assert, and as far as i see to also introduce a single allocation maximum safe value. then blissfully believe that multiple allocations are not going to cause a crash | 01:15 |
| sam_ | yep.. | 01:15 |
| sam_ | i would prefer they just banned it | 01:15 |
| sam_ | it's a microoptimisation | 01:15 |
| bb|hcb | and assert in an essential service, yuck... | 01:15 |
| bb|hcb | as far as i am aware no one suffered from udev low performace. but string operations are done in a very suboptimal way... iow penny-wise and pound-foolish | 01:19 |
| bb|hcb | let me </rant>... ;) | 01:19 |
| sam_ | :D | 01:20 |
| bb|hcb | /* If for some reason more than 4M are allocated on the stack, let's abort immediately. It's better than | 01:27 |
| bb|hcb | * proceeding and smashing the stack limits. Note that by default RLIMIT_STACK is 8M on Linux. */ | 01:27 |
| bb|hcb | #define ALLOCA_MAX (4U*1024U*1024U) | 01:27 |
| bb|hcb | so 3 by 3M are good to go... | 01:27 |
| bb|hcb | btw. if someone is willing to propose stack allocation removal patch, that would be more than welcome | 01:28 |
| bb|hcb | the easiest way would be to #define alloca our_alloc, that keeps track of things and borrows some gc from java in the main loop </joke> | 01:30 |
| semz | greedy_realloc's overflow checks are completely wrong, aren't they? | 01:41 |
| bb|hcb | not completely - that is the works for me (tm) area... | 01:53 |
| sam_ | bb|hcb: fwiw, built fine (and tests, their small size aside) on amd64/x86/ppc/ppc64/sparc/arm/arm64 for us | 04:02 |
| sam_ | not tried some of the other arches | 04:02 |
| Arsen | no define hackeryt | 10:33 |
| Arsen | hackery* | 10:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!