From roart at nvg.ntnu.no Sun Mar 8 20:58:10 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Sun, 8 Mar 2015 20:58:10 +0100 Subject: [FreeVMS] New release 0.3.17 Message-ID: <20150308195810.GA19227@sabre-wulf.nvg.ntnu.no> Hi There is a new release 0.3.17. Disk images are available from: http://www.pvv.org/~roart/a.img.gz (Boot floppy) http://www.pvv.org/~roart/c.img.gz (Disk image, 64-bit) http://www.pvv.org/~roart/c.img.32.gz (Disk image, 32-bit) Typically run with qemu-system-x86_64 -fda a.img -hda c.img -boot a -monitor stdio -net none For more about usage, see https://raw.githubusercontent.com/rroart/freevms/master/USE and which user features are tested in https://raw.githubusercontent.com/rroart/freevms/master/TESTING News for 0.3.17: Support for ODS-2 boot partition and use has been reenabled. Support for CMUIP (TCP/IP) has been reenabled. Critical/major bugfixes. Cleanup of dead/unused source code. See https://github.com/rroart/freevms for current source. More info on http://www.pvv.org/~roart/freevms.html -- Regards Roar Thronæs From roart at nvg.ntnu.no Sun Mar 8 22:19:54 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Sun, 8 Mar 2015 22:19:54 +0100 Subject: [FreeVMS] New release 0.3.17 Message-ID: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> Hi There is a new release 0.3.17. Disk images are available from: http://www.pvv.org/~roart/a.img.gz (Boot floppy) http://www.pvv.org/~roart/c.img.gz (Disk image, 64-bit) http://www.pvv.org/~roart/c.img.32.gz (Disk image, 32-bit) Typically run with qemu-system-x86_64 -fda a.img -hda c.img -boot a -monitor stdio -net none For more about usage, see https://raw.githubusercontent.com/rroart/freevms/master/USE and which user features are tested in https://raw.githubusercontent.com/rroart/freevms/master/TESTING News for 0.3.17: Support for ODS-2 boot partition and use has been reenabled. Support for CMUIP (TCP/IP) has been reenabled. Critical/major bugfixes. Cleanup of dead/unused source code. See https://github.com/rroart/freevms for current source. More info on http://www.pvv.org/~roart/freevms.html -- Regards Roar Thronæs (Retrying, had some linebreak/spacing problems) From Angel.Rosario at rtm-it.com Sun Mar 8 23:05:03 2015 From: Angel.Rosario at rtm-it.com (Angel Rosario (rtm)) Date: Sun, 8 Mar 2015 18:05:03 -0400 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> Message-ID: <00ca01d059eb$ef2413d0$cd6c3b70$@RTM-it.com> Thanks. Excellent work! I'm an oldie and OpenVMS passionate. Will do all in my reach to help and push this project out. Cheers! __________________________________________________________________________________________ Angel Rosario-Sierra Business Critical Solutions Architect * Cel: 787-548-0915, * T&F: 787-707-0869 B5 CALLE TABONUCO SUITE 216, PMB 101 GUAYNABO, PR 00968-3029 TEL/FAX: 787-707-0869 E-Mail: Angel.Rosario at RTM-IT.com, Web: www.RTM-IT.com The only organization in Puerto Rico dedicated to OpenVMS. Sales, Consulting, Virtual Alpha Server, Migration, Porting… OpenVMS for EVER!! P Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos..."Before you print this E-mail,ask if it's really necessary. Our environment concerns us all"… “Truth is what stands the test of experience.” - Albert Einstein _________________________________________________________________________________________ This communication is intended only for the use of the individual or entity named as the addressee. It may contain information which is privileged and/or confidential under applicable law. If you are not the intended recipient or such recipient's employee or agent, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. Confidentiality violations will be punished to the fullest extent of the applicable law. If you have received this communication in error, please immediately notify us at (787) 707-0869 or fax (787) 707-0869 or via return Internet electronic mailto: Info at RTM-it.com. _________________________________________________________________________________________ Hi There is a new release 0.3.17. Disk images are available from: http://www.pvv.org/~roart/a.img.gz (Boot floppy) http://www.pvv.org/~roart/c.img.gz (Disk image, 64-bit) http://www.pvv.org/~roart/c.img.32.gz (Disk image, 32-bit) Typically run with qemu-system-x86_64 -fda a.img -hda c.img -boot a -monitor stdio -net none For more about usage, see https://raw.githubusercontent.com/rroart/freevms/master/USE and which user features are tested in https://raw.githubusercontent.com/rroart/freevms/master/TESTING News for 0.3.17: Support for ODS-2 boot partition and use has been reenabled. Support for CMUIP (TCP/IP) has been reenabled. Critical/major bugfixes. Cleanup of dead/unused source code. See https://github.com/rroart/freevms for current source. More info on http://www.pvv.org/~roart/freevms.html -- Regards Roar Thronæs (Retrying, had some linebreak/spacing problems) _______________________________________________ FreeVMS mailing list FreeVMS at rayleigh.systella.fr https://www.systella.fr/cgi-bin/mailman/listinfo/freevms --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1617 bytes Desc: not available URL: From guidoj2269 at gmail.com Tue Mar 10 09:02:32 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 10 Mar 2015 09:02:32 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> Message-ID: <54FEA518.8090207@gmail.com> Hi, I can not build freevms 0.3.17 from the sources from github. I created a virtual machine with Debian Linux from scratch and installed all the required packages listed in the HOWTO. It fails when running the ./envscript. The errors I found so far: - myprescript contains a line for an invalid arch "um" - Makefile.kernel contains an invalid "-I" in the FINDHPATH and errors in the dep-files target - The file modversions.h is in the linux/include/config, but should be in linux/include/linux, possibly due to an invalid update-modverfile target in Makefile.kernel - The linux/include/asm-i386/spinlock.h contains in invalid redefinition of printk() Of course I might be missing something or doing things wrong ... Regards, Guido On 03/08/2015 10:19 PM, Roar Thronæs wrote: > Hi > > There is a new release 0.3.17. > > Disk images are available from: > > http://www.pvv.org/~roart/a.img.gz (Boot floppy) > http://www.pvv.org/~roart/c.img.gz (Disk image, 64-bit) > http://www.pvv.org/~roart/c.img.32.gz (Disk image, 32-bit) > > Typically run with > qemu-system-x86_64 -fda a.img -hda c.img -boot a -monitor stdio -net none > > For more about usage, see > https://raw.githubusercontent.com/rroart/freevms/master/USE > > and which user features are tested in > https://raw.githubusercontent.com/rroart/freevms/master/TESTING > > News for 0.3.17: > Support for ODS-2 boot partition and use has been reenabled. > Support for CMUIP (TCP/IP) has been reenabled. > Critical/major bugfixes. > Cleanup of dead/unused source code. > > See https://github.com/rroart/freevms for current source. > > More info on http://www.pvv.org/~roart/freevms.html > > -- > Regards > Roar Thronæs > > (Retrying, had some linebreak/spacing problems) > _______________________________________________ > FreeVMS mailing list > FreeVMS at rayleigh.systella.fr > https://www.systella.fr/cgi-bin/mailman/listinfo/freevms From roart at nvg.ntnu.no Tue Mar 10 18:36:54 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 10 Mar 2015 18:36:54 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <54FEA518.8090207@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> Message-ID: <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 10, 2015 at 09:02:32AM +0100, Guido wrote: > > I can not build freevms 0.3.17 from the sources from github. I created a > virtual machine with Debian Linux from scratch and installed all the > required packages listed in the HOWTO. It fails when running the > ./envscript. Oops, embarrassing. Sorry, but did not do a complete rebuild after some Makefile changes. You may try to do a git pull now. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 10 18:36:54 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 10 Mar 2015 18:36:54 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <54FEA518.8090207@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> Message-ID: <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 10, 2015 at 09:02:32AM +0100, Guido wrote: > > I can not build freevms 0.3.17 from the sources from github. I created a > virtual machine with Debian Linux from scratch and installed all the > required packages listed in the HOWTO. It fails when running the > ./envscript. Oops, embarrassing. Sorry, but did not do a complete rebuild after some Makefile changes. You may try to do a git pull now. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Tue Mar 10 22:36:42 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 10 Mar 2015 22:36:42 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> Message-ID: <54FF63EA.7010804@gmail.com> On 03/10/2015 06:36 PM, Roar Thronæs wrote: > On Tue, Mar 10, 2015 at 09:02:32AM +0100, Guido wrote: >> I can not build freevms 0.3.17 from the sources from github. I created a >> virtual machine with Debian Linux from scratch and installed all the >> required packages listed in the HOWTO. It fails when running the >> ./envscript. > Oops, embarrassing. > Sorry, but did not do a complete rebuild after some Makefile changes. > You may try to do a git pull now. > Better, still having the incompatible printk() declarations: extern in asm/spinlock.h and asmlinkage in linux/kernel.h and also in linux/printk.c, so I assume the asm/spinlock.h version is wrong. It would be better if it's declared only once, just to prevent these kind of compiler errors (maybe just #include in asm/spinlock.h?). Guido From guidoj2269 at gmail.com Tue Mar 10 22:47:00 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 10 Mar 2015 22:47:00 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <54FF63EA.7010804@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> Message-ID: <54FF6654.1070209@gmail.com> On 03/10/2015 10:36 PM, Guido wrote: > On 03/10/2015 06:36 PM, Roar Thronæs wrote: >> On Tue, Mar 10, 2015 at 09:02:32AM +0100, Guido wrote: >>> I can not build freevms 0.3.17 from the sources from github. I >>> created a >>> virtual machine with Debian Linux from scratch and installed all the >>> required packages listed in the HOWTO. It fails when running the >>> ./envscript. >> Oops, embarrassing. >> Sorry, but did not do a complete rebuild after some Makefile changes. >> You may try to do a git pull now. >> > Better, still having the incompatible printk() declarations: extern in > asm/spinlock.h and asmlinkage in linux/kernel.h and also in > linux/printk.c, so I assume the asm/spinlock.h version is wrong. It > would be better if it's declared only once, just to prevent these kind > of compiler errors (maybe just #include in > asm/spinlock.h?). > > Guido > Same problem for do_exit() ... From roart at nvg.ntnu.no Wed Mar 11 09:39:35 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 09:39:35 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <54FF63EA.7010804@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> Message-ID: <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 10, 2015 at 10:36:42PM +0100, Guido wrote: > > Better, still having the incompatible printk() declarations: extern in > asm/spinlock.h and asmlinkage in linux/kernel.h and also in > linux/printk.c, so I assume the asm/spinlock.h version is wrong. It > would be better if it's declared only once, just to prevent these kind > of compiler errors (maybe just #include in > asm/spinlock.h?). The asm/spinlock.h files haven't been changed since the inclusion here. It's not compiler errors, they are warnings, and FreeVMS is built and works with pretty strict compiler settings. I prioritize critical/major errors until Debian 8 is out, and I have barely started on a possibly timeconsuming double/triplefault issue. If anyone else wants to have a look at these warnings, feel free to do it. Thanks for the input and feedback. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 11 09:39:35 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 09:39:35 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <54FF63EA.7010804@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> Message-ID: <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 10, 2015 at 10:36:42PM +0100, Guido wrote: > > Better, still having the incompatible printk() declarations: extern in > asm/spinlock.h and asmlinkage in linux/kernel.h and also in > linux/printk.c, so I assume the asm/spinlock.h version is wrong. It > would be better if it's declared only once, just to prevent these kind > of compiler errors (maybe just #include in > asm/spinlock.h?). The asm/spinlock.h files haven't been changed since the inclusion here. It's not compiler errors, they are warnings, and FreeVMS is built and works with pretty strict compiler settings. I prioritize critical/major errors until Debian 8 is out, and I have barely started on a possibly timeconsuming double/triplefault issue. If anyone else wants to have a look at these warnings, feel free to do it. Thanks for the input and feedback. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 11 10:38:47 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 10:38:47 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55000D27.9050201@gmail.com> "conflicting types" is definitely a compiler error On 03/11/2015 09:39 AM, Roar Thronæs wrote: > On Tue, Mar 10, 2015 at 10:36:42PM +0100, Guido wrote: >> Better, still having the incompatible printk() declarations: extern in >> asm/spinlock.h and asmlinkage in linux/kernel.h and also in >> linux/printk.c, so I assume the asm/spinlock.h version is wrong. It >> would be better if it's declared only once, just to prevent these kind >> of compiler errors (maybe just #include in >> asm/spinlock.h?). > The asm/spinlock.h files haven't been changed since the inclusion here. > It's not compiler errors, they are warnings, and FreeVMS is built and works > with pretty strict compiler settings. > > I prioritize critical/major errors until Debian 8 is out, and I have barely > started on a possibly timeconsuming double/triplefault issue. > > If anyone else wants to have a look at these warnings, feel free to do it. > > Thanks for the input and feedback. > From roart at nvg.ntnu.no Wed Mar 11 11:00:06 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 11:00:06 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55000D27.9050201@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> Message-ID: <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 11, 2015 at 10:38:47AM +0100, Guido wrote: > "conflicting types" is definitely a compiler error I get a handful of these: warning: conflicting types for built-in function execve [enabled by default] And the builds complete. Which Debian version are you using, and which compiler version? -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 11 11:00:06 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 11:00:06 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55000D27.9050201@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> Message-ID: <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 11, 2015 at 10:38:47AM +0100, Guido wrote: > "conflicting types" is definitely a compiler error I get a handful of these: warning: conflicting types for built-in function execve [enabled by default] And the builds complete. Which Debian version are you using, and which compiler version? -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 11 11:42:29 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 11:42:29 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55001C15.9030106@gmail.com> On 03/11/2015 11:00 AM, Roar Thronæs wrote: > On Wed, Mar 11, 2015 at 10:38:47AM +0100, Guido wrote: >> "conflicting types" is definitely a compiler error > I get a handful of these: > warning: conflicting types for built-in function execve [enabled by default] > And the builds complete. > > Which Debian version are you using, and which compiler version? > Debian 7.8.0 stable, gcc 4.7.2, having read the HOWTO I assumed this is what you used for testing too. I created a dedicated virtual machine for this. From guidoj2269 at gmail.com Wed Mar 11 11:49:33 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 11:49:33 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55001DBD.8040706@gmail.com> On 03/11/2015 11:00 AM, Roar Thronæs wrote: > On Wed, Mar 11, 2015 at 10:38:47AM +0100, Guido wrote: >> "conflicting types" is definitely a compiler error > I get a handful of these: > warning: conflicting types for built-in function execve [enabled by default] > And the builds complete. > > Which Debian version are you using, and which compiler version? > Forgot to mention that it's a 32 bit Debain system inside VirtualBox. The only thing I do to reproduce the error is that I remove the freevms386.iomm directory and run ./envscript. Guido From roart at nvg.ntnu.no Wed Mar 11 12:35:13 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 12:35:13 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55001DBD.8040706@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> Message-ID: <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: > Forgot to mention that it's a 32 bit Debain system inside VirtualBox. > The only thing I do to reproduce the error is that I remove the > freevms386.iomm directory and run ./envscript. Now I got it, too, when trying 32-bit Debian 7. The two servers I am using for development are 32-bit Debian 6 and 64-bit Debian 7, and I thought these two combinations were sufficient. (Will update the git and web page for this.) But you may try one of these two. (Not sure when I get the time to fix this compile error, since it also will require a full rebuild of the two other, plus running some of the testing scripts for all three when running FreeVMS.) Sorry for the inconvenience. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 11 12:35:13 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 11 Mar 2015 12:35:13 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55001DBD.8040706@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> Message-ID: <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: > Forgot to mention that it's a 32 bit Debain system inside VirtualBox. > The only thing I do to reproduce the error is that I remove the > freevms386.iomm directory and run ./envscript. Now I got it, too, when trying 32-bit Debian 7. The two servers I am using for development are 32-bit Debian 6 and 64-bit Debian 7, and I thought these two combinations were sufficient. (Will update the git and web page for this.) But you may try one of these two. (Not sure when I get the time to fix this compile error, since it also will require a full rebuild of the two other, plus running some of the testing scripts for all three when running FreeVMS.) Sorry for the inconvenience. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 11 13:28:52 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 13:28:52 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55003504.9010005@gmail.com> On 03/11/2015 12:35 PM, Roar Thronæs wrote: > On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: >> Forgot to mention that it's a 32 bit Debain system inside VirtualBox. >> The only thing I do to reproduce the error is that I remove the >> freevms386.iomm directory and run ./envscript. > Now I got it, too, when trying 32-bit Debian 7. > The two servers I am using for development are 32-bit Debian 6 and > 64-bit Debian 7, and I thought these two combinations were sufficient. > (Will update the git and web page for this.) > > But you may try one of these two. > (Not sure when I get the time to fix this compile error, > since it also will require a full rebuild of the two other, > plus running some of the testing scripts for all three when running FreeVMS.) > > Sorry for the inconvenience. > The fix for spinlock.h is easy enough, just copy the #include's from the x86_64 onto those in the i386 version. You can get rid of the extern printk declaration in both files too, since they are no longer useful. The ./envscript completes now, with some warnings that must be fixed I'm afraid (I guess some missing #include's in linux/fs.h maybe). make bzImage gives conflicting types for do_exit() and lots of warnings too. Guido From guidoj2269 at gmail.com Wed Mar 11 13:38:43 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 13:38:43 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55003504.9010005@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> <55003504.9010005@gmail.com> Message-ID: <55003753.9040601@gmail.com> On 03/11/2015 01:28 PM, Guido wrote: > On 03/11/2015 12:35 PM, Roar Thronæs wrote: >> On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: >>> Forgot to mention that it's a 32 bit Debain system inside VirtualBox. >>> The only thing I do to reproduce the error is that I remove the >>> freevms386.iomm directory and run ./envscript. >> Now I got it, too, when trying 32-bit Debian 7. >> The two servers I am using for development are 32-bit Debian 6 and >> 64-bit Debian 7, and I thought these two combinations were sufficient. >> (Will update the git and web page for this.) >> >> But you may try one of these two. >> (Not sure when I get the time to fix this compile error, >> since it also will require a full rebuild of the two other, >> plus running some of the testing scripts for all three when running >> FreeVMS.) >> >> Sorry for the inconvenience. >> > The fix for spinlock.h is easy enough, just copy the #include's from > the x86_64 onto those in the i386 version. You can get rid of the > extern printk declaration in both files too, since they are no longer > useful. > > The ./envscript completes now, with some warnings that must be fixed > I'm afraid (I guess some missing #include's in linux/fs.h maybe). make > bzImage gives conflicting types for do_exit() and lots of warnings too. > > Guido > Here's the patch -------------- next part -------------- A non-text attachment was scrubbed... Name: spinlock.patch Type: text/x-patch Size: 1078 bytes Desc: not available URL: From guidoj2269 at gmail.com Wed Mar 11 16:20:17 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 11 Mar 2015 16:20:17 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <55003504.9010005@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> <55003504.9010005@gmail.com> Message-ID: <55005D31.4090108@gmail.com> On 03/11/2015 01:28 PM, Guido wrote: > On 03/11/2015 12:35 PM, Roar Thronæs wrote: >> On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: >>> Forgot to mention that it's a 32 bit Debain system inside VirtualBox. >>> The only thing I do to reproduce the error is that I remove the >>> freevms386.iomm directory and run ./envscript. >> Now I got it, too, when trying 32-bit Debian 7. >> The two servers I am using for development are 32-bit Debian 6 and >> 64-bit Debian 7, and I thought these two combinations were sufficient. >> (Will update the git and web page for this.) >> >> But you may try one of these two. >> (Not sure when I get the time to fix this compile error, >> since it also will require a full rebuild of the two other, >> plus running some of the testing scripts for all three when running >> FreeVMS.) >> >> Sorry for the inconvenience. >> > The fix for spinlock.h is easy enough, just copy the #include's from > the x86_64 onto those in the i386 version. You can get rid of the > extern printk declaration in both files too, since they are no longer > useful. > > The ./envscript completes now, with some warnings that must be fixed > I'm afraid (I guess some missing #include's in linux/fs.h maybe). make > bzImage gives conflicting types for do_exit() and lots of warnings too. > > Guido > Most of the warnings I mentioned above can be fixed by adding the appropriate "#include <...def.h>" to certain header files. The ...def.h files from lib/src contain structs that are used as parameters in functions that are declared in the header files that generate the warnings. Guido From guidoj2269 at gmail.com Thu Mar 12 12:26:08 2015 From: guidoj2269 at gmail.com (Guido) Date: Thu, 12 Mar 2015 12:26:08 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> Message-ID: <550177D0.8080209@gmail.com> On 03/11/2015 12:35 PM, Roar Thronæs wrote: > On Wed, Mar 11, 2015 at 11:49:33AM +0100, Guido wrote: >> Forgot to mention that it's a 32 bit Debain system inside VirtualBox. >> The only thing I do to reproduce the error is that I remove the >> freevms386.iomm directory and run ./envscript. > Now I got it, too, when trying 32-bit Debian 7. > The two servers I am using for development are 32-bit Debian 6 and > 64-bit Debian 7, and I thought these two combinations were sufficient. > (Will update the git and web page for this.) > > But you may try one of these two. > (Not sure when I get the time to fix this compile error, > since it also will require a full rebuild of the two other, > plus running some of the testing scripts for all three when running FreeVMS.) > > Sorry for the inconvenience. > I digged around in the code a bit and I found some room for improvement which might also fix build problems, portabilty issues, instability and/or improve maintainability. Most notable: - Circular dependencies - Inconsistent use of fundamental types (preferably avoid fundamental types altogether) - In general, lack of a coding standard (and not enforced) - Little documentation I'm willing to put some effort into this, although my time will be limited to a few hours a week. Please let me know if I can help. Guido From roart at nvg.ntnu.no Thu Mar 12 23:10:10 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Thu, 12 Mar 2015 23:10:10 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <550177D0.8080209@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> <550177D0.8080209@gmail.com> Message-ID: <20150312221010.GG19227@sabre-wulf.nvg.ntnu.no> On Thu, Mar 12, 2015 at 12:26:08PM +0100, Guido wrote: > > I digged around in the code a bit and I found some room for improvement > which might also fix build problems, portabilty issues, instability > and/or improve maintainability. > > Most notable: > - Circular dependencies > - Inconsistent use of fundamental types (preferably avoid fundamental > types altogether) Yes, that is partially due to the code being a merge of very different sources. > - In general, lack of a coding standard (and not enforced) > - Little documentation Yes and no. The VMS Internals books, VMS File System Internals, VAX CPU manual, very old source listings etc are freely available on the net. We'll "only" need to connect/link those parts, and write what is currently different, and about specific x86 support. > I'm willing to put some effort into this, although my time will be > limited to a few hours a week. Please let me know if I can help. Yes, thank you, we'll need as much help as we can get. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Thu Mar 12 23:10:10 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Thu, 12 Mar 2015 23:10:10 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <550177D0.8080209@gmail.com> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> <550177D0.8080209@gmail.com> Message-ID: <20150312221010.GG19227@sabre-wulf.nvg.ntnu.no> On Thu, Mar 12, 2015 at 12:26:08PM +0100, Guido wrote: > > I digged around in the code a bit and I found some room for improvement > which might also fix build problems, portabilty issues, instability > and/or improve maintainability. > > Most notable: > - Circular dependencies > - Inconsistent use of fundamental types (preferably avoid fundamental > types altogether) Yes, that is partially due to the code being a merge of very different sources. > - In general, lack of a coding standard (and not enforced) > - Little documentation Yes and no. The VMS Internals books, VMS File System Internals, VAX CPU manual, very old source listings etc are freely available on the net. We'll "only" need to connect/link those parts, and write what is currently different, and about specific x86 support. > I'm willing to put some effort into this, although my time will be > limited to a few hours a week. Please let me know if I can help. Yes, thank you, we'll need as much help as we can get. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Fri Mar 13 09:33:43 2015 From: guidoj2269 at gmail.com (Guido) Date: Fri, 13 Mar 2015 09:33:43 +0100 Subject: [FreeVMS] New release 0.3.17 In-Reply-To: <20150312221010.GG19227@sabre-wulf.nvg.ntnu.no> References: <20150308211954.GB19227@sabre-wulf.nvg.ntnu.no> <54FEA518.8090207@gmail.com> <20150310173654.GC19227@sabre-wulf.nvg.ntnu.no> <54FF63EA.7010804@gmail.com> <20150311083935.GD19227@sabre-wulf.nvg.ntnu.no> <55000D27.9050201@gmail.com> <20150311100006.GE19227@sabre-wulf.nvg.ntnu.no> <55001DBD.8040706@gmail.com> <20150311113513.GF19227@sabre-wulf.nvg.ntnu.no> <550177D0.8080209@gmail.com> <20150312221010.GG19227@sabre-wulf.nvg.ntnu.no> Message-ID: <5502A0E7.6090202@gmail.com> On 03/12/2015 11:10 PM, Roar Thronæs wrote: > On Thu, Mar 12, 2015 at 12:26:08PM +0100, Guido wrote: >> - In general, lack of a coding standard (and not enforced) >> - Little documentation > Yes and no. > The VMS Internals books, VMS File System Internals, VAX CPU manual, > very old source listings etc are freely available on the net. > We'll "only" need to connect/link those parts, and write what is > currently different, and about specific x86 support. Yes, I'm sorry, I meant documentation about the build system, source tree layout, etc. I have some questions, but I'll post those in a different thread. Because the current code is copied from different places on the net, different coding standards are currently in effect. This really hurts readability and maintainability. I would suggest to agree on a single coding standard and apply it to all of the code, using maybe indent or some similar tool to get the formatting straight, fix all compiler warnings and maybe in the future even introduce a static code analysis tool like splint or the one used on the linux kernel (can't remember the name). >> I'm willing to put some effort into this, although my time will be >> limited to a few hours a week. Please let me know if I can help. > Yes, thank you, we'll need as much help as we can get. I think a good way to get more people to jump on would be to make it easier to find one's way around the already quite large code base. Essentailly the suggestions I made above are intended as steps in that direction. Guido From guidoj2269 at gmail.com Fri Mar 13 12:01:55 2015 From: guidoj2269 at gmail.com (Guido) Date: Fri, 13 Mar 2015 12:01:55 +0100 Subject: [FreeVMS] Build system questions Message-ID: <5502C3A3.1050103@gmail.com> Hi, I have some questions about the current FreeVMS code base/build system: - What is the reason that a symbolic linked copy of the entire source tree is created? At first I thought that maybe this had to do with cross compilation, but the tree is create based on the host build machine hardware (uname -m). It seems unnecessary. - What are the really old Debian packages need for? I also noticed that these packages only seem to be required for x86_64 and not for i386. - Could the source tree easily be resructured? The source tree contains the kernel, libraries and system tools/application that are all put into the main freevms directory. I would like to create seperate directories, say "vmskernel", "vmslibs" and "vmsapps" for instance, and put each in the appropriate subdir. Note that I'd like to immediatly get the dependencies right, so "vmsapps" depends on "vmslibs" and "vmslibs" depend on "vmskernel" but no more. Probably some "common" stuff must be split off too to make that possible. Any suggestions on how to do this easily? Thanks in advance. Regards, Guido From roart at nvg.ntnu.no Fri Mar 13 17:05:06 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Fri, 13 Mar 2015 17:05:06 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <5502C3A3.1050103@gmail.com> References: <5502C3A3.1050103@gmail.com> Message-ID: <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> On Fri, Mar 13, 2015 at 12:01:55PM +0100, Guido wrote: > > - What is the reason that a symbolic linked copy of the entire source > tree is created? > At first I thought that maybe this had to do with cross compilation, but > the tree is create based on the host build machine hardware (uname -m). > It seems unnecessary. To use the same source for many binary builds (useful in a time when disk was more scarce). Cross-compiling is possible, using NFS. Previously, it was also possible to build User Mode Linux on the same PC, but that support is removed. > - What are the really old Debian packages need for? > I also noticed that these packages only seem to be required for x86_64 > and not for i386. Because gs register usage (on at least x86_64) has changed in the libraries used in newer Debian. One of many signs of a need for more native code. > - Could the source tree easily be resructured? > The source tree contains the kernel, libraries and system > tools/application that are all put into the main freevms directory. I > would like to create seperate directories, say "vmskernel", "vmslibs" > and "vmsapps" for instance, and put each in the appropriate subdir. Note > that I'd like to immediatly get the dependencies right, so "vmsapps" > depends on "vmslibs" and "vmslibs" depend on "vmskernel" but no more. > Probably some "common" stuff must be split off too to make that > possible. Any suggestions on how to do this easily? Not easily, changing/improving the paths/build system may take some time, I suspect. There are some specially privileged images that are linked against the kernel routines and data structures. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Fri Mar 13 17:05:06 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Fri, 13 Mar 2015 17:05:06 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <5502C3A3.1050103@gmail.com> References: <5502C3A3.1050103@gmail.com> Message-ID: <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> On Fri, Mar 13, 2015 at 12:01:55PM +0100, Guido wrote: > > - What is the reason that a symbolic linked copy of the entire source > tree is created? > At first I thought that maybe this had to do with cross compilation, but > the tree is create based on the host build machine hardware (uname -m). > It seems unnecessary. To use the same source for many binary builds (useful in a time when disk was more scarce). Cross-compiling is possible, using NFS. Previously, it was also possible to build User Mode Linux on the same PC, but that support is removed. > - What are the really old Debian packages need for? > I also noticed that these packages only seem to be required for x86_64 > and not for i386. Because gs register usage (on at least x86_64) has changed in the libraries used in newer Debian. One of many signs of a need for more native code. > - Could the source tree easily be resructured? > The source tree contains the kernel, libraries and system > tools/application that are all put into the main freevms directory. I > would like to create seperate directories, say "vmskernel", "vmslibs" > and "vmsapps" for instance, and put each in the appropriate subdir. Note > that I'd like to immediatly get the dependencies right, so "vmsapps" > depends on "vmslibs" and "vmslibs" depend on "vmskernel" but no more. > Probably some "common" stuff must be split off too to make that > possible. Any suggestions on how to do this easily? Not easily, changing/improving the paths/build system may take some time, I suspect. There are some specially privileged images that are linked against the kernel routines and data structures. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Fri Mar 13 21:39:37 2015 From: guidoj2269 at gmail.com (Guido) Date: Fri, 13 Mar 2015 21:39:37 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55034B09.2070301@gmail.com> On 03/13/2015 05:05 PM, Roar Thronæs wrote: > To use the same source for many binary builds (useful in a time when > disk was more scarce). Cross-compiling is possible, using NFS. > Previously, it was also possible to build User Mode Linux on the same > PC, but that support is removed. OK, i'd say the sym linking the entire tree can be removed, but it's a low prio task > Because gs register usage (on at least x86_64) has changed in the > libraries used in newer Debian. One of many signs of a need for more > native code. Agreed. Not an easy task though. > Not easily, changing/improving the paths/build system may take some > time, I suspect. There are some specially privileged images that are > linked against the kernel routines and data structures. Too bad, but I was already afraid of that. I still think this would improve things though. Thanks for the answers, I have a few more questions: - How did you create the bootable floppy disk image? I can not seem to be able to build grub. I created hard disk images and I use the floppy image you provided. I was thinking about trying to upgrade grub to a more recent version. And at the same time getting grub to install on the HD image. - How can I run the TEST*.COM scripts? They do not start however I try it, both on the images you provided and those I built myself. It would be nice to have some testcases to make sure I did not brake anything. Guido From roart at nvg.ntnu.no Sat Mar 14 07:36:22 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Sat, 14 Mar 2015 07:36:22 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55034B09.2070301@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> Message-ID: <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> On Fri, Mar 13, 2015 at 09:39:37PM +0100, Guido wrote: > > - How did you create the bootable floppy disk image? > I can not seem to be able to build grub. I created hard disk images and > I use the floppy image you provided. I was thinking about trying to > upgrade grub to a more recent version. And at the same time getting grub > to install on the HD image. With an old Debian not supported anymore, built grub (which won't build on recent Debian) and diskimage/createimage. Did choose not to prioritize grub because I had a working floppy image. I have now updated the HOWTO text slightly. > - How can I run the TEST*.COM scripts? > They do not start however I try it, both on the images you provided and > those I built myself. It would be nice to have some testcases to make > sure I did not brake anything. With @ [vms$common.systest]test1.com etc. Remember the space after @. (And can only run one script after a boot, that is classified as a minor bug, currently.) -- Regards, Roar Thronæs From roart at nvg.ntnu.no Sat Mar 14 07:36:22 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Sat, 14 Mar 2015 07:36:22 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55034B09.2070301@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> Message-ID: <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> On Fri, Mar 13, 2015 at 09:39:37PM +0100, Guido wrote: > > - How did you create the bootable floppy disk image? > I can not seem to be able to build grub. I created hard disk images and > I use the floppy image you provided. I was thinking about trying to > upgrade grub to a more recent version. And at the same time getting grub > to install on the HD image. With an old Debian not supported anymore, built grub (which won't build on recent Debian) and diskimage/createimage. Did choose not to prioritize grub because I had a working floppy image. I have now updated the HOWTO text slightly. > - How can I run the TEST*.COM scripts? > They do not start however I try it, both on the images you provided and > those I built myself. It would be nice to have some testcases to make > sure I did not brake anything. With @ [vms$common.systest]test1.com etc. Remember the space after @. (And can only run one script after a boot, that is classified as a minor bug, currently.) -- Regards, Roar Thronæs From guidoj2269 at gmail.com Mon Mar 16 21:32:04 2015 From: guidoj2269 at gmail.com (Guido) Date: Mon, 16 Mar 2015 21:32:04 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55073DC4.6050602@gmail.com> On 03/14/2015 07:36 AM, Roar Thronæs wrote: > On Fri, Mar 13, 2015 at 09:39:37PM +0100, Guido wrote: > With an old Debian not supported anymore, built grub (which won't > build on recent Debian) and diskimage/createimage. Did choose not to > prioritize grub because I had a working floppy image. I have now > updated the HOWTO text slightly. Ultimately we can use the grub that is installed on the host, but agreed that it is low prio. > With @ [vms$common.systest]test1.com etc. Remember the space after @. > (And can only run one script after a boot, that is classified as a > minor bug, currently.) OK, got it, forgot the space after @. Some more questions: - I found both struct TIME and VMSTIME, they both represent the 8 byte VMS date/time. VMSTIME is redefined in quite a lot of c-files! Can we agree on using just one of these and get rid of the other? - I also noted that some functions are declared and defined in entirely different parts of the source tree. For instance, exe$bintim is declared in lib/src/exe_routines.h but defined in sys/src/syscvrtim.c. What is the rationale behind splitting up lib and sys? Or better, can they be merged together (preferably somewhere inside linux/kernel)? BTW in case you had not noticed, I believe that there needs to be done some janitorial work before I can contribute anything else. Regards, Guido From roart at nvg.ntnu.no Mon Mar 16 22:23:58 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Mon, 16 Mar 2015 22:23:58 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55073DC4.6050602@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> Message-ID: <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > > Ultimately we can use the grub that is installed on the host, but agreed > that it is low prio. My patched grub has ODS-2 support, as you know. > Some more questions: > > - I found both struct TIME and VMSTIME, they both represent the 8 byte > VMS date/time. VMSTIME is redefined in quite a lot of c-files! Can we > agree on using just one of these and get rid of the other? Both variants come from an earlier (Free)VMS project. > - I also noted that some functions are declared and defined in entirely > different parts of the source tree. For instance, exe$bintim is declared > in lib/src/exe_routines.h but defined in sys/src/syscvrtim.c. What is > the rationale behind splitting up lib and sys? Or better, can they be > merged together (preferably somewhere inside linux/kernel)? System headers for both the executive/kernel and user software? VMS itself had things structured that way, between librtl(?)/starlet (sys$starlet_c.tlb) and lib (sys$lib_c.tlb). (Had to google to find those tlbs.) -- Regards, Roar Thronæs From roart at nvg.ntnu.no Mon Mar 16 22:23:58 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Mon, 16 Mar 2015 22:23:58 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55073DC4.6050602@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> Message-ID: <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > > Ultimately we can use the grub that is installed on the host, but agreed > that it is low prio. My patched grub has ODS-2 support, as you know. > Some more questions: > > - I found both struct TIME and VMSTIME, they both represent the 8 byte > VMS date/time. VMSTIME is redefined in quite a lot of c-files! Can we > agree on using just one of these and get rid of the other? Both variants come from an earlier (Free)VMS project. > - I also noted that some functions are declared and defined in entirely > different parts of the source tree. For instance, exe$bintim is declared > in lib/src/exe_routines.h but defined in sys/src/syscvrtim.c. What is > the rationale behind splitting up lib and sys? Or better, can they be > merged together (preferably somewhere inside linux/kernel)? System headers for both the executive/kernel and user software? VMS itself had things structured that way, between librtl(?)/starlet (sys$starlet_c.tlb) and lib (sys$lib_c.tlb). (Had to google to find those tlbs.) -- Regards, Roar Thronæs From guidoj2269 at gmail.com Tue Mar 17 00:25:53 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 17 Mar 2015 00:25:53 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55076681.8000807@gmail.com> On 03/16/2015 10:23 PM, Roar Thronæs wrote: > My patched grub has ODS-2 support, as you know. Of course, do not mind my earlier comment on grub. > Both variants come from an earlier (Free)VMS project Obviously. On VMS the date/time is represented by a QUADWORD, probably best to use something like that here too. > System headers for both the executive/kernel and user software? VMS > itself had things structured that way, between librtl(?)/starlet > (sys$starlet_c.tlb) and lib (sys$lib_c.tlb). (Had to google to find > those tlbs.) I did not mean librtl and starlet, those are user level C libraries. What is currently in the sys and lib subdirs could be sys$lib_c indeed. According to HoffmanLabs sys$lib_c contains system-specific (private) definitions that are undocumented and subject to change. One should not need it for user land applications, that is what librtl and starlet are for. sys$lib_c can be used for device driver development. What is called libc on linux/unix resides somewhere in decc$... (or vaxc$... on really old systems?). Regards, Guido From roart at nvg.ntnu.no Tue Mar 17 07:18:18 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 07:18:18 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55073DC4.6050602@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> Message-ID: <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > > merged together (preferably somewhere inside linux/kernel)? Not there, I guess that path will eventually go away (this is not Linux). -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 07:18:18 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 07:18:18 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55073DC4.6050602@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> Message-ID: <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > > merged together (preferably somewhere inside linux/kernel)? Not there, I guess that path will eventually go away (this is not Linux). -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 08:06:50 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 08:06:50 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55076681.8000807@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> <55076681.8000807@gmail.com> Message-ID: <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 12:25:53AM +0100, Guido wrote: > > >System headers for both the executive/kernel and user software? VMS > >itself had things structured that way, between librtl(?)/starlet > >(sys$starlet_c.tlb) and lib (sys$lib_c.tlb). (Had to google to find > >those tlbs.) > > I did not mean librtl and starlet, those are user level C libraries. > What is currently in the sys and lib subdirs could be sys$lib_c indeed. > According to HoffmanLabs sys$lib_c contains system-specific (private) > definitions that are undocumented and subject to change. One should not Very few headers belong in sys, that is the place for the main kernel. The lib headers are found here: http://starlet.deltatel.ru/sys$common/syslib/SYS$LIB_C.TLB > need it for user land applications, that is what librtl and starlet are > for. sys$lib_c can be used for device driver development. What is called > libc on linux/unix resides somewhere in decc$... (or vaxc$... on really > old systems?). But a lot of special/privileged images use the lib headers. Also a lot of third party software. So the usage of the most relevant ones are known/well documented. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 08:06:50 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 08:06:50 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55076681.8000807@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> <55076681.8000807@gmail.com> Message-ID: <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 12:25:53AM +0100, Guido wrote: > > >System headers for both the executive/kernel and user software? VMS > >itself had things structured that way, between librtl(?)/starlet > >(sys$starlet_c.tlb) and lib (sys$lib_c.tlb). (Had to google to find > >those tlbs.) > > I did not mean librtl and starlet, those are user level C libraries. > What is currently in the sys and lib subdirs could be sys$lib_c indeed. > According to HoffmanLabs sys$lib_c contains system-specific (private) > definitions that are undocumented and subject to change. One should not Very few headers belong in sys, that is the place for the main kernel. The lib headers are found here: http://starlet.deltatel.ru/sys$common/syslib/SYS$LIB_C.TLB > need it for user land applications, that is what librtl and starlet are > for. sys$lib_c can be used for device driver development. What is called > libc on linux/unix resides somewhere in decc$... (or vaxc$... on really > old systems?). But a lot of special/privileged images use the lib headers. Also a lot of third party software. So the usage of the most relevant ones are known/well documented. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Tue Mar 17 20:56:32 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 17 Mar 2015 20:56:32 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> Message-ID: <550886F0.7010800@gmail.com> On 03/17/2015 07:18 AM, Roar Thronæs wrote: > On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: >> merged together (preferably somewhere inside linux/kernel)? > Not there, I guess that path will eventually go away (this is not Linux). > Oh, it would be just a temporary place. But since you bring it up, how did you plan to do that? Renaming the directory (to "system"?) is too easy. I guess the code should evolve from a linux design to a more vms-like design. I must admit that I lack enough detailed knowledge for now. Regards, Guido From guidoj2269 at gmail.com Tue Mar 17 21:36:38 2015 From: guidoj2269 at gmail.com (Guido) Date: Tue, 17 Mar 2015 21:36:38 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> <55076681.8000807@gmail.com> <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55089056.5010603@gmail.com> On 03/17/2015 08:06 AM, Roar Thronæs wrote: > Very few headers belong in sys, that is the place for the main kernel. > The lib headers are found here: > http://starlet.deltatel.ru/sys$common/syslib/SYS$LIB_C.TLB But a lot > of special/privileged images use the lib headers. Also a lot of third > party software. So the usage of the most relevant ones are known/well > documented. OK, two points: 1) Ultimately you would like to evolve/move the code in linux to sys, right? 2) IMO there is no need to let the source tree from which you build the freevms kernel and system libraries have the same layout as the tree with headers and libraries that is used to build special/privileged images when freevms is deployed. So I still think that lib can be placed somewhere inside/below sys. Regards, Guido From roart at nvg.ntnu.no Tue Mar 17 21:36:15 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 21:36:15 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <550886F0.7010800@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> <550886F0.7010800@gmail.com> Message-ID: <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 08:56:32PM +0100, Guido wrote: > On 03/17/2015 07:18 AM, Roar Thronæs wrote: > >On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > >>merged together (preferably somewhere inside linux/kernel)? > >Not there, I guess that path will eventually go away (this is not Linux). > > > Oh, it would be just a temporary place. But since you bring it up, how > did you plan to do that? Renaming the directory (to "system"?) is too > easy. I guess the code should evolve from a linux design to a more > vms-like design. I must admit that I lack enough detailed knowledge for now. I only expect it to go in that direction, since with time less and less are used in those directories. (I doubt I will be the one who does it.) Thanks for the patch/pull request. I will most likely make a new branch with it and/or add your access tomorrow. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 21:36:15 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 21:36:15 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <550886F0.7010800@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> <550886F0.7010800@gmail.com> Message-ID: <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 08:56:32PM +0100, Guido wrote: > On 03/17/2015 07:18 AM, Roar Thronæs wrote: > >On Mon, Mar 16, 2015 at 09:32:04PM +0100, Guido wrote: > >>merged together (preferably somewhere inside linux/kernel)? > >Not there, I guess that path will eventually go away (this is not Linux). > > > Oh, it would be just a temporary place. But since you bring it up, how > did you plan to do that? Renaming the directory (to "system"?) is too > easy. I guess the code should evolve from a linux design to a more > vms-like design. I must admit that I lack enough detailed knowledge for now. I only expect it to go in that direction, since with time less and less are used in those directories. (I doubt I will be the one who does it.) Thanks for the patch/pull request. I will most likely make a new branch with it and/or add your access tomorrow. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 22:11:57 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 22:11:57 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55089056.5010603@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> <55076681.8000807@gmail.com> <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> <55089056.5010603@gmail.com> Message-ID: <20150317211157.GN19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 09:36:38PM +0100, Guido wrote: > > OK, two points: > 1) Ultimately you would like to evolve/move the code in linux to sys, right? Yes, that is the expected. > 2) IMO there is no need to let the source tree from which you build the > freevms kernel and system libraries have the same layout as the tree > with headers and libraries that is used to build special/privileged > images when freevms is deployed. So I still think that lib can be placed > somewhere inside/below sys. The lib directory with headers may be placed inside the sys tree, as long as it is not mixed with any source C or assembly files. But then -I will just be ../../sys/lib something. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Tue Mar 17 22:11:57 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Tue, 17 Mar 2015 22:11:57 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <55089056.5010603@gmail.com> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150316212358.GJ19227@sabre-wulf.nvg.ntnu.no> <55076681.8000807@gmail.com> <20150317070650.GL19227@sabre-wulf.nvg.ntnu.no> <55089056.5010603@gmail.com> Message-ID: <20150317211157.GN19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 09:36:38PM +0100, Guido wrote: > > OK, two points: > 1) Ultimately you would like to evolve/move the code in linux to sys, right? Yes, that is the expected. > 2) IMO there is no need to let the source tree from which you build the > freevms kernel and system libraries have the same layout as the tree > with headers and libraries that is used to build special/privileged > images when freevms is deployed. So I still think that lib can be placed > somewhere inside/below sys. The lib directory with headers may be placed inside the sys tree, as long as it is not mixed with any source C or assembly files. But then -I will just be ../../sys/lib something. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 18 07:46:35 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 18 Mar 2015 07:46:35 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> <550886F0.7010800@gmail.com> <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> Message-ID: <20150318064635.GO19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 09:36:15PM +0100, Roar Thronæs wrote: > > I will most likely make a new branch with it and/or add your access tomorrow. Now made available as branch guido, https://github.com/rroart/freevms/tree/guido -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 18 07:46:35 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 18 Mar 2015 07:46:35 +0100 Subject: [FreeVMS] Build system questions In-Reply-To: <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> References: <5502C3A3.1050103@gmail.com> <20150313160506.GH19227@sabre-wulf.nvg.ntnu.no> <55034B09.2070301@gmail.com> <20150314063622.GI19227@sabre-wulf.nvg.ntnu.no> <55073DC4.6050602@gmail.com> <20150317061818.GK19227@sabre-wulf.nvg.ntnu.no> <550886F0.7010800@gmail.com> <20150317203615.GM19227@sabre-wulf.nvg.ntnu.no> Message-ID: <20150318064635.GO19227@sabre-wulf.nvg.ntnu.no> On Tue, Mar 17, 2015 at 09:36:15PM +0100, Roar Thronæs wrote: > > I will most likely make a new branch with it and/or add your access tomorrow. Now made available as branch guido, https://github.com/rroart/freevms/tree/guido -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 25 07:15:18 2015 From: guidoj2269 at gmail.com (Guido de Jong) Date: Wed, 25 Mar 2015 07:15:18 +0100 Subject: [FreeVMS] More questions In-Reply-To: References: Message-ID: Hi, Some more questions: - I have not tried myself yet, but can debug messages be printed to a serial line so they can be logged by qemu? Or maybe debugging using the serial line is an option? I am looking for an easy way to analyse crashes. - A few source files and several headers within the Linux kernel source tree are not actually used. Would it be OK to remove them? - The Linux kernel configuration system is still used, albeit only half. Is there any reason to keep this in place? - Would cross compiling be a solution to the gs problem? And if so, did you try it? I am aware that a libc port is required, but smaller ones than glibc are available these days and one of them might suffice for now. Thanks in advance. Regards, Guido -------------- next part -------------- An HTML attachment was scrubbed... URL: From roart at nvg.ntnu.no Wed Mar 25 14:52:20 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 14:52:20 +0100 Subject: [FreeVMS] More questions In-Reply-To: References: Message-ID: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 07:15:18AM +0100, Guido de Jong wrote: > > Some more questions: > - I have not tried myself yet, but can debug messages be printed to a > serial line so they can be logged by qemu? Or maybe debugging using the > serial line is an option? I am looking for an easy way to analyse crashes. Maybe you can use a curses display for qemu? I don't think the serial driver is working. > - A few source files and several headers within the Linux kernel source > tree are not actually used. Would it be OK to remove them? Possibly. Which ones are you thinking of? > - The Linux kernel configuration system is still used, albeit only half. Is > there any reason to keep this in place? Make config is not supposed to be used. Everything needed is now set and not supposed to be changed. Have just not given priority to removing that part of make. > - Would cross compiling be a solution to the gs problem? And if so, did you > try it? I am aware that a libc port is required, but smaller ones than > glibc are available these days and one of them might suffice for now. Cross compile from what to what, with which libraries? No, never tried cross compiling, nor other libcs. Another libc with just introduce other untested problems, and other conventions with errno/gs. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 25 14:52:20 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 14:52:20 +0100 Subject: [FreeVMS] More questions In-Reply-To: References: Message-ID: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 07:15:18AM +0100, Guido de Jong wrote: > > Some more questions: > - I have not tried myself yet, but can debug messages be printed to a > serial line so they can be logged by qemu? Or maybe debugging using the > serial line is an option? I am looking for an easy way to analyse crashes. Maybe you can use a curses display for qemu? I don't think the serial driver is working. > - A few source files and several headers within the Linux kernel source > tree are not actually used. Would it be OK to remove them? Possibly. Which ones are you thinking of? > - The Linux kernel configuration system is still used, albeit only half. Is > there any reason to keep this in place? Make config is not supposed to be used. Everything needed is now set and not supposed to be changed. Have just not given priority to removing that part of make. > - Would cross compiling be a solution to the gs problem? And if so, did you > try it? I am aware that a libc port is required, but smaller ones than > glibc are available these days and one of them might suffice for now. Cross compile from what to what, with which libraries? No, never tried cross compiling, nor other libcs. Another libc with just introduce other untested problems, and other conventions with errno/gs. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 25 17:13:42 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 17:13:42 +0100 Subject: [FreeVMS] More questions In-Reply-To: References: Message-ID: <20150325161342.GQ19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 07:15:18AM +0100, Guido de Jong wrote: > > - I have not tried myself yet, but can debug messages be printed to a > serial line so they can be logged by qemu? Or maybe debugging using the > serial line is an option? I am looking for an easy way to analyse crashes. I am currently connecting gdb remotely to qemu. How do you (plan to) debug? -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 25 17:13:42 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 17:13:42 +0100 Subject: [FreeVMS] More questions In-Reply-To: References: Message-ID: <20150325161342.GQ19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 07:15:18AM +0100, Guido de Jong wrote: > > - I have not tried myself yet, but can debug messages be printed to a > serial line so they can be logged by qemu? Or maybe debugging using the > serial line is an option? I am looking for an easy way to analyse crashes. I am currently connecting gdb remotely to qemu. How do you (plan to) debug? -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 25 20:31:55 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 25 Mar 2015 20:31:55 +0100 Subject: [FreeVMS] More questions In-Reply-To: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> References: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55130D2B.7090503@gmail.com> On 03/25/2015 02:52 PM, Roar Thronæs wrote: >> - A few source files and several headers within the Linux kernel source >> tree are not actually used. Would it be OK to remove them? > Possibly. > Which ones are you thinking of? Here are some examples: Some can be deleted without any compile errors: linux/fs/jbd/* (no journaling fs support any time soon) linux/kernel/sched.c (seems to be moved to sys/src) Other require removal of unnecessary Makefile dependencies: linux/partitions/ibm.c (partition layout used on storage devices for IBM mainframes) linux/kernel/pm.c (power management mainly for laptops) Headers that are included, but are really not needed: linux/include/linux/joystick.h (joystick) linux/include/linux/qic117.h (tape device from the 90's) linux/include/linux/ultrasound.h (gravis ultrasound soundcard) There are many more. Some might be useful to keep although not used at present, like things for SMP. >> - The Linux kernel configuration system is still used, albeit only half. Is >> there any reason to keep this in place? > Make config is not supposed to be used. > Everything needed is now set and not supposed to be changed. > Have just not given priority to removing that part of make. OK, could be cleaned up but low prio. >> - Would cross compiling be a solution to the gs problem? And if so, did you >> try it? I am aware that a libc port is required, but smaller ones than >> glibc are available these days and one of them might suffice for now. > Cross compile from what to what, with which libraries? > No, never tried cross compiling, nor other libcs. > Another libc with just introduce other untested problems, and other > conventions with errno/gs. I'm not sure it causes any problems right now, but using the default compiler could introduce difficult to pinpoint issues. Some useful info can be found here: http://wiki.osdev.org/Main_Page Regards, Guido From guidoj2269 at gmail.com Wed Mar 25 20:41:27 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 25 Mar 2015 20:41:27 +0100 Subject: [FreeVMS] More questions In-Reply-To: <20150325161342.GQ19227@sabre-wulf.nvg.ntnu.no> References: <20150325161342.GQ19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55130F67.9090901@gmail.com> On 03/25/2015 05:13 PM, Roar Thronæs wrote: > On Wed, Mar 25, 2015 at 07:15:18AM +0100, Guido de Jong wrote: >> - I have not tried myself yet, but can debug messages be printed to a >> serial line so they can be logged by qemu? Or maybe debugging using the >> serial line is an option? I am looking for an easy way to analyse crashes. > I am currently connecting gdb remotely to qemu. > How do you (plan to) debug? I'm not sure. Debugging a multi threaded application is already tricky at best and sometimes nearly impossible, debugging an OS kernel is probably even worse. But maybe gdb could produce a backtrace of a crash? Using debug printk's is also an option, but you need to rebuild every time you add, remove or change one (rather time consuming) and they will scroll off the screen pretty fast (which is why I was looking for a way to write them to a logfile). Guido From roart at nvg.ntnu.no Wed Mar 25 22:11:40 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 22:11:40 +0100 Subject: [FreeVMS] More questions In-Reply-To: <55130D2B.7090503@gmail.com> References: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> <55130D2B.7090503@gmail.com> Message-ID: <20150325211140.GR19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 08:31:55PM +0100, Guido wrote: > > Here are some examples: > > Some can be deleted without any compile errors: > linux/fs/jbd/* (no journaling fs support any time soon) Yes, these may be considered as dead code. > Headers that are included, but are really not needed: > linux/include/linux/joystick.h (joystick) Yes, I have removed many of these, too, but they are trickier. There is always something in one of them that is used somewhere else. And recompile on all architectures and Debians is needed. > There are many more. Some might be useful to keep although not used at > present, like things for SMP. There is already SMP support (but I have only tested with uniprocessor). Not sure to which extent those SMP header files are or may be used. -- Regards, Roar Thronæs From roart at nvg.ntnu.no Wed Mar 25 22:11:40 2015 From: roart at nvg.ntnu.no (Roar =?iso-8859-1?Q?Thron=C3=A6s?=) Date: Wed, 25 Mar 2015 22:11:40 +0100 Subject: [FreeVMS] More questions In-Reply-To: <55130D2B.7090503@gmail.com> References: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> <55130D2B.7090503@gmail.com> Message-ID: <20150325211140.GR19227@sabre-wulf.nvg.ntnu.no> On Wed, Mar 25, 2015 at 08:31:55PM +0100, Guido wrote: > > Here are some examples: > > Some can be deleted without any compile errors: > linux/fs/jbd/* (no journaling fs support any time soon) Yes, these may be considered as dead code. > Headers that are included, but are really not needed: > linux/include/linux/joystick.h (joystick) Yes, I have removed many of these, too, but they are trickier. There is always something in one of them that is used somewhere else. And recompile on all architectures and Debians is needed. > There are many more. Some might be useful to keep although not used at > present, like things for SMP. There is already SMP support (but I have only tested with uniprocessor). Not sure to which extent those SMP header files are or may be used. -- Regards, Roar Thronæs From guidoj2269 at gmail.com Wed Mar 25 22:51:17 2015 From: guidoj2269 at gmail.com (Guido) Date: Wed, 25 Mar 2015 22:51:17 +0100 Subject: [FreeVMS] More questions In-Reply-To: <20150325211140.GR19227@sabre-wulf.nvg.ntnu.no> References: <20150325135220.GP19227@sabre-wulf.nvg.ntnu.no> <55130D2B.7090503@gmail.com> <20150325211140.GR19227@sabre-wulf.nvg.ntnu.no> Message-ID: <55132DD5.5060300@gmail.com> On 03/25/2015 10:11 PM, Roar Thronæs wrote: > On Wed, Mar 25, 2015 at 08:31:55PM +0100, Guido wrote: >> Headers that are included, but are really not needed: >> linux/include/linux/joystick.h (joystick) > Yes, I have removed many of these, too, but they are trickier. > There is always something in one of them that is used somewhere else. > And recompile on all architectures and Debians is needed. I ran a simple script that for each header file in ./linux searches if it is included anywhere in the source tree, even if commented out. There are quite a few header files that do not meet these conditions and it seems to me those are no longer needed. Most of them are related to hardware drivers, file systems or network (including firewall) for which the accompanying source files are no longer present. Guido