**** BEGIN LOGGING AT Sat Jun 02 03:00:09 2018 Jun 02 04:53:59 good morning team pyPRUSS Jun 02 04:54:40 good morning Wormo ! Jun 02 04:56:17 saturday morning already, right? Jun 02 04:57:27 yep, where does the time go... Jun 02 04:58:03 hopefully a good sign you're having fun Jun 02 04:58:35 yeah definitely :) Jun 02 07:25:52 zeekhuge / abhishek_[m] : here? Jun 02 07:33:49 Wormo: Is this approach fine? I have used unix sockets for IPC : https://github.com/MuneebMohammed/PRUSS-Bindings/blob/master/prussd/prudaemon.py Jun 02 07:38:24 oh good you pushed since I last looked Jun 02 07:51:18 yes unix socket is ok Jun 02 07:52:01 on the other hand you don't want to be passing data coming over the client socket to commands being executed Jun 02 07:53:51 the privileged part of code should be absolutely paranoid and not expect those crazy users to do anything sensible Jun 02 07:55:21 but there are some things such as filenames which have to be passed... Jun 02 07:56:13 you don't let them pass random filenames Jun 02 07:56:33 firmwares should live in /lib/firmware, yes? Jun 02 07:56:40 yes Jun 02 07:57:07 that's one thing you can do, is not let clients pass in paths to files that they made up and stuck in /tmp Jun 02 07:57:46 yeah, that will work Jun 02 07:57:58 think about how a naughty program could abuse your server if it were running Jun 02 07:59:22 being able to modprobe modules that it loaded into /tmp would be pretty convenient for naughty programs trying to root somebody's system... Jun 02 08:01:12 yeah, we anyway need to probe only specific modules... so I'll change that Jun 02 08:02:46 yes more like how you treat first word of command, there is fixed set of commands that it knows how to do and everything else is rejected Jun 02 08:03:52 in general "input sanitizing" is something all programmers should learn to do well, since it's key principle for both robustness and security Jun 02 08:05:12 Makes sense. Also, is there a neater way for non-blocking read apart from the select() one Jun 02 08:07:59 does it even need to be non-blocking? going to be doing anything else while waiting for a message to arrive? Jun 02 08:08:31 might just have a timeout instead, since you don't really want it wating forever Jun 02 08:09:18 non-blocking is important if blocking starves something else that ought to be running Jun 02 08:11:11 think about whether that is really the case here, or if there's only a sequence of things to be done serially Jun 02 08:11:52 We have two PRUs which can run simultaneously, so i was thinking along those lines Jun 02 08:12:25 so you're thinking of two clients commanding them independently? Jun 02 08:12:39 We will anyways need to thread out the server, right? I mean for simultaneous event waits and all? Jun 02 08:12:47 and not having to interleave their requests Jun 02 08:13:28 well that is a design decision, threading is not always needed Jun 02 08:14:13 there have been high-volume servers that do the non-blocking event loop approach Jun 02 08:15:44 Oh... so what would you suggest? Jun 02 08:18:32 probably should just get a simple version going that works well as far as it goes, and work on the eventwait in parallel later Jun 02 08:20:04 yeah, makes sense Jun 02 08:21:04 the simple version will be good enough to do some full examples Jun 02 08:22:42 and then whenever you enhance it you can add new examples with commands going to both PRU in parallel Jun 02 08:27:21 btw good job on pushing your latest work regularly Jun 02 08:28:57 Thanks. I'll probably get over with the basic version today, and can start with DMA next week, maybe? Jun 02 08:29:14 sounds plausible **** ENDING LOGGING AT Sun Jun 03 03:00:01 2018