Date: Thu, 11 Feb 1999 21:36:13 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: tlambert@primenet.com, dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902112136.OAA12779@usr06.primenet.com> In-Reply-To: <199902110625.WAA88612@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 10:25:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The issue of file-backed storage verses anon mmap is certainly real, > but it's divergent enough from the original discussion that it should > have been brought up as a separate item rather then as a response, > That's all. Well, I guess I can buy that; I was basically in brain-storm mode about the Subject: line (although the subject line is hardly specific to Linux/FreeBSD code portability). > This brings up a good point, though... I think it might make sense > to be able to specify a MAP_ flag to mmap to indicate that the file's > dirty data backing the map ( for non-anonymous maps ) does not have to > be synced by the syncer. That would make mmap() a much more useful > tool for sharing working sets. The file data would be synced on the > last close of the vnode and if the program really doesn't want it to be > synced at all, the program could madvise() it free ( and we could fix > madvise() to actually support throw-away on a vnode ). So the vnode is just for a rendesvous? This has plusses and minuses; the plus is you can have unrelated processes accessing what is, in effect, anonymous memory of the kind that SYSV SHM has, without the performance penalty you pay for the BSD interface. The minus is that you could really get screwed on things like /dev/zero. > Another possibility would be adding a memory reference passing capability > to unix-domain socket messaging. We can already pass descriptors and > access rights, why not memory too? ( ala mach ). I think this should be done in procfs; that's where my money is, anyway. I would have liked to see the vfork behaviour as a set of flags to a procfs ioctl() on the process, actually, instead of a new system call. The behaviour could be inherited (or not; make it another bit, if necessary). The descriptor passing is a kludge. You could almost use procfs for that, as well. The difference is that the exclusive use bit, if set, would foil a procfs-based "open" attempt, but not a pass. Actually, the dup/dup2/F_DUPFD code is a bit broken in this regard; it appears to honor the exclusive use bit when it shouldn't, by virtue of the underlying implementation (note: I haven't tested this in FreeBSD, only looked at the kernel code). Yet another tangent, but clearly labelled as such: There is a related portability bug, in as far as SVR4 is concerned, having to do with the partial open hack, which show up when you are trying to use the same port for HDB UUCP's uugetty on a port, and use it for dialout at the same time. The exclusive use bit is not reset if an O_EXCL open pending DCD is in progress, and another process issues an O_NDELAY open. The second open completes, but bit is not reset, meaning that if the second open is, say, terminal emulation software that uses external file transfer modules, the external transfer modules can't open the tty. I still think the partial open hack is a very elegant soloution, even if SVR4 has 12 lines of code 24 lines to early to do the right thing with the exclusive use bit. It beats the hell out of designating tty ports as modem-control or non-modem-control and/or having a control port to dick with flags. FreeBSD is way down the wrong road in supporting ABI compliance for modem devices. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902112136.OAA12779>