Mai 2009 - Vax-linux

[LV] Now for some more noise , ok any noise ...
by Mr. James W. Laferriere 04 Sep '09

04 Sep '09

Hello All , My Micro Vax 4000 (QBUS) just arrived in town . So hopefully at least someone (me) will be putting a biot more noise onto the list over the next few months . Before I do tho , Is there any Good or Bad news to share ? Twys , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr(a)baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ _______________________________________________ Linux-Vax mailing list Linux-Vax(a)pergamentum.com http://www.pergamentum.com/mailman/listinfo/linux-vax

7 41

[LV] Kernel Hacker's Meeting in Essen (Germany)
by Jan-Benedict Glaw 18 Mai '09

18 Mai '09

Hi! I'd like to announce it again. There's been the Kernel Hacker's Meeting, which grew from the M68K Hacker's Meeting. Former meetings are documented at http://meeting.ffis.de/devel.html . If you'd like to join, please drop me a line. It'll take place in Essen (Germany), at the Linuxhotel (Villa Vogelsang), Antonienallee 1, from April 30th to May 4th. http://www.openstreetmap.org/?lat=51.430664&lon=7.112265&zoom=18&layers=B00… http://maps.google.de/maps?ll=51.430593,7.112121&z=19 MfG, JBG -- Jan-Benedict Glaw jbglaw(a)lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, träume ich. the second : _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

3 4

[LV] [PATCH] Define "struct stat" and "struct stat64" reasonably
by Maciej W. Rozycki 18 Mai '09

18 Mai '09

