Hi! > I have discussed with my colleagues why you say "ugly" against my > procfs interface, then I noticed I may have misunderstood what you said. > Is the reason for saying "ugly" two interfaces, i.e. preexisting ulimit > (get/setrlimit) and my proc entry, exist to control core file size?
Yes. > > Plus, what you are doing can be done in userspace using google > > coredumper. > > I think that the needs differ between userland core dumper user and > in-kernel core dumper user. Pros and cons also differ. > > Some of people (such as system admins, distro vendors, etc) need > highly reliable core dumper because they don't want to experience > same failures again and they don't hope that another failure is > caused by core dumping. Userland core dumper is useful because > it is relatively easy to be customized, but its reliability highly > depends on the application programs. Fix userland core dumper to be reliable, then. > If the stack for signal handlers is not set up carefully, if the > data used by userland core dumper has been destroyed, if > coredump_omit_anon_shared flag has been overwritten by bad data, > or if the address of functions have been destroyed, the userland > core dumper may fail to dump. So in-kernel solutoin is required > by enterprise users. It should be possible to dump from separate process. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
