In article <[email protected]>,
matthew green <[email protected]> wrote:
>"Maxime Villard" writes:
>> Module Name: src
>> Committed By: maxv
>> Date: Mon Aug 20 11:35:28 UTC 2018
>>
>> Modified Files:
>> src/sys/kern: files.kern subr_kmem.c
>>
>> Log Message:
>> Retire KMEM_REDZONE and KMEM_POISON.
>>
>> KMEM_REDZONE is not very efficient and cannot detect read overflows. KASAN
>> can, and will be used instead.
>
>asan requires a 64 bit system, so, i'm not really OK with
>removing this code and requiring kasan.
>
>please discuss removals like this on tech-kern first. i'd
>rather this change was reverted.
Exactly: We are much more accepting on adding new features as opposed
to removing existing ones without prior discussion. Nobody is holding
a gun forcing us to remove features quickly, so a simple process like:
- announce intention to tech-kern explaining why you want to remove
something, what replaces it, and giving people a chance to comment.
- wait a few days, and remove if there was no objection.
Yes, cleanliness is a great goal, but it could be achieved without stepping
on toes.
Best,
christos
