Path: utzoo!attcan!uunet!aplcen!samsung!usc!rutgers!rochester!pt.cs.cmu.edu!g.gp.cs.cmu.edu!tgl From: tgl@g.gp.cs.cmu.edu (Tom Lane) Newsgroups: comp.sys.hp Subject: Further question about iomap Message-ID: <10647@pt.cs.cmu.edu> Date: 3 Oct 90 15:40:25 GMT References: <789@cspi.UUCP> <7370223@hpfcso.HP.COM> Organization: Carnegie-Mellon University, CS/RI Lines: 28 In article <7370223@hpfcso.HP.COM>, stroyan@hpfcso.HP.COM (Mike Stroyan) writes: > If you specify an > addr of zero, then the system picks an address just above the top of the > highest malloc'd area. This is something I discovered the hard way, and I think it sucks. Once you have iomapped something with the default address, you cannot malloc more than a couple dozen Kbytes of additional memory. This is not a reasonable default. Currently I tell iomap to map my device at sbrk() plus 1 Mbyte or so (rounded off to a 64Kb boundary). This gives me room to malloc 1 Mb, which is sufficient for the particular program I have at hand, but it's far from a general-purpose solution. A much better solution would be to iomap the device at someplace like 0x40000000. I'm afraid that trying to do that would force the kernel to give me a huge page table, if indeed it would work at all; so I have not tried it. Can anybody at HP provide a workable, efficient solution for mapping I/O devices without constraining subsequent use of malloc? -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu