Date: Tue, 10 Dec 1996 15:07:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@freebsd.org Cc: terry@lambert.org, scrappy@hub.org, erich@lodgenet.com, hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612102207.PAA05053@phaeton.artisoft.com> In-Reply-To: <199612102153.QAA00743@dyson.iquest.net> from "John Dyson" at Dec 10, 96 04:53:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm not clear on how I get several processes using the same region > > in the MAP_ANON case... is it even possible? The man page says a > > non -1 fd "is used for naming"... how does that work? Is it an index, > > or is it just an ID? > > I am not clear on what it is supposed to do either. What would the > protection attributes of such an entity be? At least SYSVSHM defines > them. Maybe: P1: fd = open key file mmap( ... fd ... MAP_ANON ... yada yada ...) P2: fd = open key file mmap( ... fd ... MAP_ANON ... yada yada ...) So the key file would be used to create a unique identifier. In this case, I would expect the protection attributes to match the key file. NOTE: Since the MAP_ANON is used, the key file is *NOT* the backing store for the region; however, since the is generated from the key file (dev_t and inode_t?) and uniquified that way, I don't think you could have both an anonymous and a non-anonymaous mapping for the same file... ie: you can't map a key file if it is being used as a key for an anon region, since the mapping will return the first mapping... the MAP_ANON... and the second mapping would fail. This may be scary at this point, since you *could* have both in different processes, *IF* the VM and cache were not unified, but not otherwise. OR you could take MAP_ANON as part of the key generation and end up with a structure that pointed to the anon vnode that was not the fd vnode, but was in the list of key indices. This would imply that you would need to indirect the key references (they are currently direct, it looks like). My hunch is that using and fd as a key would make that file the backing store; at the very least, you would be in danger, since you would not get protection if you used the fd index instead of the FS object (it wouldn't be very portable between processes otherwise, either). In other words, the cache unification would now cause some wierd behaviour about whose buffer is written on a page write fault from user space. I guess we could quit postulating and write test code... NAW! 8-) 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612102207.PAA05053>