Re: LinuxKPI debugfs Port

Mark,

Your reply clears up a lot. I just forked drm-kmod, applied your Makefile
patch, and added DEBUGFS to kconfig.mk. I am extremely excited to be
back on track, especially now that I know how to proceed.

Just to clarify, my job is to extend the current debugfs implementation
(debugfs.h and lindebugfs.c) to include the missing functionality required
for i915kms to compile and run successfully? I would ask manu@, but
he has not responded to me in weeks.

I greatly appreciate your explanations about LinuxKPI and lindebugfs.
Extensive documentation is what draws me to FreeBSD, but I struggled
to find any information regarding lindebugfs or LinuxKPI. I plan to write
some of my own when I am done with this project to help others in my
position :).

Thank you so much,
Jake Freeland

On Tue, Jun 28, 2022 at 4:18 PM Mark Johnston <markj@freebsd.org> wrote:

> On Tue, Jun 28, 2022 at 03:38:48PM -0500, Jake Freeland wrote:
> > Hi there,
> >
> > I am working on porting Intel's igt-gpu-tools drm graphics driver testing
> > suite to FreeBSD and I ran into some issues regarding debugfs. I spoke
> > to manu@ who told me that CONFIG_DEBUG_FS is required for the
> > testing to work properly. I started working on a debugfs port and quickly
> > got confused about what manu@ meant by implementing "CONFIG_DEBUG_FS".
>
> I would guess that he meant to compile the i915kms driver with
> CONFIG_DEBUGFS configured.  I'm not sure what the "right" way is to do
> that, but adding
>
> KCONFIG+= DEBUGFS
>
> to the end of kconfig.mk in the drm-kmod repository seems to do the
> trick for me, with the caveat that the driver doesn't compile. :)
>
> I think the task is to get it to compile by extending the existing
> debugfs shims in the LinuxKPI, but see my comments below.
>
> There is also a typo in the makefile there, see
> https://github.com/freebsd/drm-kmod/pull/185
>
> > Some quick internet searching says that CONFIG_DEBUG_FS is a
> > Linux kernel configuration flag. I am curious how I would go about
> > implementing this into FreeBSD. I copied the Linux debugfs source
> > code into a new repository and attempted to compile it on FreeBSD
> > as a kernel module:
> >
> > https://github.com/jakesfreeland/debugfs-freebsd
> >
> > Of course I was met with many, many incompatibility errors. I proceeded
> > to copy the required `sys/compat/linuxkpi/common/include/linux` headers
> > into my repository and I was met with two options:
>
> Yes, that's not going to work and isn't the right approach.
>
> > 1. continue modifying the LinuxKPI headers and commit my modifications
> > to src.
> >
> > 2. re-engineer the debugfs source code to comply with the preexisting
> > LinuxKPI headers.
> >
> > Many problems come with both approaches. First, if I modify the LinuxKPI
> > headers, I'd be "copying" over some code from Linux's GPLv2 headers.
> > I do not know how much I can "copy" before legal issues arise. Second,
> > if I re-engineer the debugfs source code, I am revolting against what
> > LinuxKPI
> > stands for: running Linux code with little-to-no modification. I don't
> know
> > what the correct approach is here.
>
> The purpose of the LinuxKPI is to allow Linux _drivers_ to run (mostly)
> unmodified on FreeBSD.  Generic kernel components like debugfs itself
> are not meant to run under the LinuxKPI and are out of its scope.
>
> debugfs provides a set of interfaces used by drivers, including i915, to
> export debug info.  The LinuxKPI provides a partial implementation of
> that interface already, in debugfs.h and lindebugfs.c, and I think the
> task ahead of you is to extend it to allow i915 to compile with DEBUGFS
> configured.  (But please double check that!)
>
> > I also discovered that lindebugfs, a curtailed version of Linux's
> debugfs,
> > already exists in FreeBSD's src. I am led to believe that this is
> > exclusively
> > used under the Linuxulator so it wouldn't help me. Is this correct?
>
> No, I don't think that's accurate.  It's just another pseudo filesystem,
> it can be used by anything that knows how to open and read files.
>
> > Thank you so much,
> > Jake Freeland
>