The changes were mechanically generated by this C-program:

@manu: I could use whitespace too as a delimiter. Would that help the read impression?

In D33224#751020, @hselasky wrote:

@manu: I could use whitespace too as a delimiter. Would that help the read impression?

That would be even worse :)

I think indenting the line continuations would help with the readability.

Also I'm not a fan of the automatic conversion.
I've put some work to sort files.arm64 a while ago and now it's a mess.
For example all coresight files are correctly grouped right now but this change put them in different part because some are standard, some for fdt and some for acpi.

In D33224#751117, @manu wrote:

Also I'm not a fan of the automatic conversion.
I've put some work to sort files.arm64 a while ago and now it's a mess.
For example all coresight files are correctly grouped right now but this change put them in different part because some are standard, some for fdt and some for acpi.

The automated conversion isn't good except as a basis for a hand-curated selection of groupings.

If the parser would permit it, I'd be tempted to make dangling pipes indicate line continuation rather than requiring a ton of \s.

In D33224#751147, @brooks wrote:

In D33224#751117, @manu wrote:

Also I'm not a fan of the automatic conversion.
I've put some work to sort files.arm64 a while ago and now it's a mess.
For example all coresight files are correctly grouped right now but this change put them in different part because some are standard, some for fdt and some for acpi.

The automated conversion isn't good except as a basis for a hand-curated selection of groupings.

Yes, exactly. Probably this change will just be an example of what may be done.

If the parser would permit it, I'd be tempted to make dangling pipes indicate line continuation rather than requiring a ton of \s.

It would be easier to user whitespace separation then between the filenames and use the backslash to forward to next line. Whitespace is not allowed in any filenames already.
We know when we have hit the end when "optional" or "standard" is encountered.

Example:

x86/xen/hvm.c \
x86/xen/xen_intr.c \
x86/xen/xen_apic.c		optional	xenhvm

Historically, requiring a newer feature like this right off the bat has been considered suboptimal because folks still use the supported legacy kernel build setup. I don't know how many more folks do, but this was a concern often raised by bde@.

Beyond that, yeah, +1 for not being a fan of automatic conversion. These groups are way too large and actually detrimental for understanding what's happening, and this style of conversion is probably too soon after manu re-alphabetized files.arm64 for the Cheri folks to have forgotten how painful rebasing across changes like this are. :-)

Honestly, I'm not a fan. I hate it almost as much as I hate the original files format.

If you're going to go for something better, then you should go for something better, especially if there's some automatic generation involved.

Unfortunately, there's an odd mix of dependencies and hacks to cope with poor dependency expression here.

For example, look at pvclock.c. it depends on kvm_clock or xenhvm. Really, it should depend on pvclock and the former two options should imply the latter. Then we could start to de-tangle the polluted information we have today. It's but one of many.

So if we're going to have such a large change, lets make it count and adopt a more expressive style.

option xenhvm {
x86/xen/hvm.c
x86/xen/xen_intr.c
x86/xen/xen_apic.c
} compile-with {} implies {} requires {} ...

is way more expressive anyway. And there's half a dozen other ways to do that leverages things like UCL / Lua / etc.
But to make much progress down that path, you need to do something about the dependencies. You need to create a cleaner model first and spend time sorting the 'oddballs' correctly.

So I see this as a lot of churn for such tiny gains as to be undesirable.

In D33224#751328, @imp wrote:

Honestly, I'm not a fan. I hate it almost as much as I hate the original files format.

If you're going to go for something better, then you should go for something better, especially if there's some automatic generation involved.

Unfortunately, there's an odd mix of dependencies and hacks to cope with poor dependency expression here.

For example, look at pvclock.c. it depends on kvm_clock or xenhvm. Really, it should depend on pvclock and the former two options should imply the latter. Then we could start to de-tangle the polluted information we have today. It's but one of many.

So if we're going to have such a large change, lets make it count and adopt a more expressive style.

option xenhvm {
x86/xen/hvm.c
x86/xen/xen_intr.c
x86/xen/xen_apic.c
} compile-with {} implies {} requires {} ...

is way more expressive anyway. And there's half a dozen other ways to do that leverages things like UCL / Lua / etc.
But to make much progress down that path, you need to do something about the dependencies. You need to create a cleaner model first and spend time sorting the 'oddballs' correctly.

So I see this as a lot of churn for such tiny gains as to be undesirable.

We should really start formally defining what we think configng should look like and work towards refining that idea into something practical and most universally acceptable. It might be worth setting up a call at some point and hashing out some of the broad design details. I'm OK with incremental improvements, but at some point we should get an idea of what we really want the end-goal to look like and draw the line for a final cutover.

In D33224#751336, @kevans wrote:

In D33224#751328, @imp wrote:

