> I really don’t see why you think the file would be regularly edited by
> someone who isn’t a distro or ZFS developer.
I see a use case to do this, thus at least I would want to edit the file. As of
> Grub: We discussed this before, and we decided it was too hard and we were
> going to defer the
With it being a configuration file you're done with
zfs; (not even having to do the second step for
modifications made to prior to the update as
usually offers to merge existing changes into the new version
being installed).
Having it in the .c code leads to having to fetch/patch/compile/
On 3/27/19 5:01 PM, Gregor Kopka wrote:
> I care, having it in the .c code makes is needlessly harder to modify as
> it would be incompatible with installing ZoL from the distributions
> repository.
While I agree that it is harder to modify something in the source than
in a configuration, file I d
>
> Thankfully, these can be solved in exactly the same way. When you create
the features=portable behavior, I will propose a features=grub
definition. I don't really care if this is in ZoL .c code, in a text
file, or in an Debian/Ubuntu patch.
I care, having it in the .c code makes is needlessl
On 3/27/19 2:13 PM, Rich wrote:
> Honestly, if nobody else writes it or convinces me otherwise, I'll
> probably take a stab at it in the next 7 days, as the actual
> implementation without configurability shouldn't require a lot of
> code. (...neither should permitting configurability, really, it's
On Wed, Mar 27, 2019 at 12:14 PM Rich wrote:
> Honestly, if nobody else writes it or convinces me otherwise, I'll
> probably take a stab at it in the next 7 days, as the actual
> implementation without configurability shouldn't require a lot of
> code. (...neither should permitting configurabilit
Honestly, if nobody else writes it or convinces me otherwise, I'll
probably take a stab at it in the next 7 days, as the actual
implementation without configurability shouldn't require a lot of
code. (...neither should permitting configurability, really, it's just
that AFAIK zpool doesn't currently
> On Mar 27, 2019, at 11:46 AM, Gregor Kopka
> wrote:
>
> I read the proposal as giving a ZFS admin the QoL to not having to dig
> through some feature compatibility matrix each time he wants to create a pool
> that should be importable on a set of other machines.
>
> I'm fine with that ge
I read the proposal as giving a ZFS admin the QoL to not having to dig through
some feature compatibility matrix each time he wants to create a pool that
should be importable on a set of other machines.
I'm fine with that general idea. I just see no point (and no benefit) in
hardcoding the val
> On Wed, Mar 27, 2019 at 1:17 PM Gregor Kopka
> wrote:
> >
> > @ahrens: Having an additional user-defined feature set list dosn't make
> > sense, it doubles the coding effort (having to check hardcoded and user
> > defined ones).
> > It would also open the question of who takes precedence: the
If the primary purpose is to enforce a consistent baseline of behavior
on all platforms, letting you override those baselines defeats the
point, because then you need to explicitly specify it all the time in
case someone decided they knew better.
Adding additional ones seems like a debatable trade
@ahrens: Having an *additional* user-defined feature set list dosn't make
sense, it doubles the coding effort (having to check hardcoded and user defined
ones).
It would also open the question of who takes precedence: the user ones (as I
would expect from OS software) or you enforcing your *hard
On Mon, Mar 25, 2019 at 10:53 AM Gregor Kopka <
mailfrom-openzfs.topicbox@kopka.net> wrote:
> Looks good.
>
> Only thing: *please* make this feature lookup the features for a set *from
> a plain text file* (like in /etc/zfs/), just containing
> features_name = comma, separated, list, of, featu
> It seems fine, perhaps, to allow __additional__ feature sets this way, but I
> think the "portable" family really needs to be something compiled in. The
> core value proposition is that "zpool create -o features=portable-2016" is
> the same __everywhere__, and allowing it to be easily overrid
I think we're agreeing loudly - as I said, I have concerns about the
implications of allowing it to be configurable, but if we did, we
should probably blacklist overriding any hardcoded defines.
Not allowing that also resolves that problem.
- Rich
On Mon, Mar 25, 2019 at 10:08 PM Josh Paetzel w
On Mon, Mar 25, 2019, at 6:32 PM, Rich wrote:
> I'm not usually in favor of limiting configurability, but in this
> case, I agree with Joshua - letting people add their own custom
> defines for e.g. debian-buster or epel6 or ubuntu1604 might be fine
> (though at that point I'd still like somethi
I'm not usually in favor of limiting configurability, but in this
case, I agree with Joshua - letting people add their own custom
defines for e.g. debian-buster or epel6 or ubuntu1604 might be fine
(though at that point I'd still like something like a constraint
solver to say "I want this to work o
On Mon, 25 Mar 2019 at 10:53, Gregor Kopka
wrote:
> Looks good.
>
> Only thing: please make this feature lookup the features for a set from a
> plain text file (like in /etc/zfs/), just containing
> features_name = comma, separated, list, of, feature, names
> and not something compiled in.
> It s
Looks good.
Only thing: *please* make this feature lookup the features for a set *from a
plain text file* (like in /etc/zfs/), just containing
features_name = comma, separated, list, of, feature, names
and *not* something compiled in.
It should be easy to define custom feature sets, this would
19 matches
Mail list logo
