Dependencies not documented about linux HOT 5 CLOSED

Hi Patrick,

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

Thanks,
Tavi

from linux.

+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.

from linux.

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!

from linux.

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.

from linux.

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.

from linux.