Are Linuxisms impossible to overcome when porting?

j0hn

j0hn

I keep hearing from people in the FreeBSD community that virtually no software with linuxisms can be ported. Are you sure there is absolutely no way at all? I am sorry if it seems like I am asking silly questions but I am not a coder so I don't completely understand. Couldn't a linuxism be overcome with rewriting some parts of the code? I know that is loads upon loads of work but if someone is really dedicated could it be done? I would assume the first and foremost before doing anything to look through the entire code of whatever program is being ported, spot and take note of every single linuxism that exists from within the code.

What if I did that for the FreeBSD community? Such as look at a program and list out every single Linuxism I find? Do the research per say. Could it then be possibly ported by someone who can code?
 
"Linuxism" is vague. Some are simple things, like Linux users assuming sh == bash. Some are much harder to adjust, like assuming certain features of the Linux kernel are present.

Yes, many programs can be modified. Many ports do that.
 
wblock@ said:
"Linuxism" is vague. Some are simple things, like Linux users assuming sh == bash. Some are much harder to adjust, like assuming certain features of the Linux kernel are present.

Yes, many programs can be modified. Many ports do that.
Click to expand...

Oooh I see. So this is the barrier. The Linux kernel has certain features that the FreeBSD kernel lacks. I get it now. So this is why Surfaceflinger or another X.Org alternative that is EGL can't be ported. I understand. Am I getting that right?
 
Linux has grown outside the POSIX standard to add certain features that are left open by the standard or are completely outside its scope. As a consequence programmers who produce code for Linux have started to assume that those extra APIs are universal and are expected to be in place in any system they intend their code to be ported to. FreeBSD hasn't been able to keep up with this development unfortunately.
 
j0hn said:
So this is the barrier. The Linux kernel has certain features that the FreeBSD kernel lacks.
Click to expand...
Either that, or the Linux and FreeBSD kernels just do it differently. There may also be issues with things that aren't directly tied into the kernel, but are part of the base system, such as:
  • exactly how init works (there are a few different init systems for Linux and each distribution chooses its own);
  • which sound framework is being used (e.g. ALSA vs. PulseAudio);
  • what the /proc system looks like.
As said by @wblock, most things that are tied directly into the kernel cannot be ported (or at least not easily) and most things that are in userland can be, but there are probably exceptions in both cases.
 
Last edited by a moderator:
So that would probably be the case with Surfaceflinger. Since it's a part of Android, Google is tying things into the Android kernel to work with Surfaceflinger. So cherrypicking portions of Android to modify to work with the FreeBSD kernel would not be possible as everything is tied directly to the Android kernel. So this is why many people discussed instead of porting Mir, Wayland or Surfaceflinger to FreeBSD it would be better to just custom-write an EGL based windowing system for BSD. (Even though from the looks of it, Wayland was ported.) The same could be said of other software. I guess I had the misconception that most things were easier to port since you're working with existing code.
 
Melvyn said:
Putting in 2cts: the biggest misconception in linux land is that the compiler is gcc.
Click to expand...

However the compiler was always GCC on Linux until very recently when a comparable alternative, namely Clang, became available.
 
I think @Melvyn is hinting that for a developer of an application that will run on Linux assumes GCC is available and will litter his code with GCC-isms that may not be available on non-Linux system (different versions of GCC), or systems that don't use GCC. For a long time, that was an issue with porting Linux-mostly applications to FreeBSD (or any other Unix-like OS).
 
Last edited by a moderator:
Yep, that was and still is the hint. While in C programs it has become less of an issue and Apple are carrying a lot of the porting weight for Clang based systems, there are still GCC-isms in both code and build systems that I run into regularly.
 
kpa said:
Linux has grown outside the POSIX standard to add certain features that are left open by the standard or are completely outside its scope. As a consequence programmers who produce code for Linux have started to assume that those extra APIs are universal and are expected to be in place in any system they intend their code to be ported to. FreeBSD hasn't been able to keep up with this development unfortunately.
Click to expand...
In the BSD world we are very fortunate that those LInux "developments" have been kept at bay ;)
 
You must log in or register to reply here.
Back
Top