• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

New kernel

Started by AAA, 2008.11.07, 17:05:07

Previous topic - Next topic

rwklein

Quote from: Fahrvenugen on 2008.12.20, 19:12:37
Hi,

I think where the questions arise is there is little information on how this kernel was developed, and so it is difficult to know what the legalities of this kernel are.

From what I see, there are a few ways this kernel could have been developed (again, without more information from those who put it together, it is difficult to know for sure).  They include:

1.  Taking the current 104a kernel and applying patches and adding additional code to it, without any source code or decompiling the kernel.   And modifying the kernel loader to allow other stuff to be loaded  up before the kernel and hook into it.   This would be similar to how Dani's Patchldr file on Hobbes used to be needed to patch the OS/2 loader to get it to recognize installed memory above 64 MB on some motherboards.  This is the most likely method that has been used to develop this kernel.

2.  Somehow getting the source code from IBM (via leaked source or other legitimate channels) and then modifying / recompiling it.

3.  Somehow decompiling the current kernel to develop a source code, and then modifying that.

As for legalities, I do agree with Roderick that any of these options would pose questionable legalities and licenses.  Here's why, I'll discuss each option separately:

Option 1:
1.  If the current 104a SMP kernel was just patched and then redistributed, then those distributing this "patched" kernel are unlikely to have a license to distribute this kernel.  The bulk of the kernel is IBM's, and unless you have a license agreement with IBM to distribute a patched kernel, then any distribution of this kernel is illegal, even if it is distributed only to those who already have OS/2 licenses to run the original kernel. 

This does not prevent you from distributing the code that has been used to patch the kernel, provided you have a license to distribute that code (or if you have written it yourself), and then end users could run that "patching" code against their own 104a kernel to create a "patched" kernel themselves (similar to how the Patchldr fix works).  I'm not sure what the license restrictions are on patching your own kernel, I'll have to check that. 

But I do know that to distribute a complete "patched" kernel package yourselves without a license to do so, yes - it is from a legal perspective considered piracy.

From my understanding of the ZIP, there is no license file included in it, so I am guessing that you don't have a license to distribute a patched kernel.  IBM's legal team is pretty good about such things, so if there had been such a license granted, I'm sure a copy of that license would have been included in the ZIP distribution file.

Option 2:
2.  If the 104a source code somehow was somehow used to develop this kernel and then compiled, then again I question its legality.  If the source code was leaked from IBM and leaked code is being used, then it is obvious that you won't have a license to modify this and redistribute.  If IBM has legitimately provided access to the source code, then there would be a license file included in the ZIP from IBM, explaining the rights and license that comes with this distribution.  As a result it is likely that if 104a kernel source code has been used for this kernel then it is an illegal use, and thus would fall under the category of piracy.

Option 3:
3.  If the current 104a kernel was somehow decompiled, modified, and then compiled and distributed, then this definitely is piracy. 

So any way that I look at it, there are serious legal questions that arise from this kernel.




I was writing a reply but you have stated already what the problems are. This is binary patched kernel, the docs also state this. The previous kernel also had certain portions of the copyright modified. Next to the license missing this was also problem (they seem to "fixed") this now. But the way they distribute these patches is illegal.

The stuff for example the os2ldr patch was done by Daniela is very different.

The OS/4 team does not seem to have much knowledge of legal stuff if none at all...

rwklein

Quote from: djcaetano on 2008.12.18, 14:23:08

  Hi Pete,

Quote from: Pete on 2008.12.18, 04:51:02
Hi djcaetano
You state earlier in this thread "Also, no changes on using SMP and OS/4 Kernel: enabling SMP
detection on ACPI caused the system to freeze when starting to process the RUN statements of CONFIG.SYS."

  Just to clear my statement, using SMP with IBM's SMP kernel sometimes causes a freeze.
Using SMP with OS/4 SMP kernel always causes a freeze.

Quote from: Pete on 2008.12.18, 04:51:02
Can I ask what switches were in use on the PSD= line? and also what mainboard chipset is involved?

  No problem. My PSD line is:

  PSD=ACPI.PSD /SMP /APIC

  I had tested other parameters some months ago, but no luck. Any suggestions?
  The chipset is Intel G31 Express (north bridge) and Intel ICH7 (south bridge).

Quote from: Pete on 2008.12.18, 04:51:02
Might also be worth checking exactly where the system gets stuck... do you have an empty text file called ALTF2ON.$$$ in the root directory of your boot drive?  If not create 1 with a text editor - simply save an empty file to that drive:\path\filename - and see if that helps identify where the boot stops.

  Well, in fact I had already did this test. It freezes always in the moment it will execute the first RUN statement. I had already tried to change the order of previous statements and it freezes in the same place (on the first RUN statement). I modified the order of RUN lines on config.sys and the boot keeps freezing on the first RUN statement.
  I seems a problem related to the way RUN statement is processed by the kernel. Weird, huh?
  I'll do some more tests later. With OS/4 kernel it is easier to test, since it always hangs in that
place.

Quote from: Pete on 2008.12.18, 04:51:02
I also note that you are using ACPI v3.11 - might be worth updating that to v3.14 (the latest, v3.7 is awhile away I think :-)

   Yes, I have to renew the eCS "software subscription".
   Anyway, this boot-freeze problem is being a constant since earlier versions of ACPI, never changed a bit. And the freeze only happens when using SMP kernel. With UNI kernel the boot is always flawlessly completed.
   As soon as possible (probably next month) I will renew my subscription and test the new ACPI version.


The problem with the hang on run and call statements is the following. What happens is that when all device driver are loaded some stuff happens in the kernel. At this time of the evening I forgot what :-) It does some switching in modes. Thats why you are seeing frequent hangs with ACPI. But this close to being fixed.

The machine is most cases does hang it just ULTRA busy hanging in a loop somewhere in some kernel/acpi code
because something goes wrong.

Roderick Klein
Mensys

AAA

Quote from: Fahrvenugen on 2008.12.20, 19:12:37
Hi,

I think where the questions arise is there is little information on how this kernel was developed, and so it is difficult to know what the legalities of this kernel are.

From what I see, there are a few ways this kernel could have been developed (again, without more information from those who put it together, it is difficult to know for sure).  They include:

1.  Taking the current 104a kernel and applying patches and adding additional code to it, without any source code or decompiling the kernel.   And modifying the kernel loader to allow other stuff to be loaded  up before the kernel and hook into it.   This would be similar to how Dani's Patchldr file on Hobbes used to be needed to patch the OS/2 loader to get it to recognize installed memory above 64 MB on some motherboards.  This is the most likely method that has been used to develop this kernel.

2.  Somehow getting the source code from IBM (via leaked source or other legitimate channels) and then modifying / recompiling it.

3.  Somehow decompiling the current kernel to develop a source code, and then modifying that.

As for legalities, I do agree with Roderick that any of these options would pose questionable legalities and licenses.  Here's why, I'll discuss each option separately:

Option 1:
1.  If the current 104a SMP kernel was just patched and then redistributed, then those distributing this "patched" kernel are unlikely to have a license to distribute this kernel.  The bulk of the kernel is IBM's, and unless you have a license agreement with IBM to distribute a patched kernel, then any distribution of this kernel is illegal, even if it is distributed only to those who already have OS/2 licenses to run the original kernel. 

This does not prevent you from distributing the code that has been used to patch the kernel, provided you have a license to distribute that code (or if you have written it yourself), and then end users could run that "patching" code against their own 104a kernel to create a "patched" kernel themselves (similar to how the Patchldr fix works).  I'm not sure what the license restrictions are on patching your own kernel, I'll have to check that. 

But I do know that to distribute a complete "patched" kernel package yourselves without a license to do so, yes - it is from a legal perspective considered piracy.

From my understanding of the ZIP, there is no license file included in it, so I am guessing that you don't have a license to distribute a patched kernel.  IBM's legal team is pretty good about such things, so if there had been such a license granted, I'm sure a copy of that license would have been included in the ZIP distribution file.

Option 2:
2.  If the 104a source code somehow was somehow used to develop this kernel and then compiled, then again I question its legality.  If the source code was leaked from IBM and leaked code is being used, then it is obvious that you won't have a license to modify this and redistribute.  If IBM has legitimately provided access to the source code, then there would be a license file included in the ZIP from IBM, explaining the rights and license that comes with this distribution.  As a result it is likely that if 104a kernel source code has been used for this kernel then it is an illegal use, and thus would fall under the category of piracy.

Option 3:
3.  If the current 104a kernel was somehow decompiled, modified, and then compiled and distributed, then this definitely is piracy. 

So any way that I look at it, there are serious legal questions that arise from this kernel.


As far as I understood, the problem is in the distribution ways only.

They have distributed a kind of software to patch the original kernel but not the kernel itself? If this is the only problem, then the legality issue is off, I hope. It should be easy for them to do it this way. But complications may arise for those who want to do patching :) . Of course, not very big.

Regards,
AAA

Pete

Hi Pasha

I've finally run into a problem with this kernel - it does not seem to want to work with UDF formatted discs.

When I try to access a UDF formatted disc from either the WPS drive object or the command line the system appears to have crashed - maybe it is trying to do the debug bit but as I'm not trying to debug I would not know - requiring a press of the Reset button.

What seems to confirm that the problem is with the os4 kernel is that if I select to boot using 14.104a_SMP then there is no problem accessing UDF formatted discs.

I have yet to test other CD/DVD writing software.

Regards

Pete


Pete

Hi All

Just to correct my previous post: None of the test kernels available will work with UDF formatted DVD+RW; All seem to work fine with UDF formatted DVDRAM; DVD-RW untested as I do not use these discs.

By "UDF" I mean the OS/2 (UDF216) UDF.IFS not the format option included with dvddao - which works fine to format a DVD+RW during the dvd copy process.

RSJ works fine with CDs; cdrecord2 seems to work fine as well.

So, the only "burning issue" is UDF and DVD+RW discs.

If anyone has any "fine tuning" suggestions to overcome this problem I'm interested  :-)

Regards

Pete


IBManners

#65
You could try reverting to an earlier kernel.

Cheers
I am the computer, it is me.

alstaszko

The package doesn't contain the file "os2ldr" but contains "os2ldr.ini" and "os2ldr.read.me".
The install instructions assume it's in that package.

Is this correct i.e. "os2ldr" is in a separate package or does it imply that one should use one from an earlier package?

Andy Staszko

Pete

Hi

Quote from: IBManners on 2009.03.19, 13:57:48
You could try  ftp://Linking to this site is not permitted on our forums/os2krnlSVN1098.zip


Sadly the problem is common to all the "test" kernels available  :-(

As there is no problem when using kernel 14.104a_SMP I can only guess that something to do with "tweaking" the debug kernel used causes this problem. This may not be common to other systems and could involve other "test" software such as ACPI.

I see the "test" kernels claim to have fixed the problem that stopped nVidia chipsets using OS2APIC.PSD so will give that a try in an attempt to more closely identify where the problem occurs and report back in the near future.

Regards

Pete

Pete

Hi

I can now confirm the problem exists when using os2apic.psd instead of acpi.psd

Seems to indicate the problem is in the test kernels.

Regards

Pete

AAA

Next version has arrived.

ftp://Linking to this site is not permitted on our forums/os2krnlSVN1313.zip

rwklein

Quote from: AAA on 2009.05.02, 15:24:58
Next version has arrived.

ftp://Linking to this site is not permitted on our forums/os2krnlSVN1313.zip

The humor in the binary :-)

Copyright 1986,1997 IBM Corp.
Copyright 2008 OS/4 Team.

I wish the eComStation team could do something with the kernel. But its still shady this whole project.
BTW don't be surprised it this kernel hangs when an application has a crash. Because its a patched debug kernel.
Unless they disabled  this code.

On the point of working with Mensys (If this project would be legal). It seems the OS/4 people do try to hide something ?! The interesting thing is that the main IP address of the Mensys ADSL line does not get FTP access to the OS/4 FTP server.
Funny enough when I walk over to a work station that has access to internet via a different ISP with a different IP address it does get access. To make matters even more interesting if you think its an ISP malfunction at home I have the same ADSL ISP as we have in the Mensys office and at home half hour later when I tried the FTP at home it worked :-) Tried the next day again, and presto still blocked. On top of that I know that Eugene Gorbunov also can not access the FTP server...

Weird stuff ?

Roderick Klein
Mensys

lewhoo

Well, from this forum, it seemed that the situation was tense on both sides - Mensys and OS/4 team. Not getting into who is responsible for what... it's obvious that the whole OS/2 community would benifit from this kernel. Thus I hope both sides will somehow manage to cooperate in the future to get it into ecs.

I am sure that Mensys or Serenity has no special interest in blocking this kernel and ment no wrong, and also I am sure that OS/4 team has only good intentions in developing this kernel.

rwklein

Quote from: lewhoo on 2009.05.02, 21:46:03
Well, from this forum, it seemed that the situation was tense on both sides - Mensys and OS/4 team. Not getting into who is responsible for what... it's obvious that the whole OS/2 community would benifit from this kernel. Thus I hope both sides will somehow manage to cooperate in the future to get it into ecs.

I am sure that Mensys or Serenity has no special interest in blocking this kernel and ment no wrong, and also I am sure that OS/4 team has only good intentions in developing this kernel.

To a large extend the kernel is the ticking clockwork for OS/2. However the continued belief that everything has to be fixed inside
the kernel itself is kind of not true. If you take a close look at the old WIN32K.SYS that Knut wrote for the ODIN project! This patches the kernel in memory without distributing a single patched IBM binary code. It modifies the OS2 loader in the kernel that makes OS/2 load an executable. Its true that some patches can not be done in the memory but a lot can be done!

Until that time OS/4 kernel by making a disassembly of the kernel, patching it with such a large collection of and then distributing it with OS/4 copyright its illegal. And Mensys can not work with the team.

Roderick Klein
Mensys

walking_x

#73
From my point of view, Mensys position is clear: "this guys must work for us for free and give us all, what they done" ;) And copyrights only is a good shield for main idea ;)
And as far as i know, no one is specially hide something from Mensys ;) - this effect is result of long term holy war between Eugene Gorbunov and maintainer of Linking to this site is not permitted on our forums ;)

AAA

I agree with lewhoo  - OS/2 community definitely  would benefit from this kernel.
And that is why it is better to support OS/4 Team rather than criticize.

Rwklein, once (#62) I have already asked about your suggestions - how you see it should be - unfortunately, there was no answer.

It looks like you really have something in your mind but you don't want to share it.
Please, advise what is illegal in OS/4 kernel:
- presence of OS/4 copyright
- distribution of patched kernel
- etc.

It's a pity, but from your posts it  is absolutely unclear what you consider illegal. I think OS/4 team will appreciate all your suggestions.

From my point of view, for example, it should not be a big deal for them to remove the copyright string or distribute a not patched kernel but a software to patch the original one.

At the same time I would not want to believe walking_x, who said that Mensys might have some hidden motifs.