larry@focsys.UUCP (Larry Williamson) (08/06/88)
I've mailed this same query to Microport hoping to get the answer
straight-from-the-horses-mouth (so to speak :-), but I though I'd
post it as well, just in case Microport does not want divulge some
AT&T secret.
I'd like to know how /etc/shmcreate attaches a physical piece of
memory to a shared memory segment. I have a need to do this from
within a user process, and I'd rather not do it by executing shmcreate.
Is the process the same on the 286 and 386 versions of Unix? Or are
there some differences?
On the same subject, although the 386 does not have a 64K segment
size limit to its addressing, the parameters to shmget() seem to
limit the size of a shared memory segment to 64K. The second
parameter specifies the size in bytes of the segment, and this is
an int. Therefore, only 65535 bytes can be specified! Is this, infact
true, or is there something that I've overlooked?
Thanks,
Larry
--
Larry Williamson Focus Automation Systems Inc.
watmath!focsys!larry Waterloo, Ontario
(519) 576-8558
(519) 746-4918plocher@uport.UUCP (John Plocher) (08/06/88)
In article <162@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: > >I've mailed this same query to Microport hoping to get the answer and as soon as I have a chance to look at the source for shmcreate() I'll post the answer (it's just a bit added to the flag argument if memory serves) >Is the process the same on the 286 and 386 versions of Unix? Or are >there some differences? The 386 does not have the modified shared memory calls like the 286 does. You need to create a device driver which allows access. If time permits in a few weeks I'll try to post a better answer than this... >an int. Therefore, only 65535 bytes can be specified! Is this, infact >true, or is there something that I've overlooked? on the 386, ints are 32 bits (a long int in 286-speak) >Thanks, >Larry Williamson Focus Automation Systems Inc. -John Plocher
wtr@moss.ATT.COM (08/06/88)
In article <162@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: > >On the same subject, although the 386 does not have a 64K segment >size limit to its addressing, the parameters to shmget() seem to >limit the size of a shared memory segment to 64K. The second >parameter specifies the size in bytes of the segment, and this is >an int. Therefore, only 65535 bytes can be specified! Is this, infact ^^^ >true, or is there something that I've overlooked? possibly, on the 386 isn't the default int size 32-bits? and not 16? so we get 4-Giga word sizing instead of 64k. i work on a 286 and have played around on 3b1s so this is by no means "from the horses mouth" :-) >Thanks, > Larry hope this helps! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ att ulysses ucbvax allegra ]!moss!wtr ...![ att ucbvax akgua watmath ]!clyde!wtr =====================================================================
det@hawkmoon.MN.ORG (Derek E. Terveer) (08/07/88)
In article <162@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: > [..] The second > parameter specifies the size in bytes of the segment, and this is > an int. Therefore, only 65535 bytes can be specified! Remember, an int is not always 16 bits. I'm not sure, but if the 80386 is one step closer to Intel's slugfest with the CPU curve that is aymptotically approaching a real machine, perhaps an int has been implemented as 32 bits by some Unix vendors...? -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 h(612)688-0667
larry@focsys.UUCP (Larry Williamson) (08/08/88)
In article <403@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: >In article <162@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: >> >>I've mailed this same query to Microport hoping to get the answer > > and as soon as I have a chance to look at the source for > shmcreate() I'll post the answer (it's just a bit added to > the flag argument if memory serves) Thanks. If this is all that is done, then my troubles will be over. Or, at least partly over (see next item). > The 386 does not have the modified shared memory calls like the 286 > does. You need to create a device driver which allows access. > If time permits in a few weeks I'll try to post a better answer than > this... This is disheartening. I would like to have used the same (as much as possible) driver on both systems. Giving the user process direct access to this physical buffer is important only because of the size of the buffer and the amount of access that it will receive. There is about 1 Meg of memory involved and the user process will be thrashing it pretty hard. Having the driver move the entire buffer to the user's virtual memory adds quite a lot of overhead that I'd rather avoid. I'll have to investigate my options here a little better. > >>an int. Therefore, only 65535 bytes can be specified! Is this, infact >>true, or is there something that I've overlooked? > > on the 386, ints are 32 bits (a long int in 286-speak) Yes, of course it is. Thanks John, Larry -- Larry Williamson Focus Automation Systems Inc. watmath!focsys!larry Waterloo, Ontario (519) 576-8558 (519) 746-4918
keith@uport.UUCP (Keith Hankin) (08/09/88)
In article <162@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: | | |Is the process the same on the 286 and 386 versions of Unix? Or are |there some differences? The 386 version does not have a "shmcreate" facility currently. The memory management is handled entirely differently and involves a different solution. We are currently involved in adding ioctl support to our 386 system for a facility like 286's "shmcreate". | |On the same subject, although the 386 does not have a 64K segment |size limit to its addressing, the parameters to shmget() seem to |limit the size of a shared memory segment to 64K. The second |parameter specifies the size in bytes of the segment, and this is |an int. Therefore, only 65535 bytes can be specified! Is this, infact |true, or is there something that I've overlooked? | On the 386, ints are 32-bits. Therefore the limitation is not 65535 bytes, but rather 4 Gigabytes! Now I know that this may limit some of our real heavy power users, but hey, life's rough :^) -- Keith Hankin keith@uport Microport Systems