Marco Colombo wrote:
> It's not a matter of how I call it. The kernel gives you addresses, which
> you are able to use. You read at a given address, you get data. You
> write to an address, and you ask the kernel to allocate memory. That
> request may fail.
--- This would be fine for an "address manager", but the Linux kernel has something called a "memory manager". What kernel are you talking about?> Again, the kernel gives you names for objects, not room to store them. > Sorry, that's what you asked for, and that's what you get. If you want > room for your objects, use another system call. --- What you are describing isn't reliable. What system call do I use to reserve the Virtual Memory of the new process space after a fork? I don't want to pin it in RAM, I just want a guarantee that Virtual Memory has been allocated.
> Memory is accounted. Your problem is that brk() does not give you any > memory. If you want memory, use another system call. --- Just because brk doesn't currently do real memory management doesn't mean it shouldn't -- that's the crux of this issue. malloc is defined to allocate *memory* -- not address space. You are confusing *existing* behavior with *desired* behavior.
> The kernel can't foresee the future. And it's silly to waste megs of > space "just in case". --- But the user can. If your program is coded according to a "design".
> Use another system call. Implement your own memory management. > Or just show a single example of an application, *written following the docs*, > that will fail. --- This is the point -- why use a different system call? Why not just allow the end user to configure whether or not the Linux kernel does address management or memory management? What is your problem with configurability?
--- There was a recent article pointer posted on 'slashdot' -- which talked about how Linux has a long way to go before it has the maturity and stability to run large commercial apps. You attitude is the reason why. Saying "we have a toy that runs this way, deal with it" won't fly if someone requires no-overcommit. You can argue that they are wrong until you are blue in the face, but they won't care -- they will just run NT or Solaris. The idea is to run with a kernel that performs resource management. Linux doesn't, as you have pointed out. It simply manages virtual address page tables -- not real memory. Some people want a system to actually manage *memory* not slots in a page table.
> brk() is the normal API. And it works as expected. --- Not if I come from a system that manages memory.
> I simply think it's wrong. "Proper functionality" *is* followed. > You've got the docs. Read them, and write your programs after them. --- Just because a bug is documented still doesn't mean it is not a bug. Oh yeah, it's not a bug...it's a *feature*. A proper feature operates under the principle of "least surprise". Most users will expect malloc to allocate a real, usable pointer. If the pointer is not usable, they will consider it broken. The fact that some arcane design describes how this really isn't a bug is irrelevant. The user did not *ask* for such behavior. Most likely they want the behavior of getting back a *usable* pointer. Please -- don't try to argue that users really don't care if malloc returns a bogus pointer. It won't fly.
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:10 EST