Honestly, I'm not a fan. I hate it almost as much as I hate the original files format.

If you're going to go for something better, then you should go for something better, especially if there's some automatic generation involved.

Unfortunately, there's an odd mix of dependencies and hacks to cope with poor dependency expression here.

For example, look at pvclock.c. it depends on kvm_clock or xenhvm. Really, it should depend on pvclock and the former two options should imply the latter. Then we could start to de-tangle the polluted information we have today. It's but one of many.

So if we're going to have such a large change, lets make it count and adopt a more expressive style.

option xenhvm {
x86/xen/hvm.c
x86/xen/xen_intr.c
x86/xen/xen_apic.c
} compile-with {} implies {} requires {} ...

is way more expressive anyway. And there's half a dozen other ways to do that leverages things like UCL / Lua / etc.
But to make much progress down that path, you need to do something about the dependencies. You need to create a cleaner model first and spend time sorting the 'oddballs' correctly.

So I see this as a lot of churn for such tiny gains as to be undesirable.

We should really start formally defining what we think configng should look like and work towards refining that idea into something practical and most universally acceptable. It might be worth setting up a call at some point and hashing out some of the broad design details. I'm OK with incremental improvements, but at some point we should get an idea of what we really want the end-goal to look like and draw the line for a final cutover.

Agreed, count me in for this.

Hi Warner,

I like the implies part. That means we can have a quick 2-SAT solver to figure out any conflicts!

Syntax template:

option [!]xenhvm {
x86/xen/hvm.c
x86/xen/xen_intr.c
x86/xen/xen_apic.c
} compile-with {} implies { [!]pci [!]acpi } dependencies {} no-obj ...

standard {
foo/foo.c
} compile-with {} implies { [!]pci [!]acpi } ...

Can I go ahead and implement this?

--HPS

In D33224#751114, @allanjude wrote:

I think indenting the line continuations would help with the readability.

Yes. But maybe after we agree about the format :-) There is a lot of manual work involved here!

One more example trying to remove ZFS will yield:

# cat GENERIC-TEST 
include "GENERIC"

nooptions zfs

# config GENERIC-TEST
WARNING: Conflict option 'zfs' implies: ufs_acl_nfs4 dtrace_zfs crypto_skein crypto_sha512 crypto_sha256 zlib 
WARNING: Conflict option '!zfs' implies: !geom_uzip_zstd !zstdio 
../../conf/files: Option(s) conflict detected!

So if we're going to change the files.XXX format why not going with UCL ?
I'm not a fan of "option standard" too, that doesn't make much sense.
I'm also not a fan of "option !XXX", I know that we have some '!' usage right now but I'm not a fan too.

Looks like I pressed "accepted" by an accident. Ignore that.

In D33224#754126, @hselasky wrote:

@manu : Can you convert an entry using compile-with into UCL format so that we can see how it would look? Are you sure this won't cause a lot of repeated bloat?

There is no "UCL format", we can do whatever we want with it.

There are two changes that mostly don't have anything to do with eachother:

1. The dependency reorder (implies support) and listing multiple files
2. The format (UCL, XML or how it is now)

I don't agree, the format dictate how we express things.

Right now minimal changes have been done to the format.

I think that what I'm trying to say is : like @kevans proposed maybe we should have a call/mail/whatever so we first answer to a few questions like :

• What do we miss with current config ?
• What do we need/want
• etc ...

I too would rather see a firm break in the format, despite the PITA this would cause for MFCs.
I also would love to have a call and/or email chain to work on a design.
My other wish list item, in addition to implies is requires which is kinda the opposite: so bar requires foo would turn off bar if foo is also off. This is generally what you want with bus relationships since otherwise if you have driver bar, but bus foo can't be on the system, you'd need to have some kind of hard failure and that's sounds good at first, but is too inflexible for people that want to subset.

When are people usually available for a talk?

I see there is a graphics driver meeting december 20th? Should we hijack that one?

I don't think I can't do that graphics call, I'll be traveling with the family. I might be able to make it work, but it might be tough.

I started a hackMD that starts with the design notions that I'd like to see, but that we can turn into a requirements and design doc.

https://hackmd.io/w1Tf8mmVQVuZok7-LNEhgw

In D33224#754190, @hselasky wrote:

When are people usually available for a talk?

I see there is a graphics driver meeting december 20th? Should we hijack that one?

Mhm no we shouldn't hijack this.

As a downstream consumer with many changes to various config/files* files I'm fine with a break, but would very much like to avoid having more than one round of large-scale changes. @manu's re-sorting of files.amd64 required completely reimplementing our changes as git had not hope of figuring out what to do. I assume the same will be true of other downstreams. If we did go to UCL it might be worth renaming the files (e.g., files-arm64.ucl)