Re: [PATCH 0/7] Let user specify the kernel version for features

[Anand Jain <anand.jain@oracle.com>]

> I meant, it can be done in packaging level and it's much easier to do.

  Its all about trade off, and there is no right or wrong, so is tough
  to arrive at a conclusion even before this was implemented. Below are
  the choices considered, now putting in the order of least suitable
  to most suitable after reviewing their advantages and disadvantages.

  . Update default features at the compile time, so to have a define
    set for the default choices per release/distro. (not sure how to
    do that), But with this, you can not solve the problem for which
    current "-O comp=" is provided (i.e to provide features which are
    compatible across a set of known kernels). And mainly, you are
    letting the control of such a discussion out of btrfs/mainline.
    Then distros will have own set of default features instead of having
    such an effort discussed and converged at the mainline.

  . /etc/btrfs.conf file to hold the default features (same as ext4)
    I have to drop this idea since from the user point of view you are
    creating another source of config/input that user/distro has to
    care about.

  . Do it at run time for the running kernel. Current. In the order of
    priority .. check sysfs, if not check kernel-version, if not use
    progs-version-based-defaults (original).


> And it's much predictable than version based detection.

  I think you mean to say its not predictable because it follows
  a priority list, and we won't know which system used sysfs/version/
  progs-version. Concern is valid. But I feel its trivial, unless
  you have some strong reason. Further still its only a trade off that
  could achieve.

  Other concern that others commented..

  if sysfs is not there and feature is backported, for this we should
  ensure sysfs feature is also backported along with the feature it
  self, without that feature back port is incomplete. If distro does not
  want to backport sysfs, the other choice that disto has is to update
  the feature-to-version table in the progs.

  For the system which does not provide version at all, it will fail
  back to the original progs-version-based-defaults.


  Hope I have captured all the concerns and addressed them.


Thanks, Anand