> On 2017-04-05 17:36, Theo de Raadt wrote: > >> On 2017-04-05 17:24, Theo de Raadt wrote: > >> >> "ls -l /dev/rsd0c; ls -l /dev/sd0c" shows that sd0c is a block device > >> >> and rsd0c is a character device, and mmap's man page says that > >> >> "character special files" are OK. > >> > > >> > The manual pages will never list all restrictions. > >> > >> /dev/sd* delivers ~120MB/sec globally, whereas /dev/rsd* delivers > >> ~575MB/sec, sustainedly in my tests, likely due to lots of the IO > >> subsystem being bypassed on /dev/rsd* access, as discussed in the > >> misc@ > >> ML thread with David Gwyne. > >> > >> So presently higher-speed access is restricted to read()/write() - > >> noted. > > > > So what? > > Yeah you're right - while some really nice code out there such as LMDB > depends on mmap, and mmap may be a bliss in how it abstracts away the > externality of a file from the programmer and from a program, then, of > course mmap is not a panacea or anything and I guess there are some > level of relevant security arguments against it. > > I totally understand that rsd* is special and there's no point with > mmap:ing it, so normal access should be done on sd* . So then this > question transforms into the fairly recent what-about-higher-sd* speeds > through multithreading and perhaps multiqueing misc@ thread with David > Gwyne on https://marc.info/?t=148660831800001&r=1&w=2 . > > He talked about that the file IO subsystem is singlethreaded and he had > made several but not all parts threadsafe, and so that it's a deep & > implementation question, and he didn't have the time to go into any > additional detail yet.
How strange. What David talked about has nothing to do with your failure to mmap a disk device.
