--- Roland McGrath <[EMAIL PROTECTED]> wrote: > > For now at least for RLIMIT_CORE I think we should just accept > any hard > > maximum. However, to implement core dumps would that be a core > server > > that actually implemented limits on core sizes and such? > > Yes. If the limit is zero, then you don't call the crash server at > all (we > don't call it the "core server" because then we'd want to use names > like > /servers/core and /hurd/core, and we're afraid of well-meaning cron > jobs). > For a limit of another finite size, it's just like the RLIMIT_FSIZE > limits > that we also don't implement--it would be arranged somehow with the > filesystem server. > Well, now I know something else the crash server does ;)
Ok, but what you said, it seems you have to tell the crash server it should allow core dumps as opposed to a core dump, which is not implemented, being the normal case. It would be nice for this to be implemented but I know I'm no where near touching the crash server yet. Off the current topic I've been looking at the symlink server recently and there are two mach_port_t 's that I noticed. One is realnode and the other is realnodenoauth. What is the difference between these port_t's. ===== James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org __________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
