On Tue, 2019-07-16 at 09:02 +0200, Chris Laif wrote: > On Tue, Jul 16, 2019 at 1:22 AM Ben Hutchings <ben@decadent.org.uk> wrote: > > On Mon, 2019-07-15 at 09:31 +0200, Chris Laif wrote: > > > On Sat, Jul 13, 2019 at 11:37 PM Ben Hutchings <ben@decadent.org.uk> wrote: > > > > On Thu, 2019-07-11 at 15:11 +0200, Chris Laif wrote: > > > This seems to break backwards compatibility for a lot of devices > > > (Google shows lots of hits for "mtdparts=" and only a handful for > > > "cmdlinepart.mtdparts", so I think nobody is using the latter). > > > > > > I wonder what's the best way to have a both Stretch and Buster > > > compatible cmdline. A quick test shows that "cmdlinepart.mtdparts" > > > works with Stretch, too (even Stretch does not have a seperate > > > "cmdlinepart" module). Do you have any recommendations? > > > > I think that "cmdlinepart.mtdparts" will work whether or not the driver > > is actually a module. But I accept it would be better if "mtdparts" > > also continued to work when the driver is a module. > > > > Thanks. Do you know if the acceptance of 'mtdparts' with/without > prefix is specific to the Debian kernel or if it is a decision by the > upstream kernel devs? I remember that some months ago one of the beta > Buster kernels accepted the 'mtdparts' variable, I /think/ the > incompatible change has been introduced during finalisation of Buster. > > Kernel docs (https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html) > refer to the 'mtdparts' variable (without prefix). The difference in behaviour between the built-in and modular builds of the driver, is not specific to Debian. The change to building this driver as a module was our decision, however. That change was made in version 4.16-1~exp1, over a year ago. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports.
Attachment:
signature.asc
Description: This is a digitally signed message part