On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:
> > Because other people might (reasonably) wish to omit anonymous memory, > > or private mappings, or file-backed VMAs, or whatever. > > > > So maybe /proc/pid/coredump_omit_anon_shared should become > > /proc/pid/core_dumpfilter, which is a carefully documented bitmask. > > There are people who wish to dump VMAs which are not dumped by default. > Taking this into account, some bits of core_dumpfilter will be set by > default. This means users have to be aware of the default bitmask > when they change the bitmask. Perhaps changing the bitmask requires > 3 steps: > > 1. read the default bitmask > 2. change bits of the mask > 3. write it to the proc entry > > So I think it is better if we provide /proc/pid/core_flags (default: > all bits are 0) instead of core_dumpfilter. With this interface, > users who use only one bit of the bitmask (this will be a common case) > just have to write 2^n to the proc entry. It takes only one step: > > 1. write a value to the proc entry > > If we can implement at the same cost, core_flags will be better > because it is useful for users. What would you think about that? > It sounds unnecessarily complex, and unnecessarily different from our normal expectations of /proc files. And the value we read differs from the value we wrote... I think having a non-zero default will be fine. > > By the way, Robin Holt wrote as follows: > > > Can you make this a little more transparent? Having a magic bitmask does > > not seem like the best way to do stuff. Could you maybe make a core_flags > > directory with a seperate file for each flag. It could still map to a > > single field in the mm, but be broken out for the proc filesystem. > > Do you think Robin's suggestion is acceptable? Marginal, I think. This is not likely to be a field which a lot of people modify a lot of times. Those few people who need to work with this can afford to look the values up in the documentation while writing their script. And it requires a distressingly large amount of code to implement a /proc file. Perhaps in this situation the code can be shared. otoh, why is it a /proc thing at all? unsigned long sys_set_corefile_filter(unsigned long enable_mask); unsigned long sys_clear_corefile_filter(unsigned long enable_mask); would be better? - 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/
