Page MenuHomeFreeBSD

linuxkpi: Move kobject related function in its own file
AbandonedPublic

Authored by manu on Oct 9 2020, 9:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 14 2024, 12:53 PM
Unknown Object (File)
Oct 27 2023, 4:40 PM
Unknown Object (File)
Jul 19 2023, 11:33 PM
Unknown Object (File)
Jul 12 2023, 8:40 AM
Unknown Object (File)
Jul 12 2023, 7:52 AM
Unknown Object (File)
Jul 12 2023, 6:56 AM
Unknown Object (File)
May 18 2023, 12:54 PM
Unknown Object (File)
Dec 16 2022, 1:41 PM
Subscribers

Details

Reviewers
None
Group Reviewers
linuxkpi
Summary

kobject is only needed when we want to fully emulate linux drivers
and not when we need linux helpers like in drmkpi.

No functional changes intended.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

manu requested review of this revision.Oct 9 2020, 9:28 PM
sys/compat/linuxkpi/common/src/linux_kobject.c
2–4

In contrast to the timer change, some parts of this new file indeed date to the original version of linux_compat.c

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

I don't see how you could currently fully split kobj off from a linux device and make it optional?

So while I like the idea of having the functions in their own file, I am confused a bit by the short explanation given.

sys/compat/linuxkpi/common/src/linux_compat.c
2391

Can we internally please keep the prefix even if it changed and can them by their proper name with the lkpi_ prefix?

sys/modules/linuxkpi/Makefile
12

If we prefix the functions with linuxkpi or lkpi now, shouldn't we also call the files linuxkpi_foo.c now for everything new we create?

In D26727#595874, @bz wrote:

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

See D23085 (Or https://github.com/evadot/freebsd/tree/drm_base_v5.6-20201007 for a more up to date version).

I don't see how you could currently fully split kobj off from a linux device and make it optional?

drmkpi is basically linuxkpi without linux device emulation part

So while I like the idea of having the functions in their own file, I am confused a bit by the short explanation given.

In D26727#595888, @manu wrote:
In D26727#595874, @bz wrote:

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

See D23085 (Or https://github.com/evadot/freebsd/tree/drm_base_v5.6-20201007 for a more up to date version).

Another tree. Thanks!

I don't see how you could currently fully split kobj off from a linux device and make it optional?

drmkpi is basically linuxkpi without linux device emulation part

So is the goal to be able to merge this into linuxkpi as well and hence the separation of files or will it stay separate?

In D26727#595906, @bz wrote:
In D26727#595888, @manu wrote:
In D26727#595874, @bz wrote:

Can you quickly elaborate what "drmkpi" is? Is that what we know as drm.ko? If that's it then is the reason that you basically have a freebsd module implementation there and just an internal glue to the linux device?

See D23085 (Or https://github.com/evadot/freebsd/tree/drm_base_v5.6-20201007 for a more up to date version).

Another tree. Thanks!

I don't see how you could currently fully split kobj off from a linux device and make it optional?

drmkpi is basically linuxkpi without linux device emulation part

So is the goal to be able to merge this into linuxkpi as well and hence the separation of files or will it stay separate?

Some people didn't like the code duplication (which is understandable) so my goal is to split linuxkpi into "helpers" and device/file emulation part.
I'm still unsure if that will work in the long term but we'll see.

Will give this another shot later this year.