>>>>> "Song" == Song Liu <songliubraving@xxxxxx> writes: Song> Hi Jason, >> On Apr 27, 2020, at 2:10 PM, Jason Baron <jbaron@xxxxxxxxxx> wrote: >> >> >> >> On 4/25/20 12:31 AM, Coly Li wrote: >>> On 2020/3/26 23:28, Jason Baron wrote: >>>> Let's add some CONFIG_* options to directly configure the raid0 layout >>>> if you know in advance how your raid0 array was created. This can be >>>> simpler than having to manage module or kernel command-line parameters. >>>> >>> >>> Hi Jason, >>> >>> If the people who compiling the kernel is not the end users, the >>> communication gap has potential risk to make users to use a different >>> layout for existing raid0 array after a kernel upgrade. >>> >>> If this patch goes into upstream, it is very probably such risky >>> situation may happen. >>> >>> The purpose of adding default_layout is to let *end user* to be aware of >>> they layout when they use difference sizes component disks to assemble >>> the raid0 array, and make decision which layout algorithm should be >>> used. Such situation cannot be decided in kernel compiling time. >> >> I agree that in general it may not be known at compile time. Thus, >> I've left the default as RAID0_LAYOUT_NONE. However, there are >> use-cases where it is known at compile-time which layout is needed. >> In our use-case, we knew that we didn't have any pre-3.14 raid0 >> arrays. Thus, we can safely set RAID0_ALT_MULTIZONE_LAYOUT. So >> this is a simpler configuration for us than setting module or command >> line parameters. Song> I would echo Coly's concern that CONFIG_ option could make it risky. Song> If the overhead of maintaining extra command line parameter, I would Song> recommend you carry a private patch for this change. For upstream, it Song> is better NOT to carry the default in CONFIG_. I agree as well. Just because you have a known base, doesn't mean that others wouldn't be hit with this problem. John
