Re: [PATCH v4 2/5] mmc-utils: Add FFU mode 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2024-10-24 at 18:19 +0000, Avri Altman wrote:
> > On Thu, 2024-10-24 at 11:04 +0200, Bean Huo wrote:
> > > On Thu, 2024-10-24 at 08:00 +0000, Avri Altman wrote:
> > > > > -       { do_ffu, -2,
> > > > > -         "ffu", "<image name> <device> [chunk-bytes]\n"
> > > > > +       { do_ffu1, -2,
> > > > > +         "ffu1", "<image name> <device> [chunk-bytes]\n"
> > > > Ah, but didn't we establish that the current API should be
> > > > retained
> > > > to act as the default mode?
> > > > 
> > > > Thanks,
> > > > Avri
> > > 
> > > Avri,
> > > 
> > > Corret, the reason for updating the default FFU mode name from
> > > 'ffu'
> > > to
> > > 'ffu1' is to avoid the error: 'ERROR: in command 'ffu', 'ffu' is
> > > ambiguous' when using 'mmc ffu'. Without this change, the system
> > > will
> > > encounter ambiguity.
> > > 
> > > 
> > > I am considering a naming scheme like opt_ffu1 and opt_ffu2, that
> > > works well for maintaining consistency and keeping the names
> > > concise.
> > > 
> > > ffu2 could become opt_ffu1 (indicating the first optimized or
> > > alternate FFU mode).
> > > 
> > > ffu3 could become opt_ffu2.
> > > ffu4 could become opt_ffu3.
> > > ffu5 could become opt_ffu4.
> > > 
> > > then keep default ffu name as it is used to be.
> > > 
> > > how do you think?
> > > 
> > > 
> > > 
> > > Kind regards,
> > > Bean
> > 
> > Avri,
> > 
> > how do you think about above my proposal of changing ffux to
> > opt_ffux?
> I don't really have a strong opinion about that.
> As long as the current mode stay the same.
> 
> Thanks,
> Avri


To avoid ambiguity while keeping the default FFU mode as 'ffu', I
cannot use prefix ffu. I’m considering using the prefix opt_ffu for the
optional FFU modes. This would allow us to differentiate between the
default FFU implementation and the various optimized or alternative
modes without using the "ffu" prefix directly.


opt_ffu1: First optional/optimized FFU mode
opt_ffu2: Second optional/optimized FFU mode
opt_ffu3, etc.

This would keep the default ffu unchanged while allowing us to add
clarity and scalability to the naming of other FFU modes.




Hi Ulf

What’s your thought on this approach?

Kind regards, 
Bean






[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux