I suggest FreeBSD porting hardware drivers from Linux Kernel 4.5

Not sure if it's the forum or my web browser, but your link doesn't work for me...

There has certainly been an effort to port Intel i915 DRM from Linux 3.8 which has recently landed in HEAD. It looks as thought it's been a fair chunk of work, not sure how easy it would be to bump it to Linux 4.5 version.

I can't comment on the other driver updates.
 
Things usually can't be ported due to the differences in licenses. To be included in the FreeBSD base OS or kernel the license needs to be compatible with BSD's license. The GPL (and variations thereof) isn't compatible. That means having to write them from scratch.
 
I suggest to FreeBSD porting hardware drivers from Linux Kernel 4.5 :)

Would you like to make a guess about how many man-hours this "suggestion" requires? Would you like the comment on the feasibility of jumping from the equivalent of 3.8 (on FreeBSD-current) to 4.5?

As a point of reference, look at DragonFly. It's been doing this for a couple of years now and has only reached 4.2 so far, going release by release.

moral of the story: It's easy to "suggest" things. I suggest NASA goes to Mars by 2020. See how easy that is?
 
Lots of the Linux kernel code is useless as a starting point because FreeBSD and Linux never shared any code at their beginnings so just about everything is different and uses different methodology to implement certain crucial features and services. This idea is a dead end as it is.
 
are suggesting this for any particular reason?

Indeed. This is an oddly specific suggestion, especially considering that as far as Phoronix is concerned everything that happens to Linux heralds the dawn of a new and better era for the human race.
 
Indeed. This is an oddly specific suggestion, especially considering that as far as Phoronix is concerned everything that happens to Linux heralds the dawn of a new and better era for the human race.

LOL, Given that it's a first post and a new member (welcome - we like new members!) - yes the OP has one of the referenced devices, and wants a driver. He's not wanting to change the FreeBSD mission statement :)

First posters always think these kinds of things are easy peasy ... Hopefully, our new member hangs around long enough to appreciate the answers given here in this thread ...
 
no no no ..

Now is the kernel 3.8, and I suggest starting directly from 4.5.

Because 4.5 to join a lot of new features, I did not say that now began.

If FreeBSD official organization we go to the driver module.

I think a lot of people are willing to take the time to help FreeBSD to finish the job.
 
no no no ..

Now is the kernel 3.8, and I suggest starting directly from 4.5.

Because 4.5 to join a lot of new features, I did not say that now began.

If FreeBSD official organization we go to the driver module.

I think a lot of people are willing to take the time to help FreeBSD to finish the job.

You still don't make any sense and it's obvious that you didn't read the responses you got. You seem to be under a false belief that just because some drivers have been ported/adopted from Linux to FreeBSD it is possible to do that with any Linux driver. If I were you I would first do my homework about the matter before coming on a public board suggesting nonsense.
 
no no no ..

Now is the kernel 3.8, and I suggest starting directly from 4.5.

Because 4.5 to join a lot of new features, I did not say that now began.

If FreeBSD official organization we go to the driver module.

I think a lot of people are willing to take the time to help FreeBSD to finish the job.
You could suggest "starting directly from 4.5" if porting have not been started yet. Porting drivers from 3.8 required a lot of efforts and manpower, and the results of this work will be available in FreeBSD 11-RELEASE pretty soon (in July) after about two years of development. This should give you an idea about how much time and how many efforts are needed to port some software, in particular things like drivers.
Moreover, suggesting a particular kernel version because has more features has no point; because there will always be newer versions with new stuff, and restarting all the work would mean never finish the job. This would be possible if FreeBSD and Linux were so similar to require little or no changes to the code (license apart).
And, even if surely FreeBSD has people that "are willing to take the time to help FreeBSD to finish the job", consider that not all the developers work on this subject.
 
Now is the kernel 3.8, and I suggest starting directly from 4.5.
As I basically already said, this statement illustrates a complete lack of understanding about what exactly your suggestion requires. Do you think that nobody has asked for modern graphic drivers before Linux 4.5 arrived? Wouldn't you expect people wanted Linux 4.4 drivers before this?

I didn't realize that was your first post, but I think you should have thought logically about this. If the support isn't there, and it is widely desirable, there must be a good reason for it, and it's not a day's worth of work to accomplish.
 
