**** BEGIN LOGGING AT Sat Feb 05 02:59:56 2022 Feb 05 03:06:28 /29/29 Feb 05 03:06:33 * vagrantc waves Feb 05 03:06:54 you have 29 windows open? Feb 05 03:07:44 at least! Feb 05 03:48:53 Hey! I am trying to do things! Feb 05 03:49:56 Okay so...here it goes. Feb 05 03:50:34 As some of you know, I am trying to get involved more by making this wpan-next driver available in some context. Feb 05 03:51:40 So, I need to learn zigbee standards, MAC (soft and hard), and then the WiFi standard. Feb 05 03:53:18 I have a 5.15.x kernel installed right now and I am not seeing a lot of what is described in mailings and/or chat around "town." Feb 05 03:59:23 10:00! No. Dang it. Feb 05 04:00:27 Can we make an exception this time b/c of my trying to understand how to assist w/ usb and zigbee standards? Feb 05 04:01:28 is anyone else making this a reality right now? Feb 05 04:14:00 Could adding misc. constants in specific files be an effort? Feb 05 09:33:20 Is it too early? Feb 05 10:10:28 GPIO and sysfs or configfs? Feb 05 10:25:47 Dudes and Dudets, I just learned a simple way to read the UIO and other kernel docs. outside of man. Feb 05 10:26:09 make pdfdocs && make htmldocs Feb 05 10:26:15 Yes! Feb 05 10:26:18 I feel free! Feb 05 10:33:58 Hey... Feb 05 10:34:27 when you guys say you are mainlining the .dts files, does it have to do w/ older .dts files not needing updating or changing? Feb 05 10:35:18 I looked at https://github.com/devicetree-org/devicetree-source/tree/master/src/arm, and it shows outdated things from three years ago or are they outdated? Feb 05 10:53:43 who said what about mainlining which dts files? Feb 05 10:54:48 Oh. Feb 05 10:55:20 I thought rcn-ee said the beagleboard.org people were trying to mainline the .dts files in the kernel. Feb 05 10:55:42 For the am335x and am5729. Feb 05 10:56:18 not sure what you mean, they already have dts files in the kernel Feb 05 10:56:27 Hey @zmatt, since i have you here, what is the "die" calls in the source in that gpio lib you produced? Feb 05 10:56:28 Oh. Feb 05 10:57:06 https://github.com/mvduin/sysfs-gpio/blob/master/sysfs-gpio.c#L17 Feb 05 10:57:14 Let me check. Feb 05 10:57:30 just the simplest error handling function possible (print error message and exit) Feb 05 10:57:32 Yep. Feb 05 10:57:34 That one. Feb 05 10:57:41 Oh. Feb 05 10:57:45 obviously can be replaced by any other form of error handling if you prefer Feb 05 10:57:51 Okay. Feb 05 10:58:08 Can it be called something else outside of die? Feb 05 10:58:34 For instance, mos? Feb 05 10:58:52 if you also rename all uses of it you can call it whatever you fancy... why? Feb 05 10:59:11 Oh. Okay. I was asking b/c die seems a bit morbid. Feb 05 10:59:49 I mean, it kills the program Feb 05 10:59:58 I was just reviewing the source. Oh! Now, I understand. Feb 05 11:00:15 I thought it was for the readers. Feb 05 11:00:18 Ha. Feb 05 11:00:42 Well, now I know. Feb 05 11:01:05 Is it like EOF and NULL? Feb 05 11:01:22 none of these things are even remotely related? Feb 05 11:01:29 Okay. You are right. Feb 05 11:01:31 Sorry. Feb 05 11:01:54 I keep reading that NULL in Linux is a black hole. It just gets erased for good. Feb 05 11:02:36 And EOF, quits the program too, i.e. like the die() usage. Feb 05 11:02:51 Just wondering. That is all. Feb 05 11:03:00 it's just a simple form of handling errors that really shouldn't happen, in a way that's more useful than returning some error code that the caller is probably going to ignore because they don't know what to do with it either... as the old klingon proverb says, it's better to die() than to return() in failure ;-) Feb 05 11:03:19 Aw! Feb 05 11:03:45 you're confusing NULL (the pointer constant) with /dev/null (the device that discards anything written to it) Feb 05 11:03:54 Aw. Yes. Feb 05 11:03:58 You are right. Feb 05 11:04:04 and EOF is just an abbreviation for "end of file", it does not imply any sort of behaviour Feb 05 11:04:18 Oh. Okay. Feb 05 11:04:30 and none of these things still anything to do with each other Feb 05 11:04:34 *still have Feb 05 11:04:38 Okay. Feb 05 11:05:07 Hey @zmatt: none of those things have anything to do w/ one another. You are right. Feb 05 11:05:17 But, they all are endings. Feb 05 11:05:29 no they're not Feb 05 11:05:32 Oh. Feb 05 11:06:26 the /dev/null is the end of the file on the output unless specificity is called in the program. Feb 05 11:06:33 ????? Feb 05 11:06:49 For instance, if I was making atoi or atof work. Feb 05 11:07:02 that sentence was really just a word-salad Feb 05 11:07:18 in .c files...here. Sheesh. Feb 05 11:07:29 So anyway. Feb 05 11:07:35 Back to what I was saying. Feb 05 11:08:51 Forget it. Feb 05 11:09:09 atoi is ascii to int. Feb 05 11:09:27 atof is ascii to float as in a double. Feb 05 11:10:32 I have been goofin' around w/ stderr, stdin, stdout on the console. Feb 05 11:14:15 I was learnin' about dprintf too! Feb 05 11:14:56 Are using fd's a thing of the past? Feb 05 11:14:56 that's a function you're very unlkely to have any use for Feb 05 11:15:03 no Feb 05 11:15:09 Okay. Good. Feb 05 11:15:11 oh. Feb 05 11:15:28 Why would I not use the dprintf function? Feb 05 11:15:36 but normally you don't use the underlying file descriptors for stdin/stdout/stderr directly except in very specific circumstances Feb 05 11:15:58 Aw. Okay. What are two "specific circumstances?" Feb 05 11:16:00 because all other code uses printf()/fprintf(), and mixing that with dprintf will result in problems Feb 05 11:16:08 Oh. Okay. Feb 05 11:16:27 Hmm. I guess I better be careful. Feb 05 11:17:12 basically, if there's an open FILE* for a file descriptor, you almost certainly want to use that instead of using the file descriptor directly (unless you know exactly what you're doing) Feb 05 11:18:10 hence, use stdin/stdout/stderr instead of using the underlying file descriptors (0, 1, and 2 respectively) directly Feb 05 11:19:43 Oh. Yep. Using https://pastebin.com/syrSkb4C has been teaching me some off topic instances. Feb 05 11:19:50 You are right. Feb 05 11:20:40 I was using specific commands to pipe and throw some info. from stdout to files. Feb 05 11:23:17 and then into /dev/null and return it from nothingness. Feb 05 11:28:04 Hey! Check this one out: https://pastebin.com/bVwF5r7g . It shows the variable he made for '-c' to handle not ending the output. Feb 05 11:28:08 I thought it was neat. Feb 05 11:28:34 i.e. not ending the output on the commandline from the script runnin'. Feb 05 11:31:50 The reason it is neat is b/c it hits errors but still runs. Feb 06 00:30:52 all day? Feb 06 00:30:54 Nothing? Feb 06 00:31:01 Sheesh. Feb 06 00:31:08 Man, am I glad I am back. Feb 06 00:31:09 ha. Feb 06 00:38:49 Anyway...sorry for the interjection. Just be as you were. **** ENDING LOGGING AT Sun Feb 06 02:59:57 2022