From nobody Tue Jun 28 22:11:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7ED3D876BB2 for ; Tue, 28 Jun 2022 22:12:07 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXf2t1xsWz4gHk for ; Tue, 28 Jun 2022 22:12:06 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x736.google.com with SMTP id f14so10864840qkm.0 for ; Tue, 28 Jun 2022 15:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Sqh7sWyhEUw0SETvLcLZl3XmmBWk/vymorJIwloiyU=; b=PKK+QQexQtdiSpT1tfHwczwslSQgOn2+E6ts8OjjDFN7YXz8Uy32vBXAEatfjIl+G0 McsKJ3bPDwt9yGkXIECJa9czUoROfFkV6fzqpDBLVwhQU8TqU8rSX/bgMmGTgHm3j44z VQOFF37zBOoIKjJ6f587vMXCI9D31mdHWx3LZiXbVGLYJ4U4w0bIdKUlgAWAhDHj56H7 f9oXQ+fNbesOfrSSQm1ilyZM91xp8OUt99PulfD9cotRJvbEyZbkf3OxvVrKA4rcHVp2 1v1PEcl4wzHzf2Kfz2jWJSBtc1gLR+VwkOf/3y3fW39lNnjZUKNbt3GbPjt0D1NCkQwS MDfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Sqh7sWyhEUw0SETvLcLZl3XmmBWk/vymorJIwloiyU=; b=2pXWMgm3p2K6H1XDHaQKBiRdtv/IxwCBi+1TUuDwvVuBlq/1u+rRbFiklM7H0/gqrb r6Nvz1kmJJldDyjv6Jc2onvRKAh8zTkDDgfCe7Gs3k8XEBTzQlceM/8rN2JoVw653n/I xfyeKO506D5uh2mb1HC3EAeKq4UCpo1gQGSlTR3nXigBjImUf91MRTkW2FoGcozxx74y pFCVX9Gaq0CsQXpJHAYu17ZaDDzqrqSMx+SEXaI1uHf36FndeaN1yX2YLZ6xefD/zrHY EDeVuc0NyE0AXnpKQH75SfIK+INbQwtNF6B0S0WvNUWrFAQYLX5URDyRlu+8yYfizU5b GqsA== X-Gm-Message-State: AJIora/UxtXEMRQqg0cs3RtdrSOKLtBcRtVBicxuP0hqc8c8jKv8zRuK vAiMOo8Dp5By3Unlg/IeHnZ4Y8vIwGFR7NieRiVa3Zq9LgCXCg== X-Google-Smtp-Source: AGRyM1uOCR/6ZPWrk5GQwF93pSsTN7GHBxQcIg6TGqFpsGDmrwnjXGPpscRCuDrw6fAA0jXcGX4Vy+wHetVmtAzysFM= X-Received: by 2002:a05:620a:c91:b0:6af:4b9:4c1b with SMTP id q17-20020a05620a0c9100b006af04b94c1bmr64707qki.615.1656454319714; Tue, 28 Jun 2022 15:11:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Tue, 28 Jun 2022 17:11:49 -0500 Message-ID: Subject: Re: LinuxKPI debugfs Port To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005048c105e289538c" X-Rspamd-Queue-Id: 4LXf2t1xsWz4gHk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=PKK+QQex; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::736) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[technologyfriends.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; NEURAL_HAM_SHORT(-0.98)[-0.980]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000005048c105e289538c Content-Type: text/plain; charset="UTF-8" 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 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 > --0000000000005048c105e289538c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark,

Your reply clears up a lot. I jus= t forked drm-kmod, applied your Makefile
patch, and added DEBUGFS= to kconfig.mk. I am extremely=C2=A0excit= ed 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 t= he missing functionality required
for i915kms to compile and run = successfully? I would ask manu@, but
he has not responded to me i= n weeks.

I greatly appreciate your explanations ab= out LinuxKPI and lindebugfs.
Extensive documentation=C2=A0is what= draws me to FreeBSD, but I struggled
to find any information reg= arding lindebugfs or LinuxKPI. I plan to write
some of my own whe= n 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 Fr= eeland 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 quic= kly
> 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.=C2=A0 I'm not sure what the "right"= ; way is to do
that, but adding

KCONFIG+=3D 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-freebs= d
>
> Of course I was met with many, many incompatibility errors. I proceede= d
> to copy the required `sys/compat/linuxkpi/common/include/linux` header= s
> 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<= br> > LinuxKPI headers.
>
> Many problems come with both approaches. First, if I modify the LinuxK= PI
> 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 aris= e. Second,
> if I re-engineer the debugfs source code, I am revolting against what<= br> > LinuxKPI
> stands for: running Linux code with little-to-no modification. I don&#= 39;t know
> what the correct approach is here.

The purpose of the LinuxKPI is to allow Linux _drivers_ to run (mostly)
unmodified on FreeBSD.=C2=A0 Generic kernel components like debugfs itself<= br> 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.=C2=A0 The LinuxKPI provides a partial implementation of<= br> 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.=C2=A0 (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<= br> > exclusively
> used under the Linuxulator so it wouldn't help me. Is this correct= ?

No, I don't think that's accurate.=C2=A0 It's just another pseu= do filesystem,
it can be used by anything that knows how to open and read files.

> Thank you so much,
> Jake Freeland
--0000000000005048c105e289538c--