Our "struct stat" and "struct stat64" definitions make them less then useful for actual use as some of the fields are narrower than the types used by the kernel to hold the respective data entities internally. Take the opportunity from our port being immature (despite the age :( ) and define them in a way userland expects them to look like. This way no overhead from on-the-fly conversion between the kernel and the user format is incurred in the C library as is the case for most other platforms. The structures have been laid out such as to avoid unnecessary padding due to misalignment. Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> --- A news entry on our page states there was a problem with uClibc and stat() -- there's no mention as to whether it has been rectified or not; given the state of the structures, probably not. This patch constitutes a user-visible ABI change, but I think is worth doing rather than trying to keep the breakage working somehow and introducing new syscalls operating on the data in the correct way. Of course uClibc would have to be adjusted if anybody cared. If anybody thinks the breakage of the ABI would be a real problem, then please speak out and I can think about a possible solution, but even then my sugestion would simply be to retire the old syscall numbers without providing compatible handlers. Otherwise, please apply. Maciej patch-mips-2.6.25-20080422-vax-stat-0 diff -up --recursive --new-file linux-mips-2.6.25-20080422.macro/include/asm-vax/stat.h linux-mips-2.6.25-20080422/include/asm-vax/stat.h --- linux-mips-2.6.25-20080422.macro/include/asm-vax/stat.h 2008-05-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.25-20080422/include/asm-vax/stat.h 2009-05-05 19:08:20.000000000 +0000 @@ -1,79 +1,44 @@ #ifndef _VAX_STAT_H #define _VAX_STAT_H -/* lifted from i386 port */ - -struct __old_kernel_stat { - unsigned short st_dev; - unsigned short st_ino; - unsigned short st_mode; - unsigned short st_nlink; - unsigned short st_uid; - unsigned short st_gid; - unsigned short st_rdev; - unsigned long st_size; - unsigned long st_atime; - unsigned long st_mtime; - unsigned long st_ctime; -}; - +/* This matches struct stat in glibc 2.4. */ struct stat { - unsigned short st_dev; - unsigned short __pad1; - unsigned long st_ino; - unsigned short st_mode; - unsigned short st_nlink; - unsigned short st_uid; - unsigned short st_gid; - unsigned short st_rdev; - unsigned short __pad2; - unsigned long st_size; - unsigned long st_blksize; - unsigned long st_blocks; - unsigned long st_atime; - unsigned long st_atime_nsec; - unsigned long st_mtime; - unsigned long st_mtime_nsec; - unsigned long st_ctime; - unsigned long st_ctime_nsec; - unsigned long __unused4; - unsigned long __unused5; + unsigned long long st_dev; + unsigned long st_ino; + unsigned int st_mode; + unsigned int st_nlink; + unsigned int st_uid; + unsigned int st_gid; + long st_size; + unsigned long long st_rdev; + long st_blocks; + long st_blksize; + long st_atime; + long st_atime_nsec; + long st_mtime; + long st_mtime_nsec; + long st_ctime; + long st_ctime_nsec; }; -/* This matches struct stat64 in glibc2.1, hence the absolutely - * insane amounts of padding around dev_t's. - */ +/* This matches struct stat64 in glibc 2.4. */ struct stat64 { - unsigned short st_dev; - unsigned char __pad0[6]; - - unsigned long long st_ino; - unsigned int st_mode; - unsigned int st_nlink; - - unsigned long st_uid; - unsigned long st_gid; - - unsigned short st_rdev; - unsigned char __pad3[10]; - - long long st_size; - unsigned long st_blksize; - - unsigned long st_blocks; /* Number 512-byte blocks allocated. */ - unsigned long __pad4; /* future possible st_blocks high bits */ - - unsigned long st_atime; - unsigned long st_atime_nsec; - - unsigned long st_mtime; - unsigned long st_mtime_nsec; - - unsigned long st_ctime; - unsigned long st_ctime_nsec; - - unsigned long __unused1; - unsigned long __unused2; + unsigned long long st_dev; + unsigned long long st_ino; + unsigned int st_mode; + unsigned int st_nlink; + unsigned int st_uid; + unsigned int st_gid; + long long st_size; + unsigned long long st_rdev; + long long st_blocks; + long st_blksize; + long st_atime; + long st_atime_nsec; + long st_mtime; + long st_mtime_nsec; + long st_ctime; + long st_ctime_nsec; }; #endif /* _VAX_STAT_H */ _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0

[LV] [PATCH] Fix the entry mask of __copy_tofrom_user()
by Maciej W. Rozycki 18 Mai '09

18 Mai '09

The entry mask of __copy_tofrom_user() is wrong -- temporary registers need no saving normally and we do not call this function from any special context to make it any different in this respect. Thanks, Jan-Benedict, for catching this one! Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> --- Please apply. Eventually our implementation of the ENTRY() macro should mimic what the userland variation does, that is accept the mask as its second argument. But that should be done as a separate patch with no semantic changes. Maciej patch-mips-2.6.25-20080422-vax-copy-user-mask-2 diff -up --recursive --new-file linux-mips-2.6.25-20080422.macro/arch/vax/lib/copy_tofrom_user.S linux-mips-2.6.25-20080422/arch/vax/lib/copy_tofrom_user.S --- linux-mips-2.6.25-20080422.macro/arch/vax/lib/copy_tofrom_user.S 2008-05-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.25-20080422/arch/vax/lib/copy_tofrom_user.S 2009-05-01 23:21:09.000000000 +0000 @@ -19,7 +19,7 @@ .text ENTRY(__copy_tofrom_user) - .word 0x3e + .word 0x0000 movl 4(%ap), %r2 /* to in r2 */ movl 8(%ap), %r3 /* from in r3 */ movl 12(%ap), %r0 /* size in r0 */ _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0

[LV] [PATCH] Fix __copy_tofrom_user() copying zero bytes
by Maciej W. Rozycki 18 Mai '09

18 Mai '09

Fix the case of requesting zero bytes to be copied by __copy_tofrom_user(). Such invocations happen for example with certain patterns of accesses with scatter-gather I/O syscalls. Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> --- Please apply. Maciej patch-mips-2.6.25-20080422-vax-copy-user-zero-2 diff -up --recursive --new-file linux-mips-2.6.25-20080422.macro/arch/vax/lib/copy_tofrom_user.S linux-mips-2.6.25-20080422/arch/vax/lib/copy_tofrom_user.S --- linux-mips-2.6.25-20080422.macro/arch/vax/lib/copy_tofrom_user.S 2008-05-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.25-20080422/arch/vax/lib/copy_tofrom_user.S 2009-05-01 23:21:09.000000000 +0000 @@ -23,10 +23,12 @@ movl 4(%ap), %r2 /* to in r2 */ movl 8(%ap), %r3 /* from in r3 */ movl 12(%ap), %r0 /* size in r0 */ + beqlu 2f 1: EX(movb, (%r3)+, %r4, l_fixup) EX(movb, %r4, (%r2)+, s_fixup) sobgtr %r0, 1b +2: ret .section .fixup,"ax" .align 4 _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0

[LV] [PATCH] Permit 2- and 3-argument calls to open(2)
by Maciej W. Rozycki 18 Mai '09

18 Mai '09

All the other Linux platforms as well traditional *nix systems define the open(2) syscall as accepting either two or three arguments as needed. Make the debug argument-count verification code accept the syscall with either count as a special case. Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> --- Please apply. Maciej patch-mips-2.6.25-20080422-vax-open2-2 diff -up --recursive --new-file linux-mips-2.6.25-20080422.macro/arch/vax/kernel/syscall.c linux-mips-2.6.25-20080422/arch/vax/kernel/syscall.c --- linux-mips-2.6.25-20080422.macro/arch/vax/kernel/syscall.c 2008-05-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.25-20080422/arch/vax/kernel/syscall.c 2009-05-01 17:15:30.000000000 +0000 @@ -59,7 +59,7 @@ extern asmlinkage long sys_rt_sigaction( static struct { unsigned long *sc_func; - unsigned int nr_args; + int nr_args; } syscall[] = { #define SC(num, func, args) \ [num] = { \ @@ -70,7 +70,7 @@ static struct { SC (__NR_fork, sys_fork, 0), SC (__NR_read, sys_read, 3), SC (__NR_write, sys_write, 3), - SC (__NR_open, sys_open, 3), + SC (__NR_open, sys_open, -1), SC (__NR_close, sys_close, 1), SC (__NR_waitpid, sys_waitpid, 3), SC (__NR_creat, sys_creat, 2), @@ -271,7 +271,8 @@ void syscall_handler(struct pt_regs *reg { unsigned int sc_number; unsigned int *user_ap; - unsigned int nr_args; + int sc_args; + int nr_args; sc_number = *(unsigned int *)(excep_info); @@ -331,17 +332,26 @@ void syscall_handler(struct pt_regs *reg /* * Check number of syscall arguments */ - if (unlikely (syscall[sc_number].nr_args != nr_args)) { - printk (KERN_DEBUG "%s(%d): stack mismatch (should=%d, caller=%d) on syscall %d\n", + sc_args = syscall[sc_number].nr_args; + if (unlikely(sc_args != nr_args)) + switch (sc_args) { + case -1: + /* open(2) is special and takes two or three args. */ + if (sc_number == __NR_open && (nr_args & ~1) == 2) + break; + /* Fall through. */ + default: + printk(KERN_DEBUG "%s(%d): stack mismatch " + "(should=%d, caller=%d) on syscall %d\n", current->comm, current->pid, - syscall[sc_number].nr_args, nr_args, sc_number); - printk (KERN_DEBUG "Please report to " + sc_args, nr_args, sc_number); + printk(KERN_DEBUG "Please report to " "<linux-vax(a)pergamentum.com>.\n"); #ifdef CONFIG_DEBUG_VAX_CHECK_CHMx_ARGS_ABORT - regs->r0 = -EFAULT; - return; + regs->r0 = -EFAULT; + return; #endif /* CONFIG_DEBUG_VAX_CHECK_CHMx_ARGS_ABORT */ - } + } #endif /* CONFIG_DEBUG_VAX_CHECK_CHMx_ARGS */ /* _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0

[LV] [PATCH] Interpret the syscall argument count as for CALLS
by Maciej W. Rozycki 18 Mai '09

18 Mai '09

The number of function arguments as pushed on the stack by the CALLS instruction is defined by the architecture to be the least significant byte of the longword pointed to by %AP after the call has been made. Make the syscall argument count be interpreted the same way so that trivial library syscall wrappers may simply execute CHMK reusing the argument area of their callers with no need for the overhead to make a local copy. This also provides for special handling of values outside the defined <255:0> range. Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> --- Please apply. Maciej patch-mips-2.6.25-20080422-vax-scall-args-2 diff -up --recursive --new-file linux-mips-2.6.25-20080422.macro/arch/vax/kernel/syscall.c linux-mips-2.6.25-20080422/arch/vax/kernel/syscall.c --- linux-mips-2.6.25-20080422.macro/arch/vax/kernel/syscall.c 2008-05-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.25-20080422/arch/vax/kernel/syscall.c 2009-05-01 17:15:30.000000000 +0000 @@ -313,6 +313,7 @@ void syscall_handler(struct pt_regs *reg regs->r0 = -EFAULT; return; } + nr_args &= 0xff; /* * The SP value in the pt_regs structure should really @@ -323,7 +324,7 @@ void syscall_handler(struct pt_regs *reg /* * Kernel Mode Syscall Handling - no need to check access to arguments. */ - nr_args = *user_ap; + nr_args = *user_ap & 0xff; } #ifdef CONFIG_DEBUG_VAX_CHECK_CHMx_ARGS _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0

[LV] Initial port of glibc available for VAX/Linux
by Maciej W. Rozycki 17 Mai '09

17 Mai '09

Hello everybody interested! As the outcome of the recent Essen Linux Developers Meeting, following four months of development and followed by two weeks of cleaning up and bug squishing, I am pleased to announce the initial port of the GNU C library, version 2.4, to the VAX/Linux platform. The port comprises the C library itself, the dynamic linker, C run-time startup files as well as system headers, and is accompanied by updates to binutils, version 2.19.1, and GCC, version 4.1.2, required to build the library as well as make use of it. Additionally some changes are required for the Linux kernel. I have made source and binary packages available at my FTP site. The packages have been designed to form a cross-compilation environment, where you can build programs for the VAX/Linux target system using your host system of choice. Mine is i386/Linux and hence the binutils and GCC binary packages are meant for such a system. However the corresponding source packages can be rebuilt on any host system if need be. The C library itself has no host-system dependency of any kind and hence its binary package is compatible with any host system. To get the sources, navigate to: ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/SRPMS/ and download these files: vax-linux-binutils-2.19.1-8.src.rpm vax-linux-boot-gcc-4.1.2-19.src.rpm vax-linux-glibc-2.4-8.src.rpm To get the binaries, navigate to: ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/RPMS/ and download these files: i386/vax-linux-binutils-2.19.1-8.i386.rpm i386/vax-linux-boot-gcc-4.1.2-19.i386.rpm noarch/vax-linux-glibc-debug-2.4-8.noarch.rpm noarch/vax-linux-glibc-devel-2.4-8.noarch.rpm noarch/vax-linux-glibc-profile-2.4-8.noarch.rpm noarch/vax-linux-glibc-static-2.4-8.noarch.rpm I will post changes required for the Linux kernel here shortly. Please note the shared objects from the binary glibc package, that is ld-2.4.so and libc-2.4.so, and their associated symlinks, can be copied and used on the target system. Their usability was verified this way, by building and installing bash, version 3.2. Statically linked bash was tested too. Both ran correctly to the point of accepting user commands and were capable of starting a "Hello World!" program. Some built-in commands were manually tested too. No readline or history library was included in testing, and job control was not tested either (which would be useful to verify signal handling) due to the lack of the controlling terminal. Advance warning: there is an impending temporary closure of the ftp://ftp.linux-mips.org/ site, which is due to relocation. The exact time when it is going to happen is not known yet. I will post details when available. Further development plan (tentative): Here is a brief list of things to do in the coming months. I have tried to put the tasks more or less in the order I envisage they might be done. Some overlap may happen. 1. Porting of the rest of the C library. This includes in particular the maths library (because of the non-IEEE754 FPU VAX provides), the threads (LinuxThreads) library (because of low-level platform dependencies, such as atomic primitives), and all the other libraries and tools included with the distribution. I have already started some work on the maths library and the initial port contains most if not all parts required for LinuxThreads. A full release is expected in several weeks' time. 2. Porting of platform support (run-time and library, as appropriate) for languages other than C provided by GCC; this includes Ada, C++ and Java. 3. Adding support for the VAX/Linux platform to GDB. 4. Implementation of C library functions which due to the lack of platform-specific code for VAX/Linux are provided as non-functional stubs only. 5. Design and implementation of Native POSIX Thread Library (NPTL) support. This mostly comprises the Thread Local Storage (TLS) model and the surrounding infrastructure. All of binutils, GCC and glibc have to be updated simultaneously for TLS to be correctly supported. 6. Adding profiling support to the C library. Although profiling libraries are built as a part of glibc compilation, some essential low-level platform glue code is missing making profiling non-functional. 7. Porting of C library changes to the then current head of glibc and upstream submission of all the changes to glibc as well as NPTL changes for binutils and GCC. 8. Porting of other libraries or programs utilising handwritten assembly code for performance reasons; this includes at least the GNU Multiple Precision (GMP) library. 9. Adding long double support -- based on the H-floating format -- both in GCC and in glibc; an update to binutils may be required too. Right now the type aliases to double. 10. Testing and bug fixing. There is undoubtedly plethora of bugs hidden waiting to bite. This task overlaps all the others of course. I am fairly sure I have missed something to place the list, so I will appreciate any suggestions. FAQ: 1. Q: Version 2.4 of glibc is a very old one. Likewise GCC 4.1.2. What was the reason behind choosing these versions? A: These were the last versions I felt like bringing up to date with LinuxThreads support which was been abandoned upsteram a while ago. The reason to insist on LinuxThreads was the ability to get a fully-working environment without the need to design the NPTL ABI beforehand, which is not straightforward for the VAX processor. This way performance evaluation of different approaches to the NPTL ABI will be possible from a full-featured system. 2. Q: What about upstream submission? Especially given the above. A: Patches for binutils shall be submitted straight away, as soon as validation has passed. Patches for GCC shall follow as they are believed to be compatible with the current trunk. They have been smoke-tested and will only undergo further testing once a full user environment has become available. Patches to glibc will be submitted once they have been forward-ported to then current trunk, which is scheduled to after NPTL support has been completed. Porting effort is expected to be moderate due to the self-containment of most of the patches. 3. Q: What about binary compatibility -- is the ABI defined by this release guaranteed to be stable? A: Unfortunately the answer is no. Some internal details may need further tuning, especially as a result of the NPTL effort. The intent is to get the ABI stabilised by the time patches will be submitted for inclusion with upstream glibc, but let people play with the port immediately so that any problems have a greater chance to be found before submission. 4. Q: Can I help with the port? How? A: Certainly, you are welcome to join the team! If you feel competent or would like to learn about the VAX architecture or the core of GNU software, then please pick a task from the list above and let the list know you would like to get into it, or if you have an idea to work on, then please let people on the list know so that someone does not duplicate your effort, which can be rather frustrating. If you are not that much into the details of the VAX architecture or the pieces of GNU software, but you have VAX hardware and would love to make a good use of it, than please do make use of the tools and the library, by building your favourite pieces of software, using it and reporting any anomalies seen to the list. 5. Q: Is there a wiki available for the port? A: There is none at the moment, although we have a site, at http://linux-vax.sourceforge.net/. It will undoubtedly be useful to have a wiki at one point, preferably hosted at our site. If you can help with arranging that, it will be useful. 6. Q: Is this FAQ complete yet? A: No, of course not! Please provide us with further questions and we will strive to work out answers or alternatively please give us an answer and we will try to find a question to fit. Acknowledgments: 1. Thanks to Jan-Benedict Glaw for his work on the VAX/Linux kernel as well as invaluable insights in the discussion at the Essen meeting about how the dynamic linker should work. 2. Thanks to Martin 'Joey' Schulze for organising the last Essen meeting, as well as all the previous meetings. 3. Thanks to CodeSourcery for keeping me busy outside my free time. 4. Thanks to all the people who have supported me with this effort -- you know who you are! If you have any questions or comments, then please do not hesitate to contact me, cc-ing the list if appropriate. Maciej _______________________________________________ Linux-Vax mailing list Linux-Vax(a)mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax

1 0