wdym perfet world, even in normal world, the world we live in that's how things are done, that's how drivers are made normally, and since the foundation was pouring down so much money to hire expert devs, writing native drivers should be a possibility for them, have you ever heard if any other os doing anything like this? no, because this is wrong

Do we know how much linuxulator affects performance?

Do we know how much linuxulator affects performance?

linuxulator is a different thing, this is linuxkpi

and linuxkpi is far from complete, that causes freebsd specific bugs and missing features due to it being incomplete, and completing it is a very hard task compared to just writing native drivers because linuxkpi is derived from gpl code, which forces freebsd devs to use manuals as the only source to make it possible you can read the wiki to know more https://wiki.freebsd.org/LinuxKPI

wdym perfet world, even in normal world, the world we live in that's how things are done, that's how drivers are made normally, and since the foundation was pouring down so much money to hire expert devs, writing native drivers should be a possibility for them, have you ever heard if any other os doing anything like this? no, because this is wrong

NDISwrapper, NDISulator ...

NDISwrapper, NDISulator ...

it's a separate software written by separate people, it's not officially part of linux kernel, but these drivers are common laptop hardware drivers, like wifi ones which are going to be officially used in freebsd

if you need network on linux you don't by default use NDISwrapper, but for those who will need those specific wifi drivers on freebsd will need linuxkpi

hmm, this might sound like a controversial opinion, but in my opinion the idea of adding hardware and wifi support using linux drivers and a compat layer is a bad one, hardware drivers should be native without translation as they are performance critical

there is no translation in linuxkpi. linux kernel programming interface, that means freebsd kernel has functions behaving like linux ones, enabling linux drivers to build in freebsd environment

no performance penalty

actually linuxkpi is the best strategy. getting all the linux fruits without linux annoyances

no performance penalty

read the wiki page of linuxkpi, and you will see the penalties on your own and there is translation

read the wiki page of linuxkpi, and you will see the penalties on your own and there is translation

linux -> freebsd translation, its written clearly in wiki

read the wiki page of linuxkpi, and you will see the penalties on your own and there is translation

misinformation

sir there is no translation, but rather a porting layer on source code level check it out for yourself https://github.com/freebsd/freebsd-src/blob/main/sys/compat/linuxkpi/common/src/linux_usb.c come and see

misinformation

i would trust the wiki more then the words of a random person on tg

The drm drivers with the LinuxKAPI are still couple of years behind imagine if it was a "Native" implementation .

i would trust the wiki more then the words of a random person on tg

it mentions problems such as bugs, but no performance penalties

it mentions problems such as bugs, but no performance penalties

it mentions translation as well

Translation does not mean what you think here .

its the same deal as it was with solaris porting layer in openzfs early days

Translation does not mean what you think here .

translation means translation, wdym?

translation means translation, wdym?

wine -> translating ABI userland calls / syscalls linuxulator -> translating ABI syscalls linuxkpi -> translating (but I would rather say wrapping) API on source code level, once. then linux driver built as module and access functions in freebsd kernel directly

there is no runtime computational translation involved in linuxkpi

wine -> translating ABI userland calls / syscalls linuxulator -> translating ABI syscalls linuxkpi -> translating (but I would rather say wrapping) API on source code level, once. then linux driver built as module and access functions in freebsd kernel directly

you sentence doesn't make sense, translation happens in runtime, wdym before compiling? that's just source code there

to simplify its like you have certain linux driver that expects certain linux functions and therefore linux behavior, for example pci_get_class freebsd has similar function named pci_find_class_from the linuxkpi code bridges two functions together, shuffling stuff a little

dont interpret words too literally

in BSD UNIX you must see the grand vision, not just stick to words

there is no sticking to words here but rather sticking to what is shown, and i am not retarded enough to spend my days digging unto the linuxkpi source to prove what is already proven in the wiki

there is no sticking to words here but rather sticking to what is shown, and i am not retarded enough to spend my days digging unto the linuxkpi source to prove what is already proven in the wiki

> i am not retarded enough to spend my days digging unto the linuxkpi source to prove what is already proven in the wiki such attitude is disrespectful and unacceptable

> i am not retarded enough to spend my days digging unto the linuxkpi source to prove what is already proven in the wiki such attitude is disrespectful and unacceptable

disrespectful to who? i am talking about myself

i didn't called anyone else anything

there is no sticking to words here but rather sticking to what is shown, and i am not retarded enough to spend my days digging unto the linuxkpi source to prove what is already proven in the wiki

"A deeper dive into LinuxKPI source proves that Linux --> FreeBSD translation is not easy. Even though LinuxKPI enables working drivers, there exist FreeBSD-specific bugs and missing features as a result of LinuxKPI's incomplete, and sometimes incorrect, translation. " A real performance penalty that happens is introduction of another layer of code, that has inherent performance hit because driver code executed slightly longer than it was in native linux kernel. but thats too synthetic and dry, in native linux you would have other factors that completely obliterate performance difference not in favor of linux

https://cdaemon.com/posts/pwS7dVqV even cdaemon says there exists freebsd specific bugs, performance hits because of linuxkpi

i really have no reason to show anything and prove what is already proven

https://cdaemon.com/posts/pwS7dVqV even cdaemon says there exists freebsd specific bugs, performance hits because of linuxkpi

not because of runtime translation, but because of differences of implementations

also this discussion is one big nothing burger. linuxkpi just works and freebsd is best bsd

not because of runtime translation, but because of differences of implementations

there is no "different implementations" but as he says little modified drivers

there is no "different implementations" but as he says little modified drivers

*different implementations of standard kernel functions, such as memory allocators or resource schedulers

linuxkpi sounds really useful. If this goes well and becomes sound I might just have to consider FreeBSD for my daily driver

also this discussion is one big nothing burger. linuxkpi just works and freebsd is best bsd

>many says linuxkpi has issues >but everyone should believe a random person on telegram

>many says linuxkpi has issues >but everyone should believe a random person on telegram

Do you understand what is LinuxKPI, and more generally what is porting layer?

getting both linux drivers work and getting rid of linuxkpi means transforming freebsd kernel info 1:1 linux kernel, which is not good and more over impossible in terms of work volume

i don't need to answer your meaningless questions, the discussion was about linuxkpi issues and many trustable sources say they exists

https://cdaemon.com/posts/pwS7dVqV even cdaemon says there exists freebsd specific bugs, performance hits because of linuxkpi

Even if this is true, Would you want to have native drivers 6 years behind supporting a narrower set of hardware, or ones supporting more hardware and being newer with KAPI?

I've been using drm forever and there was exactly 0 issues .

Even if this is true, Would you want to have native drivers 6 years behind supporting a narrower set of hardware, or ones supporting more hardware and being newer with KAPI?

why 6 years behind? in what aspect? why would the scope of hardware would be narrow when it is easier to port drivers into native freebsd drivers?

why 6 years behind? in what aspect? why would the scope of hardware would be narrow when it is easier to port drivers into native freebsd drivers?

thats literally purpose of linuxkpi

why 6 years behind? in what aspect? why would the scope of hardware would be narrow when it is easier to port drivers into native freebsd drivers?

🤦‍♂

why 6 years behind? in what aspect? why would the scope of hardware would be narrow when it is easier to port drivers into native freebsd drivers?

Without KAPI the drivers need to be rewritten for FreeBSD, and that takes a huge amount of effort .

thats literally purpose of linuxkpi

buddy, native freebsd drivers never had "linux" in their names, native drivers would just work with the native kernel, but there is a general linuxkpi driver needed to make other linuxkpi drivers work

Without KAPI the drivers need to be rewritten for FreeBSD, and that takes a huge amount of effort .

no it doesn't, even cracaur says it is easier to port drivers rather then make them run through linuxkpi, for example for the erofs-fuse driver https://forums.freebsd.org/threads/mounting-erofs-images-in-freebsd.97006/post-692058

bruh

you just googling random linuxkpi results?

you just googling random linuxkpi results?

? that's my own discussion with him yesterday

>https://forums.freebsd.org/threads/mounting-erofs-images-in-freebsd.97006/post-692058 >The fuse porting sounds more promising. fuse has nothing to do with kernel

no it doesn't, even cracaur says it is easier to port drivers rather then make them run through linuxkpi, for example for the erofs-fuse driver https://forums.freebsd.org/threads/mounting-erofs-images-in-freebsd.97006/post-692058

🤣

>https://forums.freebsd.org/threads/mounting-erofs-images-in-freebsd.97006/post-692058 >The fuse porting sounds more promising. fuse has nothing to do with kernel

we talked about porting drivers

Maybe actually read it ?

He says a fuse driver would be easier, not a native in kernel one !

There is the licensing issue too .

He says a fuse driver would be easier, not a native in kernel one !

i didn't talked about native driver but running the fuse driver through linuxkpi

There is the licensing issue too .

as it is with other linux drivers

i didn't talked about native driver but running the fuse driver through linuxkpi

What are you talking about ?

ok polyduekes, whats your goal with this discussion? if you are not volunteering for source code contributions then its meaningless

Fuse drivers run as a process .

Fuse drivers run as a process .

erofs-fuse is a userland driver, maybe you should google a bit

erofs-fuse is a userland driver, maybe you should google a bit

Yeah that's my point !

userland driver is not kernel driver

ok polyduekes, whats your goal with this discussion? if you are not volunteering for source code contributions then its meaningless

i have all the freedom to put my opinions about freebsd in a public group about freebsd, you can't deny me from not talking jn a public group

linuxkpi is kernel thing. the forum topic about erofs was mentioning linux erofs kernel driver, and OP asked was it more viable to do port via linuxkpi into freebsd kernel where responder said its better to port fuse-erofs userland from linux to freebsd

userland driver is not kernel driver

i know, but as i have already shown the gpl issues, performance hits, and bugs make native drivers more viable

i know, but as i have already shown the gpl issues, performance hits, and bugs make native drivers more viable

so what?

hmm, this might sound like a controversial opinion, but in my opinion the idea of adding hardware and wifi support using linux drivers and a compat layer is a bad one, hardware drivers should be native without translation as they are performance critical

so

By reading your forum post I see that you are mixing stuff together .

native drivers better

what is the community for? you think vendors made all the drivers for openbsd and linux?

oh, you just deleted, nvm then

Fuse drivers != Native in kernel drivers LinuxKAPI != Linuxulator Fuse driver == A userland process Native driver == Runs Inside the kernel space

linuxkpi drivers != native drivers