**** BEGIN LOGGING AT Fri Apr 01 02:59:58 2016 Apr 01 18:45:17 alexhiam: please let me know when you're free. I had some questions Apr 01 18:46:14 shame here Apr 01 18:46:25 same here Apr 01 18:58:30 don't ask to ask!! Apr 01 18:59:09 if you just ask your questions then I'll see them when I am here - and someone else might have answers too Apr 01 19:10:27 okay I was thinking of adding ioctl controls to the driver I had written so that we can configure the buffer size to be arbitrary (right now the driver just access a byte of memory) Apr 01 19:11:16 but I read somewhere that sysfs is a better approach for small stuff like this and now I am confused....which one do you suggest and why? :/ Apr 01 19:12:14 oh and I added a simple userspace program to show the usage of driver I had written.....I also cleaned up some of the code and now it's compatible with the newer kernels (I tested it on 4.2) Apr 01 19:13:17 well, technically device files are meant to provide interfaces to device drivers, which control devices connected to the computer Apr 01 19:14:12 so if there's no device you shouldn't really be using a device file Apr 01 19:14:20 whereas sysfs is more general purpose Apr 01 19:15:07 but this driver accesses the memory region like it's a device doesn't it? Apr 01 19:17:03 so from the system's perspective it's all the same I suppose right Apr 01 19:25:51 udayansinha: it doesn't represent a physical device though Apr 01 19:26:15 mmm okay......so sysfs... Apr 01 19:26:59 but ioctls can't be used? Or I can use them but it's overkill? Apr 01 19:28:12 On the chardev vs sysfs question key questions are speed /overhead vs ease of use. Apr 01 19:29:09 There are more restrictions on sysfs in that it is one file for one value and all should be in nice sensible units etc. Apr 01 19:30:02 right...like the ones for gpio eh?....gpio12, gpio13, etc....but it's easier to use too (simple file writes to change config of the device) Apr 01 19:30:16 Idea is you should need no knowledge beyond what is in the sysfs naming should be needed to use it. Apr 01 19:30:55 if only... Apr 01 19:31:23 Chardev s are more freeform in both read and write and ioctls. Apr 01 19:31:42 Ioctls are meant for out of band data... Apr 01 19:32:01 And these days are often hard to justify Apr 01 19:32:17 how so? Apr 01 19:32:21 you mean vs sysfs? Apr 01 19:32:30 Yup. Apr 01 19:33:31 Not that hard, but harder! Apr 01 19:33:38 but I don't need too much of flexibilty (not for this example code atleast)...just a way to be able to change the buffer size... Apr 01 19:33:42 and not self-documenting Apr 01 19:33:57 Exactly! Apr 01 19:34:19 udayansinha: I don't mean to discourage you from trying out ioctl, I was just pointing out the convention side of it Apr 01 19:34:36 getting experience with both is good Apr 01 19:35:01 so ioctls=lesser overhead, more flexibilty, harder to use.....sysfs=more overhead (not sure how, will have to dig in), lesser flexibility, but easy to use Apr 01 19:35:31 While you are it debugfs and configfs if you are feeling adventurous! Apr 01 19:36:01 Sysfs is strings, that is about it on overhead Apr 01 19:36:35 Binary sysfs exists but only had very rare valid uses. Apr 01 19:36:53 weird Apr 01 19:37:12 Hmm mostly abused for dirty hacks. Apr 01 19:37:21 I'm sure Apr 01 19:38:44 Another use for ioctls is to get anonymous file handles. Very handy if you want lots of fast pipes to a driver. Apr 01 19:38:49 and ioctls is just hex codes (I read that it uses codes to change config)? Apr 01 19:39:38 Yeah, they just turn up in a callback registered for the device iirc Apr 01 19:40:01 Kind of a labeled read or write. Apr 01 19:40:44 Oh okay... Apr 01 19:41:06 What gets messy is variable sized ioctls where size stuff returned to userspace is unpredictable in advance... Apr 01 19:41:26 Keep away from those! Apr 01 19:42:21 Will start with sysfs... Apr 01 19:43:55 I will consider ioctls too but I gotta see exactly how many variables might need to be configured while the driver is loaded in the kernel for the SPI/UART/I2C stuff....SPI will need most of the config (courtesy of it's flexibility) Apr 01 19:44:05 Good plan. Good to have an idea of various options though. There are lots more :) Apr 01 19:44:18 but sysfs as the first step Apr 01 19:44:52 hold on now, you wouldn't be implementing any of that for the PRU serial devices Apr 01 19:45:13 All the spi config will be handled through the spi core. You shouldn't need to do any of that. Apr 01 19:45:31 Same for i2c whilst we are here. Apr 01 19:45:49 but you said they're discarding some stuff :/ Apr 01 19:46:25 Only possible userspace interface you might want to have in those drivers is debugfs. Apr 01 19:47:19 Not clear what is happening at rproc end, upwards in kernel is all very tightly defined. Apr 01 19:48:00 Back later. Apr 01 19:48:42 okay I thought them might do away some stuff connected to the userspace so I would have to do that too if that change is permanent....no issues :) Apr 01 19:48:46 thanks :) **** ENDING LOGGING AT Sat Apr 02 02:59:58 2016