As I basically already said, this statement illustrates a complete lack of understanding about what exactly your suggestion requires. Do you think that nobody has asked for modern graphic drivers before Linux 4.5 arrived? Wouldn't you expect people wanted Linux 4.4 drivers before this?

I didn't realize that was your first post, but I think you should have thought logically about this. If the support isn't there, and it is widely desirable, there must be a good reason for it, and it's not a day's worth of work to accomplish.
Hi marino@,

Would you be able to give an estimate on the required man-hours and costs to finish the 3.8 import?

Long ago we, the forums, had a thread where multiple users claimed to be willing to spend a certain amount of their income, to collect the required fees for such a task. I would be curious to give it a try.

PS: Before anyone has the brilliant idea to tell me to contribute to the Foundation, I just want to let everyone know that I do that on a yearly basis.
 
BTW, how other FreeBSD-derivatives made a huge leap porting drm code?

No other "FreeBSD-derivative" made a huge jump. OpenBSD is at 3.9 (this was last time I checked they could be even further ahead), and DragonFlyBSD is at 4.2 IIRC. But:

A) They have several developers dedicated to the graphics stack and they've been working on it non stop.
B) They didn't make a "huge jump", they had to iterate through all the code releases.
C) None of them is a "FreeBSD derivative" OpenBSD and FreeBSD shared a codebase but that was long ago and Dragonfly forked from FreeBSD but its a different architecture.

Now that initial Haswell support is in place, the compatibility layer with Linux has improved a lot and we're probably going to get the next DRM update a lot faster.

It did take a long time to get here, but things are improving by degrees now.
 
31854b3b83225f6337ff974dc2c5957b.jpg
 
Things usually can't be ported due to the differences in licenses. To be included in the FreeBSD base OS or kernel the license needs to be compatible with BSD's license. The GPL (and variations thereof) isn't compatible. That means having to write them from scratch.
I read that a few drivers were made with Berkeley compatible licenses, but Linux just incorporated them first into their kernel code. IMO, FreeBSD's video hardware drivers shouldn't be heavily encouraged past DragonFlyBSD's or the latest BSD's, because doing more requires major rewrites, unless the person who really wants it is willing to put that many work hours into the code.

zoujiaqing
It's better to learn and contribute, so you understand what it takes. If you are unable to work on that directly, then contribute specific bug reports, write documentation or do some other type of assistance.
 
Indeed. This is an oddly specific suggestion, especially considering that as far as Phoronix is concerned everything that happens to Linux heralds the dawn of a new and better era for the human race.
I've seen Phoronix suggest to report anything in FreeBSD ports that doesn't compile under CLANG as a bug. However, I couldn't find this recently, so they either removed it, or I don't know where to look again. I'm not sure if there's consensus for that suggestion.
 
I just have a question. What exactly will I gain if one day the support for Haswell graphics is updated to version 4.6? When I run 11-CURRENT and watch videos with mpv, I can set vo to opengl-hq. Update 3.8 allowed me to do that and I don't see any performance issues when watching videos. Update 4.6 won't allow me to do anything that I am already able to do now.
 
He could always contribute to the Linux compatibility layer.
There is a nice tutorial of having Debian; and of course, there are others.
A bit about jails, permissions and such.
And, maybe, he could work on a port or two.

The Haswell thing?
CISC only exposure and none other; and, yet, they are using their ARM devices to chat nonsense with each other.
It is very ironic that they don't - for the most part - consider hacking their phones.
I still say that exposure to multiple architectures, languages, and operating systems makes one better at hacking.
 
Update 4.6 hasn't been merged with HEAD, right? ...As I mentioned earlier, I run 11-CURRENT, and I am pretty sure it doesn't have drm update 4.6. But maybe the latest HEAD already has update 4.6.
 
Update 4.6 hasn't been merged with HEAD, right? ...As I mentioned earlier, I run 11-CURRENT, and I am pretty sure it doesn't have drm update 4.6. But maybe the latest HEAD already has update 4.6.
HEAD = 11-CURRENT.
 
I meant to say that I was running an older version of 11-CURRENT (which, of course, has been a part of the -HEAD branch for quite a while). I am just curious what update 4.6 will allow me to do that I am unable to do now. As I said earlier, on my Haswell laptop, mpv seems to be perfectly happy with update 3.8.
 
Back
Top