Dependencies not documented

[pscollins]

Not a serious issue, but it would be nice --- on Ubuntu here I had to look into the circle.yml file to realize that I needed

• libfuse-dev
• libarchive-dev
• xfsprogs

bc ships with pretty much all *nix systems as far as I know and the wine/minigw dependencies seem to be for the sake of a Windows integration test, correct me if I'm wrong.

Then to get the test to run I needed:

• btrfs-tools

Also, it seems a little strange to me to give installation instructions for FreeBSD and Windows but not any Linux distros --- it is a kernel fork, after all.

I'll put together a PR with the info, if you'd like --- I don't know if there is a good reason that it's missing at the moment or what.

[tavip]

Hi Patrick,

Yes, a PR with the info is more then welcomed :)

Thanks,
Tavi

[thehajime]

+1 for the documentation.

on the other hands, I've been thinking how messy to track all the dependencies in our document IF we will put much more test/example codes in tools/lkl.

We then may need to have another repository, such as lkl-packages, to host such lkl-specific applications. Dependencies are described by per-application, which may be easier to maintain by each package maintainer.

[tommie-lie]

Judging from the backlash that Tavi got from the XFS maintainers when he proposed the no-mmu patches, I would rather not try to add more application stuff to tools/lkl (except from very bare testbeds in tools/lkl/tests). People are already arguing that lklfuse should not be in the Kernel tree.

My experiments yesterday concerning a new build system (issue #36) looked very promising and I think it will be better to just have the liblkl.{so,a} and necessary headers installed separately. Having the applications separate (and thus not introducing new arbitrary dependencies) will be a lot easier then!

[tavip]

on the other hands, I've been thinking how messy to track all the dependencies in our document IF we will put much more test/example codes in tools/lkl.

IIRC tools/perf has a good systems of detecting and reporting missing required / optional dependencies.

Judging from the backlash that Tavi got from the XFS maintainers when he proposed the no-mmu patches, I would rather not try to add more application stuff to tools/lkl (except from very bare testbeds in tools/lkl/tests). People are already arguing that lklfuse should not be in the Kernel tree.

The concern there was that maintainers will not be able to test this configuration. I think that if we move lklfuse out of tools/lkl we will make that worse.

[thehajime]

Judging from the backlash that Tavi got from the XFS maintainers when he proposed the no-mmu patches, I would rather not try to add more application stuff to tools/lkl (except from very bare testbeds in tools/lkl/tests). People are already arguing that lklfuse should not be in the Kernel tree.

The concern there was that maintainers will not be able to test this configuration. I think that if we move lklfuse out of tools/lkl we will make that worse.

from what I observed from the particular subsystem people, they just don't have willingness to be with LKL. we can simply skip it to support unless we have a strong motivation to include in.