BP Dedicated Server
Title: New Page 1 To bug-hurd@gnu.org: We supply BulletProof servers for you: Fresh IPs 512MB RAM P4 CPU 36 GB SCS Dedicated 100 M fiber Unlimited Data Transfer Linux/Windows/FreeBSD Locate in China Price: No setup fee US$ 599.00/MO You can use the servers for any of the following: Direct Mailing or Proxy Mailing Bulk Web Hosting Or customize Dedicated Server: More Information We also can supply Target Email Addresses according to your requirements, and sending out Target Emails for you. Looking forward to do business with you. Mark Server Dept [EMAIL PROTECTED] *** No.Thank: [EMAIL PROTECTED]@gnu.org *** ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Patches to GDB to make cross-compile friendly...
Date: Sat, 26 Feb 2000 03:22:21 -0500 From: Roland McGrath <[EMAIL PROTECTED]> That looks fine, though you should match `*-*-gnu*' for the configuration. Mark Kettenis is in charge of gdb for hurd and will take care of getting the fix put into gdb. It is probably easier to not conditionalize the check for MiG on the host triplet. AC_CHECK_TOOL isn't really expensive. I'll check in the following patch once it is approved. Mark 2000-02-26 Mark Kettenis <[EMAIL PROTECTED]> Make cross-compilation for the Hurd more friendly. From Jeff Bailey <[EMAIL PROTECTED]>: * configure.in: Use AC_CHECK_TOOL to find MiG. * Makefile.in (MIG): New variable. * config/i386/i386gnu.mh (MIG): Remove. * configure: Regenerated. Index: gdb/configure.in === RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.7 diff -u -r1.7 configure.in --- gdb/configure.in2000/02/24 08:16:26 1.7 +++ gdb/configure.in2000/02/26 13:31:55 @@ -77,6 +77,9 @@ AC_CHECK_TOOL(RANLIB, ranlib, :) AC_PROG_YACC +dnl MiG is needed for the Hurd. +AC_CHECK_TOOL(MIG, mig) + AC_ARG_PROGRAM AC_TYPE_SIGNAL Index: gdb/Makefile.in === RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.8 diff -u -r1.8 Makefile.in --- gdb/Makefile.in 2000/02/24 08:16:26 1.8 +++ gdb/Makefile.in 2000/02/26 13:31:57 @@ -59,6 +59,7 @@ RANLIB = @RANLIB@ DLLTOOL = @DLLTOOL@ WINDRES = @WINDRES@ +MIG = @MIG@ # If the user configured GDB to include the TUI, the name of the tui # library goes here. Index: gdb/config/i386/i386gnu.mh === RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mh,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 i386gnu.mh --- gdb/config/i386/i386gnu.mh 1999/04/16 01:34:18 1.1.1.1 +++ gdb/config/i386/i386gnu.mh 2000/02/26 13:31:57 @@ -12,7 +12,6 @@ msg-MIGUFLAGS = -D'MSG_IMPORTS=waittime 1000;' # ick -MIG = mig MIGCOM = $(MIG) -cc cat - /dev/null # Reply servers need special massaging of the code mig generates, to make
Re: Bug#62328: unexpected error in __fork
Date: Thu, 13 Apr 2000 19:03:43 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Package: hurd
Version: N/A
Hi,
I sometimes see this when compiling packages, followed by a crash and
reboot. I can't see the console messages leading to this crash, maybe
someone else or me can follow up later with more information.
perl: ../sysdeps/mach/hurd/fork.c:158: __fork: Nicht erwarteter
Fehler: (ipc/send) invalid destination port.
(Nicht erwarteter Fehler: Unexpected Error).
Time to upgrade your Hurd! We fixed this bug last month :-)
>From proc/ChangeLog:
2000-03-13 Roland McGrath <[EMAIL PROTECTED]>
* mgt.c (S_proc_exception_raise): Check for
MACH_SEND_NOTIFY_IN_PROGRESS rather than MACH_SEND_INVALID_NOTIFY.
Don't deallocate THREAD and TASK ports before the switch, since the
successful case uses THREAD again and the failure case uses TASK
again. Instead, deallocate them at the end of the successful case.
At the end of the error case, use mach_port_destroy on THREAD only.
* stubs.c (struct msg_sig_post_request): New type, broken out of
send_signal, where it was anonymous.
(struct msg_spec): Type removed.
(blocking_message_send): Change type to any_t -> any_t.
Don't call cthread_wire; it's a no-op in GNU anyway.
Just return instead of calling cthread_exit.
Argument is now a pointer to struct msg_sig_post_request.
Check mach_msg return value for sanity assert.
(send_signal): Make MESSAGE auto instead of static, use new type name.
This problem tracked down by Mark Kettenis <[EMAIL PROTECTED]>.
Mark
Re: write support without inodes
Date: Sun, 7 May 2000 22:27:17 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> Hi, as you may know, there are no inodes in the FATFS, all information being stored directly in the directory entry. Do I need some lock on the directory node when updating the node information? Do you have any other tips for this situation, things to watch out for, or strategies how to get the location of the directory entry (seems I need a lookup at update time, because the address is not robust under rename operations (moving the file to a different directory). Not really, but maybe you could get some idea's from looking at Linux or one of the BSD's. Mark
Re: MIG -> CORBA
Date: Tue, 9 May 2000 23:28:58 +0200 From: "Martin v. Loewis" <[EMAIL PROTECTED]> [ This is not really directed to you Martin, but the last line of this message just provided a convenient point to jump in the discussion. ] > > No, it isn't. Its license is more liberal than the GPL. > That's right. But It seems as a completely new environment for me and > it has less conformance even that ORBit. I won't argue about the "new environment" part. On the "less conformance" part, can you give me a feature that is implemented conformingly in ORBit, but not in ILU? Not that this has to do anything with the Hurd... Indeed. I don't really have experience with CORBA, but I don't think the issues in this thread are relevant in this stage of Hurd development. Right now the core Hurd protocols are defined by the MiG .defs files. At one side this defines the C ABI, at the other side this defines the layout of messages and conventions on how to handle the data contained in them for use with Mach IPC. None of these can be easily changes without rewriting most of the Hurd. I also fail to see why we need an ORB. The Mach kernel handles most of the things the ORB usually does. Now MiG has some drawbacks, and therefore, one day, we'll want to switch to a more sane IDL. That's why there is some blurb in the task list. It would make sense to choose an IDL that's already widely used, such as the CORBA IDL. Especially since one day we might want to run the Hurd on other microkernels besides Mach. We might need some sort of an ORB too, but this should probably be tightly integrated with the underlying microkernel. Feel free to talk about this stuff if you want. Just don't expect any of the core Hurd developers to take part in it. That might be a good reason to take it off the bug-hurd mailing list. Mark
Re: MIG -> CORBA
Date: Tue, 09 May 2000 13:09:59 -0400 From: Serguei Izvoztchikov <[EMAIL PROTECTED]> Jeff Bailey wrote: > I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have > declined to add wrappers within their header files to permit linking from > C++ programs, so I don't think they're going to change. What is the reason ? C is the one-and-only language all respectable system programmers understand. The Hurd uses a dialect called "GNU C" since it has some nice features that we just need to have. Other dialects that retroactively change the rules (like added new reserved words) are just not worth supporting. Mark
Re: MIG -> CORBA
Date: Tue, 9 May 2000 22:55:21 +0500 (GMT-5) From: Sergey Izvoztchikov <[EMAIL PROTECTED]> On Wed, 10 May 2000, Mark Kettenis wrote: > Indeed. I don't really have experience with CORBA, but I don't think > the issues in this thread are relevant in this stage of Hurd > development. Right now the core Hurd protocols are defined by the MiG > .defs files. At one side this defines the C ABI, at the other side > this defines the layout of messages and conventions on how to handle > the data contained in them for use with Mach IPC. None of these can > be easily changes without rewriting most of the Hurd. First thought was that Hurd should have its ORB to be treated an Enterprise level OS. I heard about possibility of inter-computer communications using Mach messages, but I suspect it doesn't function in Hurd now. I started with studying Flick from FLUX which theoretically allows to generate Mach3 IPC from CORBA IDLs. And I think that using CORBA allows mush more people start writing new servers and porting existing software to Hurd. It's just more convenient way for programmers who already knows CORBA. Well, if all you're interested in is porting an existing CORBA implementation (like ORBit) to the Hurd, you'd be more than welcome. However, take a look at the Debian/Hurd project first. It might already have been done :-). If you think it is possible to make things more efficient by doing the actual data transfer directly via Mach IPC, that might indeed be something worth exploring. However, *replacing* MiG with CORBA doesn't make sense right now. The only thing we use MiG for in the Hurd is in the core interfaces. Feel free to ask any *technical* questions on porting CORBA to the Hurd on bug-hurd. Packaging issues are probably best discussed on debian-hurd. Mark
Re: Bug#63723: hurd: suspicious code in ext2fs/pager.c
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Date: 10 May 2000 10:03:52 +0300 According to the glibc manual, the result of setjmp must not be assigned like diskfs_catch_exception does: it must be either immediately used in a do/while/for/if/switch statement or ignored. Has GCC relaxed this restriction? It looks to me that there is no problem with assigning the result of setjmp for the Hurd. Since setjmp() is just a macro that calls __sigsetjmp(), we're simply assigning the return value of a function. Since that return value is guaranteed to be in the %eax register, regardless of whether that return was the result of a non-local goto or not, doesn't matter. Of course this isn't portable. There may be implementations that put additional restrictions on the use of setjmp(). ISO C allows setjmp() to be implemented as a macro, which means that the argument above doesn't have to apply. That's probably why the manual mentions those restrictions. However, for the Hurd servers themselves, it is not too bad to make some additional assumptions about implementation details if that is convenient or improves performance. Mark
Re: CVS version doesn't boot for me
Date: Sun, 14 May 2000 02:52:49 -0400 (EDT) From: Roland McGrath <[EMAIL PROTECTED]> > On Sat, Apr 22, 2000 at 02:20:30AM +0200, Marcus Brinkmann wrote: > > > > I have troble with current CVS version, cross compiled with gcc > > 2.95.2 and glibc 2.1.3 (as of 2000/02/24). When booting, I get: The changes I made related to versioning went into glibc (2.2) on 2000-03-30 or thereabouts and into hurd/libthreads at about the same time. It is not too surprising to have a problem with an old glibc and a new hurd. I am not able to do any real hacking or even much code-reading these days (it will be probably at least several more weeks before I can), and I don't recall the full details of all this off hand. I don't think there should be a problem like this, but I don't have enough information on hand right now to be of much more help. Mark understands the details too and might be able to help before I can. There is indeed a versioning problem. The following symbols exist both in libc and libthreads: __mutex_lock_solid, __mutex_unlock_solid, _cthread_exit_routine, _cthread_init_routine, cthread_keycreate, cthread_getspecific, cthread_setspecific; The symbols in libc are supposed to overridden by the symbols in libthread. Before Roland's change, the symbols in libc were're bound to version GLIBC_2.0, and the symbols in libthreads were unversioned, and apparently this worked fine. However, now the symbols in libthreads are versioned, and bound to a *different* version HURD_CTHREADS_0.3. So the symbols in libthread no longer override those in libc. This means that the cthreads library isn't initialized so it isn't surprising that the exec server crashes in the boot process. I think Roland's nifty versioning plan can only be implemented if we use different versions for a libio-ified Hurd than for a stdio-using Hurd. In that case I think it is reasonable to keep libthreads unversioned with stdio and only use the version script with libio. If you agree Roland, I'll add the necessary stuff to configure.in and the relevant Makefile. Mark
Re: CVS version doesn't boot for me
Date: Thu, 18 May 2000 23:11:38 -0400 (EDT) From: Roland McGrath <[EMAIL PROTECTED]> I really don't have sources or a build on hand to look at at all these days. But I suspect that it will dtrt for glibc-2.1 compatibility if we make aliases with the GLIBC_2.0 version tag in libthreads.so for the symbols from libc. I'm not sure off hand if we can do this in the version script or if we need to add .symver wierdness when building libthreads. No problem. Your suggestion would indeed work, but we do need ".symver wierdness" for this. However, I really don't see the benefits. It is impossible to use the same libthreads with both a stdio-using libc (either 2.1 or 2.2) and a libio-using libc (2.2 with a different soname). Leaving libthreads for a stdio-based Hurd unversioned and only version the libthreads for a libio-based Hurd is IMHO the simplest and most robust way to solve the problem. Mark
Re: CVS version doesn't boot for me
Date: Fri, 19 May 2000 19:03:38 -0400 (EDT) From: Roland McGrath <[EMAIL PROTECTED]> Yeah, on later thought I liked your idea fine. Here's a patch. OK to check this in? 2000-05-20 Mark Kettenis <[EMAIL PROTECTED]> * configure.in: Add check for libio. Only enable versioning if we found libio. Index: configure.in === RCS file: /home/cvs/hurd/configure.in,v retrieving revision 1.18 diff -u -p -r1.18 configure.in --- configure.in2000/03/27 18:20:47 1.18 +++ configure.in2000/05/20 14:23:12 @@ -93,7 +93,23 @@ else hurd_cv_ld_version_script_option=no fi rm -f conftest*]) -VERSIONING=$hurd_cv_ld_version_script_option + +# See if libc was built with --enable-libio. +AC_CACHE_CHECK([for libio], + hurd_cv_libio, + AC_TRY_COMPILE([#include +#ifndef _STDIO_USES_IOSTREAM +# error No libio found. +#endif],, +hurd_cv_libio=yes, +hurd_cv_libio=no)) + +# Only turn on versioning if we found libio and versioning is supported. +if test $hurd_cv_libio = yes; then + VERSIONING=$hurd_cv_ld_version_script_option +else + VERSIONING=no +fi AC_SUBST(VERSIONING)
Re: CVS version doesn't boot for me
Date: Sun, 14 May 2000 02:52:49 -0400 (EDT) From: Roland McGrath <[EMAIL PROTECTED]> The changes I made related to versioning went into glibc (2.2) on 2000-03-30 or thereabouts and into hurd/libthreads at about the same time. It is not too surprising to have a problem with an old glibc and a new hurd. I am not able to do any real hacking or even much code-reading these days (it will be probably at least several more weeks before I can), and I don't recall the full details of all this off hand. I don't think there should be a problem like this, but I don't have enough information on hand right now to be of much more help. Mark understands the details too and might be able to help before I can. I'll look into it the coming week. Mark
Re: Port to PowerPC
Date: Sat, 8 Jul 00 19:59:25 +0100 From: Peter Bruin <[EMAIL PROTECTED]> Hello, I would like to work on a port of the Hurd to the PowerPC, using OSF Mach. I have already cross-compiled (= hacked) most of the GNU C library and the Hurd; serverboot works (from the MkLinux prompt) until it tries to load ext2fs.static (which I haven't done yet). Does anybody have comments on this, and is there anything I should do before continuing? I did some work on getting the hurd running on OSF Mach on the i386, but more or less abandoned it. I have some stuff for libc still lying around, that I could put up somewhere if you'd like. But if you've indeed already cross-compiled most of libc and the Hurd, its probably not of much use. OSF Mach is a bit different from GNU Mach. The set of RPC's is slightly different and I believe that the OSF MiG is slightly different from the traditional MiG used on GNU Mach. I don't know if you can use the GNU MiG at all (perhaps you can use oit for the Hurd's *.defs files), but if you use the OSF MiG you'll probably need to hack the Hurd *.defs files somewhat. You'll also have to adjust some hand crafted Mach messages that are hidden in the Hurd and libc. If it's of any use, I packaged the OSF MiG some time ago, and modified it in a way such that it is a bit more compatible with the GNU MiG. You can find it at http://www.wins.uva.nl/~kettenis/osfmk. If you have some concrete questions, don't hesitate to ask. I'd love to see the Hurd running alongside with Mac OS X :-). Mark
Re: translators, ext2 and files
Date: Thu, 13 Jul 2000 19:27:55 -0400 From: Olivier Galibert <[EMAIL PROTECTED]> On Fri, Jul 14, 2000 at 01:07:38AM +0200, Marcus Brinkmann wrote: > On Thu, Jul 13, 2000 at 07:01:28PM -0400, Olivier Galibert wrote: > > Currently the on-disk structures for translators in ext2 allow for an > > inode to be both a passive translator and a file (or directory) with > > actual contents. AFAICT, this capability is not used anywhere for > > now. I'm not even sure it is accessible from the filesystem > > interface. > > The underlying node is accessible to the translator, and this can and will > be used for example for filter (or for example for activity logging etc). But only the translator has access to it? That's yucky. This means that things can be hidden behind a translator and the only way for both yourself and the sysadmin to know what's there is to remove it? That's why we have O_NOTRANS, i.e. you can do fd = open (..., O_READ | O_NOTRANS); and use the file descriptor to read from the actual file. It's probably even too magic for the translator itself. This does not work: dd if=/dev/zero of=dummy bs=1024k count=8 mke2fs dummy settrans -c dummy /hurd/ext2fs `pwd`/dummy ...because the translator will end up looping on itself. Did you check that? If it really does that, I'd consider it a bug, and I might try to fix it :-). Anyway, I agree with Marcus that it's useful to have this feature, and it's probably how Thomas designed it. Mark
Re: translators, ext2 and files
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Date: 14 Jul 2000 23:23:31 +0300
Mark Kettenis <[EMAIL PROTECTED]> writes:
>Date: Thu, 13 Jul 2000 19:27:55 -0400
>From: Olivier Galibert <[EMAIL PROTECTED]>
>
>settrans -c dummy /hurd/ext2fs `pwd`/dummy
>
>...because the translator will end up looping on itself.
>
> Did you check that? If it really does that, I'd consider it a bug,
> and I might try to fix it :-).
I think it would be better to reserve "-" for the untranslated
node. (Or is there a place where that would clash with the
std{in,out} meaning?)
I think it's better to reserve "-" for stdin, and not overload it for
this purpose.
How about having a magic translator /dev/underlying to represent the
underlying node of a translator (similar to /dev/tty for the
controlling terminal)?
Mark
Re: debugging the exec server
Date: Wed, 19 Jul 2000 00:14:01 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> Hi Kalle, you asked: > Is it possible to debug the primary exec server with gdb? > Or is it possible to run another exec server and debug that? I have successfully attached gdb to the primary exec server (pid 5), but it is quite unstable, and not recommended. Marcus, Are you aware that you can do $ gdb /hurd/exec ... (gdb) set noninvasive on (gdb) attach 5 ... (gdb) to debug essential system servers? You cannot really control program flow this way, but backtraces should work fine, and you can print variables (and watch them change underneath you). Mark
Re: small note about unexp. error in __fork
Date: Thu, 27 Jul 2000 12:50:22 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> Hi, I just realized that I am suffering this unexpected error in __fork problem only in long (several hours) perl runs. The autobuilder is such a perl program, and it has a lot of system() calls (which is perlish for fork/exec), which themselve can take a long time. That's a bit unfortunate, since it's hard too debug if you got to wait a long time for it to happen. Does your Hurd crash shortly after it happens, or will it keep running? The last time the bug was in the proc server. It was losing point rights when sending signals to a program. You could use GDB on the proc server to see if you can spot any cases where the number of port references is obviously wrong. The `set noninvasive on' and `info port' commands might be useful. Mark
Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken
Date: Sat, 29 Jul 2000 00:27:09 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> The culprit is that fileutils now defines _FILE_OFFSET_BITS 64 on the Hurd, which sucks in functions like readdir64, lseek64 etc Can we easily implement those? Not really. I have to use --disable-largefile on the Hurd, it seems. That would do the trick for now. Funnily, the autoconf check doesn't bother to check if largefiles are really supported. That's broken I think. checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGEFILE_SOURCE value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking for _XOPEN_SOURCE value needed for large files... no Is this a bug in fileutils? No, it's a bug in autoconf. We don't advertise that we support large files on the Hurd. If we did, we would set one of more of the following macros to 1 in : _LFS_LARGEFILE _LFS64_LARGEFILE _LFS64_ASYNCHRONOUS_IO _LFS64_STDIO I think autoconf should at least check for _LFS_LARGEFILE. Mark
Re: oskit-mach trouble
You'll probably need to provide alternatives for more (all) of the functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach synch.c. Mark
Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken
[ Argh... It's [EMAIL PROTECTED] ] Date: Sat, 29 Jul 2000 00:27:09 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> The culprit is that fileutils now defines _FILE_OFFSET_BITS 64 on the Hurd, which sucks in functions like readdir64, lseek64 etc Can we easily implement those? Not really. I have to use --disable-largefile on the Hurd, it seems. That would do the trick for now. Funnily, the autoconf check doesn't bother to check if largefiles are really supported. That's broken I think. checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGEFILE_SOURCE value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking for _XOPEN_SOURCE value needed for large files... no Is this a bug in fileutils? No, it's a bug in autoconf. We don't advertise that we support large files on the Hurd. If we did, we would set one of more of the following macros to 1 in : _LFS_LARGEFILE _LFS64_LARGEFILE _LFS64_ASYNCHRONOUS_IO _LFS64_STDIO I think autoconf should at least check for _LFS_LARGEFILE. Mark
Re: _FILE_OFFSET_BITS 64 not supported (was: Re: WARNING fileutils 4.0x-1 severly broken
Date: Sat, 29 Jul 2000 00:03:06 -0700 (PDT) From: Paul Eggert <[EMAIL PROTECTED]> From: Mark Kettenis <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2000 01:22:03 +0200 Date: Sat, 29 Jul 2000 00:27:09 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> The culprit is that fileutils now defines _FILE_OFFSET_BITS 64 on the Hurd, which sucks in functions like readdir64, lseek64 Sorry, this is the first I've heard of the problem. What does "sucks in functions" mean? Does the program try to link these functions, even though they don't exist? If so, "configure" could catch that problem by trying to linking a program that sets _FILE_OFFSET_BITS to 64 and invokes lseek; if the link doesn't work, then "configure" could avoid setting _FILE_OFFSET_BITS to 64. The Hurd uses the GNU C Library, and basically the same header files as on Linux (only the `bits' differ). This means that setting _FILE_OFFSET_BITS has basically the same effect on Linux, except that some of the *64() calls are implemented as stubs returning ENOSYS. To assist autoconf, defines: #define __stub_fstatfs64 #define __stub_fstatvfs64 #define __stub_glob64 #define __stub_lstat64 #define __stub_posix_fadvise64 #define __stub_readdir64 #define __stub_readdir64_r #define __stub_stat64 #define __stub_statfs64 #define __stub_statvfs64 and if you link against the functions you'll get a `foo64 is not implemented and will always fail' message. Funnily, the autoconf check doesn't bother to check if largefiles are really supported. What do you mean by "really supported"? I'd prefer checks that can be done at compile or link time, for cross-compilation. I'd suggest testing for one of the *64() functions in the list above. If you tell me which one, I'll make sure that'll be the last one for which we add a "real" implementation. We don't advertise that we support large files on the Hurd. If we did, we would set one of more of the following macros to 1 in : _LFS_LARGEFILE I don't know that those macros are reliable. E.g. I suspect that some AIX and/or HP-UX hosts don't define them, even though they have large files. (Unfortunately I don't have access to those hosts to test my theory.) The LFS specs are not always followed, so I'd like autoconf to use a more direct test if possible. That would mean a compile time check for one of the *64() functions listed above (AC_CHECK_FUNC checks the __stub_* macros mentioned above) or a link time check for the warning. Apparently the Hurd grow off_t from 32 to 64 bits when the programmer sets _FILE_OFFSET_BITS to 64. Why does the Hurd do this if it doesn't support large files, at least to some extent? In other words, to what extent does the Hurd support large files? The Hurd doesn't really support large files at all. The filesystems cannot handle partitions larger than ~1 GB, and there is no support for the 64-bit interfaces in the "kernel". We have definitions for most of the types and structures, "just to make the GNU C Library compile". By the way, I believe there are older versions of the GNU C Library thet even on Linux do not implement some of the *64() interfaces. Mark
Re: oskit-mach trouble
Date: Sun, 30 Jul 2000 17:31:11 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> On Sat, Jul 29, 2000 at 07:05:27PM +0200, Mark Kettenis wrote: > You'll probably need to provide alternatives for more (all) of the > functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach > synch.c. This would be osenv_intr_save_disable(), which is the only one not defined i oskit-mach? Yep! Try to cook up your own version of it. I don't understand how adding more overwrites can help, because the linker already complains about conflicting definitions, but then I don't understand the linker very well, so I will try to add a dummy function. The linker only pulls in an object from an archive if it is needed to satisfy undefined references. Since aparently some other code references osenv_intr_save_disable() and this function can only be found in the archive, it pulls in the entire module which also defines the functions in oskit-mach's synch.o, hence the conflicts. However, if you provide osenv_intr_save_disable() in oskit-mach's synch.o, the linker won't pull in oskit's synch.o, and the conflicts disappear. Mark
Re: error compiling glibc 2.2 (CVS), cross comp problem?
Date: Sun, 30 Jul 2000 23:46:09 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> Hi, I tried to compile glibc 2.2 (CVS head from 2000-07-13), because there are first debian sources for them and I want to make sure everything will work when the time is ready. I'm supposed to make sure it does :-). I'm not sure whether the 2000-07-13 snapshot does compile though. Just a warning: I recently made some changes to the Hurd's Makefiles that reorder some libraries. An older Hurd (i.e. one that doesn't have those patches) won't work with glibc 2.2. I got the following error. Is this related to cross compilation? Will using glibc2.2 on linux help? It's hard to say. Compiling glibc from CVS usually works for me, although there's a minor glitch from time to time. The undefined references come from the dynamic linker (ld.so). It looks as if the build process is using the old ld.so instead of the new one. Mark
Re: error compiling glibc 2.2 (CVS), cross comp problem?
Date: Mon, 31 Jul 2000 13:52:19 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> I don't think you really keep track of the Debian build scripts, do you? :) (Ben Collins takes over maintenance of glibc, and he asked me to take a look at his pre-packages). No, I still live in the dark ages where you'd get the source as a tar file and compile it yourself :-). > Just a warning: I recently made some changes to the Hurd's Makefiles > that reorder some libraries. An older Hurd (i.e. one that doesn't > have those patches) won't work with glibc 2.2. You mean it won't run? So the Hurd needs to be recompiled and both have to be installed updated at the same time? (This probably needs to be reflected in the package dependencies). A Hurd compiled from sources dating before 2000-07-26 won't run with glibc 2.2. Everything after that date should work with both glibc 2.1 or glibc 2.2. They do not have to be upgraded at the same time. People can upgrade their Hurd now (well, when there's a new Debian package). Compiling the Hurd with the glibc 2.2 headers doesn't quite work yet. libshouldbeinlibc/wire.c depends on some dynamic linker internals that have changed and are no longer exported. One of the things that I'll have to fixed before glibc 2.2 is released. >I got the following error. Is this related to cross compilation? Will using >glibc2.2 on linux help? > > It's hard to say. Compiling glibc from CVS usually works for me, > although there's a minor glitch from time to time. > > The undefined references come from the dynamic linker (ld.so). It > looks as if the build process is using the old ld.so instead of the > new one. It can't use the new linker when cross compiling, right? Well, it cannot actualy *execute* a program when cross compiling. But when building glibc the static linker should look at the new ld.so instead of the old ld.so. You know, ld.so is not only the program interpreter, but it also is a shared library. Anyway, either something went wrong with your build (nm and objdump might be handy to find out what's wrong), or your cross compiler is screwed somehow (passing -v to gcc can be of assistence here). Mark
Re: Bug in glibc/hurd/hurdsig.c
Date: Sun, 27 Aug 00 21:46:05 +0100 From: Peter Bruin <[EMAIL PROTECTED]> Dag Peter, Hello, I think there is a bug in glibc, in hurd/hurdsig.c:_hurdsig_init. It happens when, in a cthreads program, _hurdsig_fault_init refers to _hurd_msgport_thread before it is set in the _hurd_msgport_receive thread. I would suggest something like: Fixed that a couple of days ago :-). BTW, the PowerPC port of the Hurd now works until console-run tries to open the terminal. I am working on dynamic linking, which doesn't work well yet. Great to see there's progress :-). Don't hesitate to ask any questions. Make sure you provide parallel implementations for the things in sysdeps/mach/hurd/i386. dl-machine.h is particularly relevant to the dynamic linker. Mark
Re: huge number of ports & threads
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]> Date: 29 Jul 2000 20:31:24 +0300 Marcus Brinkmann <[EMAIL PROTECTED]> writes: > compiling oskit really stresses the Hurd. It takes many hours > on my machine. But when I checked after 8 hours, it seemed to > make slow progress, so I interrupted it and looked at the state > of the machine. When I compiled more stuff on the Hurd in Oct 1999, I used to get this behavior too. The programs didn't even have to be big; perhaps that's because the machine only has 16 MB of RAM. When I compiled libc, I had to interrupt and reboot the system several times to get it back to speed. Me too :-(. > I found out that the ext2fs.static process on /mnt, where the compilation > happened, had 137 threads and 1062 ports. But the root filesystem had > 1817 threads and 7808 ports. In my case, ext2fs.static had 847 ports and PID 3 (the pager) had 6779. Perhaps you too have many more ports in the pager? I bet. When memory is getting low, Mach starts paging out stuff. Apparently it does so at a rate which causes every request to start a new thread (i.e. the previous pageouts have not yet completed when a new one arrives). Some time ago Thomas made some changes to the paging code in the kernel with the idea to avoid this scenario, but apparently it doesn't help enough in your case. Mark
Re: [Bug-hurd] Re: defining _POSIX_SYNCHRONOUS_IO although msync not available?
Date: Sun, 17 Sep 2000 23:35:44 -0400 (EDT)
From: Roland McGrath <[EMAIL PROTECTED]>
> So we probably have to give in. The apt author (Jason Gunthorpe) is not
> happy about a special configure check for that on the Hurd (quote: "I really
> hate adding more configure tests"), and the code is correct in any way.[1]
I have no problem with that. We should not claim to conform to things we
don'te rally conform to.
FYI, I checked in the following change:
2000-09-18 Mark Kettenis <[EMAIL PROTECTED]>
* sysdeps/mach/hurd/bits/posix_opt.h (_POSIX_SYNCHRONIZED_IO):
#undef since we don't have msync.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: How to get _IOT_disk_parms ?
Date: 07 Oct 2000 16:52:30 +0200 Content-Type: text/plain; charset=us-ascii Hello, I'm trying to compile the following code fragment: [...] Unfortunately, I get this compilation error: gcc -g -Wall -I/gnu/includegeom.c -o geom geom.c: In function `store_get_disk_geometry': geom.c:19: `_IOT_disk_parms' undeclared (first use in this function) geom.c:19: (Each undeclared identifier is reported only once geom.c:19: for each function it appears in.) geom.c:19: warning: passing arg 3 of `device_get_status' from incompatible pointer type I've been trying for many many hours now to track down this _IOT_disk_parms guy, with no success. What should I include? I'm getting desperate. Hmm, you're mixing Mach and Hurd ioctls here, and get bitten by the fact that the encodining of the ioctls differs between the two. The Mach/i386 ioctl encoding is specified in . The Hurd ioctl enconding is specified in . There are simply no _IOT_xxx definitions for Mach ioctls. I'm not sure if mixing the two should work. But in this particular case, you can #define _IOT_disk_parms 0x038e and everything should work fine :-). By the way, I don't thing V_GETPARMS is supported by oskit-mach. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: stopping of translators
From: Roland McGrath <[EMAIL PROTECTED]> Date: Tue, 10 Oct 2000 04:27:11 -0400 (EDT) > So the more precise question is: should translators quit when the last > reference to them is gone? It is up to the translator to decide when it is safe and desireable to shut down when there are no users. The general plan is to do this after a timeout, but the implementations are not entirely consistent. Look at the calls to ports_manage_* and the code around them--those functions take arguments for the timeout value and return when the timeout expires. After that, the server code must ascertain if there are no user ports and if so it can to decide to exit. I believe that in the current code, the actual timeouts are disabled, i.e. all started threads are kept forever, and no translator will ever terminate when linked with the current libports. Enabling the timeouts isn't too difficult, but when I did so somewhere in the past, I encountered some bugs. One of them an off-by-one problem that terminated the last thread listening for requests. Sorry, I don't have the details right now. Could look them up off course :-). Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: cross compilation problems
Date: Thu, 26 Oct 2000 21:07:55 -0700 From: Steve Bowman <[EMAIL PROTECTED]> No bug report needed. /usr/i386-gnu/lib is indeed a symlink to /gnu/lib and ldd under hurd shows: libc.so.0.2 => /lib/libc.so.0.2 (0x01022000) for all libraries. ldd under linux just finds the wrong libc so that's the wrong way to check. Indeed. ldd is useless in cross-compiling situations, since it is invoking the Linux ld.so on a Hurd binary. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: a problem with login and hostname
Date: Mon, 13 Nov 2000 20:04:22 +0100 From: Marcus Brinkmann <[EMAIL PROTECTED]> This is a glibc bug. In libc/hurd/get-host.c, the returned buffer is not null terminated if there is no newline in the file. A patch is below, I didn't test it, but it's sort of obvious what is going wrong. Mark, can you commit this or a patch with a similar effect? Thanks Marcus, I checked it in. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Problems cross-compling glibc
From: Farid Hajji <[EMAIL PROTECTED]> Date: Thu, 7 Dec 2000 13:03:39 +0100 Hi, cross-compiling glibc (new cvs snapshot) breaks with the following error message (while making $(GLIBC_BUILDDIR)/elf/dl-sysdep.os): I already fixed this :-). Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: all largefile checks broken
From: Marcus Brinkmann <[EMAIL PROTECTED]> Date: Thu, 4 Jan 2001 22:45:14 +0100 On Thu, Jan 04, 2001 at 04:04:14PM -0500, Roland McGrath wrote: > > some largefile autoconf check included in shellutils, fileutils and probably > > elsewhere doesn't recognize the Hurd stubs returning EOPNOTSUPP correctly. > > For all those, a special case in the Debian packaging is needed to add > > --disable-largefile to configure invocation. > > Please give details. autoconf is only supposed to notice ENOSYS. Ok, I think I misunderstood that. To clarify things: All autoconf does is check whether it can get a 64-bit off_t by defining an appropriate macro. For the Hurd this is the case for #define _FILE_OFFSET_BITS 64 and autoconf assumes everything else is kosher even though we do not claim to support LFS (we don't define any of the _LFS* constants in ), and a lot of the *64 functions are only implemented as stubs and cleary marked as such. I raised the issue with the autoconf folks, suggesting they'd check the proper _LFS* defines, but was told that most of the systems out there were subtly broken such that this wouldn't work. At that time Roland suggested that we'd simply add the necessary *64 functions to libc (emulating them with the 32-bit interfaces), but I only did those that were necessary to support libio. I'll have a go at it now. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Cosmetic glibc 2.2.2 and hurd cvs patches.
From: "Arkadi E. Shishlov" <[EMAIL PROTECTED]> Date: Sun, 18 Feb 2001 02:27:47 +0200 Hi. Just checked out and build latest hurd & glibc. Attached two patches I've created to make it possible. Hurd boots and works OK. Thanks, I've applied the libc changes. I'll leave the other bits to someone else right now. It it worth to post such (small) patches in list or it should be handled in different way? (BTS, no post at all?) Well, I don't know the official policy. If you only post them to the mailing list, they might get lost. Entering them into the Debian BTS should be enough to avoid that. And now we also have savannah.gnu.org (the GNU sourceforge site) where you can enter bug reports for the Hurd. Whatever you do, please let us know about these problems and patches, no matter how small they are. Thanks, Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Bug#88690: mtrace triggers SIGBUS at first malloc
From: Marcus Brinkmann <[EMAIL PROTECTED]> Date: Wed, 7 Mar 2001 19:39:51 +0100 So I think this might have something to do with what _cthread_init_routine does, or with the special code in libc/sysdeps/mach/hurd/i386/init-first when this function is defined. I don't understand this code at all, and I have no idea how to debug it any further than that. What! You don't understand Roland's overly clever stack-munging code :-). Seriously, what _cthread_init_routine does is allocating a new stack for the initial thread. Then the code in sysdeps/mach/hurd/i386/init-first.c copies some stuff (such as the program arguments and environment) from the old stack to the new one, switches to the new stack, and then frees the old stack. However the dynamic linker keeps a pointer to the old program arguments in _dl_argv. Now when mtrace() calls _dl_addr() it looks at _dl_argv[0], which points somewhere in the deallocated stack which results in your SIGBUS. Unfortunately, I'm not sure how to fix this yet. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: internal compiler error
From: Roland McGrath <[EMAIL PROTECTED]> Date: Sun, 11 Mar 2001 19:10:29 -0500 (EST) Congratulations, you have found a GCC bug. Run the compilation by hand with -v -save-temps, and then take the -v output and the .i file and include them in your bug report to the GCC folks. Since 2.95.2 works fine, this clearly is a regression, and should really be reported, such that the official 2.95.3 release doesn't have this problem. Marcus, can you report it to the GCC folks? It's probably a good idea to include 2.95.3 somewhere in the subject line in order to attract the attention of the release manager. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: glibc broken
From: Marcus Brinkmann <[EMAIL PROTECTED]> Date: Wed, 23 May 2001 12:38:18 +0200 On Tue, May 22, 2001 at 11:04:54PM -0400, Roland McGrath wrote: > It is important to be clear about what works and what doesn't: > > * statically linked user programs > * statically linked user programs that use cthreads I don't see how a statically linked program can be affected by a glibc upgrade. Note that I didn't recompile the Hurd with the new glibc. It's likely to be a problem in the libc or ld.so initialization code, in particar the argument/environment vector munging that we do at various stages. And those things are done differently if a program is started directly by Mach or serverboot or via the exec server. The dates Marcus mentions make the following change a bit suspect: 2001-03-24 Mark Kettenis <[EMAIL PROTECTED]> * sysdeps/mach/hurd/i386/init-first.c: Include . (_dl_argv): Declare. (init) [SHARED]: Readjust _dl_argv if we switched to a new stack. I'm fairly sure things were working OK on my machine, but I can remember problems similar to the ones Marcus is observing when working on that patch. Perhaps the assertion in sysdeps/mach/hurd/i386/init-first.c:init() is failing? ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: glibc broken
I can't reproduce Marcus' problems with a freshly checked out glibc. Everything appears to work fine for me. Oh, and invoking ld.so on a statically linked executable isn't supposed to work I think. Produces a segmentation fault on Linux and Solaris, so I think the current Hurd hebaviour is quite acceptable. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: glibc broken
Date: Sun, 27 May 2001 18:36:52 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]> On Thu, May 24, 2001 at 05:17:08PM +0200, Mark Kettenis wrote: > I can't reproduce Marcus' problems with a freshly checked out glibc. > Everything appears to work fine for me. Can you provide us a tar of the build directory? I'd like to do a comparison. Hmm, the entire build directory is to large, however I have put up a gzipped libc_pic.a and a tar of the elf/ subdirectory: http://www.science.uva.nl/~kettenis/libc_pic.a.gz http://www.science.uva.nl/~kettenis/elf.tar.gz libc_pic.a.gz is about 10 MB, elf.tar.gz about 2.5 MB. Can you ping me when you've downloaded them? Also, can you let us know which versions of binutils and gcc you use. binutils 2.10.1, gcc 2.95.2. These are Linux native versions that I turned into a cross toolchain :-). Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Fix statfs
The way the ext2fs and ufs file system calculate the number of available blocks can yield a negative number. Since fsblkcont_t is an unsigned type this causes some interesting output from df, when your filesystem is clogging up. Roland, OK to check thus in? Mark Index: ext2fs/ChangeLog from Mark Kettenis <[EMAIL PROTECTED]> * inode.c (diskfs_set_statfs): If number of free blocks is less than the number of reserved blocks, set the number of available blocks to 0. Index: ufs/ChangeLog from Mark Kettenis <[EMAIL PROTECTED]> * inode.c (diskfs_set_statfs): If number of free blocks is less than the number of reserved blocks, set the number of available blocks to 0. Index: ext2fs/inode.c === RCS file: /home/cvs/hurd/ext2fs/inode.c,v retrieving revision 1.54 diff -u -p -r1.54 inode.c --- ext2fs/inode.c 2001/01/07 17:03:55 1.54 +++ ext2fs/inode.c 2001/06/09 11:28:05 @@ -1,6 +1,6 @@ /* Inode management routines - Copyright (C) 1994,95,96,97,98,99,2000 Free Software Foundation, Inc. + Copyright (C) 1994,95,96,97,98,99,2000,01 Free Software Foundation, Inc. Converted for ext2fs by Miles Bader <[EMAIL PROTECTED]> @@ -618,6 +618,8 @@ diskfs_set_statfs (struct statfs *st) st->f_blocks = sblock->s_blocks_count; st->f_bfree = sblock->s_free_blocks_count; st->f_bavail = st->f_bfree - sblock->s_r_blocks_count; + if (st->f_bfree < sblock->s_r_blocks_count) +st->f_bavail = 0; st->f_files = sblock->s_inodes_count; st->f_ffree = sblock->s_free_inodes_count; st->f_fsid = getpid (); Index: ufs/inode.c === RCS file: /home/cvs/hurd/ufs/inode.c,v retrieving revision 1.54 diff -u -p -r1.54 inode.c --- ufs/inode.c 2001/01/08 22:33:11 1.54 +++ ufs/inode.c 2001/06/09 11:28:07 @@ -1,5 +1,5 @@ /* Inode management routines - Copyright (C) 1994,95,96,97,98,2000 Free Software Foundation, Inc. + Copyright (C) 1994,95,96,97,98,2000,01 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as @@ -519,6 +519,8 @@ diskfs_set_statfs (struct statfs *st) + sblock->fs_cstotal.cs_nffree); st->f_bavail = ((sblock->fs_dsize * (100 - sblock->fs_minfree) / 100) - (sblock->fs_dsize - st->f_bfree)); + if (st->f_bfree < ((sblock->fs_dsize * (100 - sblock->fs_minfree) / 100))) +st->f_bavail = 0; st->f_files = sblock->fs_ncg * sblock->fs_ipg - 2; /* not 0 or 1 */ st->f_ffree = sblock->fs_cstotal.cs_nifree; st->f_fsid = getpid (); ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: packets stuck in queue (was: Re: pfinet & ftp & hang, round two (much simpler case)
Hey Marcus, it works really great. No real problems thus far. Even ftpfs seems to work reasonably well. Thanks! ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Fix statfs
From: [EMAIL PROTECTED] (Thomas Bushnell, BSG) Date: 29 Jun 2001 10:55:51 -0700 Mark Kettenis <[EMAIL PROTECTED]> writes: > The way the ext2fs and ufs file system calculate the number of > available blocks can yield a negative number. Since fsblkcont_t is an > unsigned type this causes some interesting output from df, when your > filesystem is clogging up. Hrm. Before checking it in, it seems to me that if this situation actually arises, there is a bug. I mean, we should never allow reserving more blocks than we really have free... No there is no bug. Those blocks are reserved for root, thus when root starts using these, the number of available blocks (as in available to other users) f_bavail should be reported as 0. The number of blocks that are really free is stored in f_bfree. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: glibc/io/fts.c, MAXPATHLEN issue
Date: Fri, 29 Jun 2001 15:49:01 -0500 From: Marcus Brinkmann <[EMAIL PROTECTED]> Hi, io/fts.c has a MAXPATHLEN issue. The Debian glibc build of 2.2.3-6 (CVS 6-9-2001) fails because of that. I don't see any problems with the current CVS version. Yes, it uses MAXPATHLEN, but only as a reasonable default, and io/fts.c defines it to 1024 if it isn't already defined. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: error compilimg hurd cvs source
From: Moritz Schulte <[EMAIL PROTECTED]> Date: 02 Jul 2001 00:27:20 +0200 > make[1]: Entering directory `/root/src/hurd/libdiskfs' > gcc -O -Wall -g -O3 -I. -I.. -I../include -D_GNU_SOURCE-c -o file-syncfs.o file-syncfs.c > file-syncfs.c: In function `helper': > file-syncfs.c:61: internal error--unrecognizable insn: IIRC i got the same error. Decreasing the optimiziation from '-O3' to '-O2' helped (it seems to be a bug in gcc). You can do that in the file 'Makeconf' in the Hurd source tree. It *is* a bug in GCC. Please report it to the GCC folks. See http://gcc.gnu.org/bugs.html for more information on reporting bugs in GCC. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Thread creation and stack allocation
From: Igor Khavkine <[EMAIL PROTECTED]>
Date: Mon, 2 Jul 2001 01:37:59 -0400
On Sun, Jul 01, 2001 at 08:27:17PM -0400, Igor Khavkine wrote:
>
> In this case, should the creation of the "red zone" be the programmer's
> responsibility, or is there a way to create it with the library?
>
> It is also possible that I'm misinterpreting the standard, if so, please
> let me know.
I've looked further in the standard and found the functions
pthread_attr_{get,set}guardsize(). These control the size of the
"red zone" or guard zone at the end of the stack. However the
documentation is moot and does not specify whether the guard area
is part of STACKSIZE set by the user with ptread_attr_{get,set}stacksize().
Clarifications, are more then welcome.
The page for pthread_attr{get,set}guardsize() in the current POSIX
draft says:
if the STACKADDR or STACK attribute has been set (that is, the
caller is allocating and managing its own thread stacks), the
GUARDSIZE attribute shall be ignored and no protection shall be
provided by the implementation. It is the responsibility of the
application to manage stack overflow along with stack allocation
and management in this case.
Changebars in the draft indicate that this is a recent addition. See
http://www.opengroup.org/austin on how to get the current POSIX draft.
Mark
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Kernel Divide error trap
Could it be a compiler optimization issue, where the empty loop is simply optimized away, and therefore never executed?? (I have seen stranger things come out of optimized code) On Wed, 26 Sep 2001 19:20:22 +0200, Marcus Brinkmann wrote: >On Wed, Sep 26, 2001 at 05:15:32PM +0200, Piotr Krukowiecki wrote: >> > > Anyway, first leftover is f3, second f3ff, so i'ts close to >> > >> > Just print the final calculation. >> >> > >Ok, so why has it that value? It's strange enough. The tenmicrosec will >count down from MICROCOUNT (1000) to zero, and in this time, the counter >should go down from 0x to something smaller than that. > >It can't overflow, because counting to 1000 is fast. The comment above the >function says "MICROCOUNT 1000 /* keep small to prevent overflow */" and >that was when a 386 was a powerful machine. > >So, may it be that the loop in tenmicrosec was executed faster than the >clock could go down? But that would be trifle strange as we have run the >Hurd on mach faster machines than an AMD K6 400MHz and not have this bug >(and any faster machine should show the same bug). I have personally run >the Hurd on a Pentium III with 1GHz, and it worked just fine. > >On the other hand, that adding a printk hold it up enough to go down to >0xfff3 (IIRC), so maybe it is indeed the case that the clock doesn't go down >at all. Does your processor do something special to an empty loop that >prevents the clock from going down? I am no processor expert. Why have >other people with a similar configuration not reported such a problem >before? > >However I turn it, it remains a mystery to me, and frankly, I am not sure >what to suggest to you how to get more info about it. > >> > > Now, should i left that printk or maybe better would be to add sth. like >> > > if (leftover == 0x) leftover -= 1; >> > >> > The last printk should be ok. BTW, oskit-mach does not use that code, so >> >> But it doesn't change anything. I must add "if" > >Yeah, simply setting microdata to 1 might work around it, but I don't think >it's the correct approach. At least I don't understand why the code doesn't >work on your machine but on other, even faster machines. > >> > the problem will go away in the future. However, we might be able to just >> >> Future does not satisfy me ;) > >A hack to just make it work on your machine doesn't satisfy me ;) > >> Well, why not. I have another bug, i'll post info but i must check >> mail archive > >You scare me ;) > >Thanks, >Marcus > >-- >`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] >Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] >[EMAIL PROTECTED] >http://www.marcus-brinkmann.de > >___ >Bug-hurd mailing list >[EMAIL PROTECTED] >http://mail.gnu.org/mailman/listinfo/bug-hurd ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: ps just hangs
From: Roland McGrath <[EMAIL PROTECTED]> Date: Thu, 25 Oct 2001 02:31:19 -0400 (EDT) > (gdb) attach 743 > Attaching to program `/usr/bin/tail', pid 743 > ^C^C Hmm. That might be gdb trying to talk to the signal thread. Definitely. But there is no excuse for C-c not working in gdb. Someone should debug gdb. Hmm. C-c is supposed to interrupt the program, which obviously fails because the signal thread isn't responding. Should it interrupt GDB instead in such a case? There might be some hurdish gdb options you should set before attaching. "set signals" or something. "set noninvasive on" should do the trick. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Building OSKit-Mach (texinfo format) - dead link w/patch
The link for the remote debugging boot option (oskit-boot.txt)
under Booting OSKit-Mach is broken. I would propose the following
patch to correct this link to a live location:
--- oskit-mach.texi.origTue Oct 9 11:15:14 2001
+++ oskit-mach.texi Tue Oct 9 11:16:08 2001
@@ -344,7 +344,7 @@ Assuming all of this worked successfully
start debugging oskit-mach. If you have a second machine with a couple
of serial cables, the preferred method is remote debugging using GDB.
That is outside the scope of this document, though; see
-@url{http://www.multiverse.ca/hurd/oskit-boot.txt}
+@url{http://debian.fmi.uni-sofia.bg/~ogi/hurd/hurd.gnu.org/oskit-boot.txt}
for a treatment of that topic.
to On Tue, 25 Sep 2001 17:47:59 -0500, Kevin Kreamer wrote:
>Robert, thank you for your help. Jeff, here's that doc I was
>telling you about.
>
>On Sat, Sep 22, 2001 at 01:14:35PM +, Robert J. Chassell said:
>> The document formats without reported error, except for one overfull
>> and one underfull hbox in the TeX dvi output.
>
>Ok, I've changed the overfull paragraph around a bit, and now it's
>a underfull paragraph, which is better I suppose. Both of those
>are caused by longish URL's in the paragraphs, I'm not sure what else can
>be done.
>
>> It is convenient to include the following summary of shell commands at
>> the beginning of your Texinfo document. This set of commands makes it
>> easy for reviewers and users to create the different outputs. You can
>> run them in shell in Emacs, or copy them to an Xterm in X Windows.
>
>I've added these to the newest revision.
>
>> Also, I find that @smallbook produces the best size printed output,
>> even on US letter sized paper or on A4 paper. My eyes have an easier
>> time tracking `conventional book' length of lines in @smallbook and my
>> red editor's pen prefers the wider margins. (If your examples are
>> wide, @smallbook requires that you replace @example with
>> @smallexample.)
>
>I realised that I hadn't actaully run it through TeX, because my main
>focus was the .info file. Consequently, there was a few goofs that
>only showed up the TeX formats (like the table of contents being in
>the wrong place). I think it's best, then, to get this updated copy
>out to everyone instead of worrying about @smallbook. I may
>move it there in the future, and I'll keep this point in mind whenever
>I write more docs, so thank you for pointing it out.
>
>Kevin
>--
>Kevin Kreamer
>FsckIt on openprojects.net
>
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PowerPC port
From: Derek Fults <[EMAIL PROTECTED]> Date: Fri, 12 Oct 2001 13:09:17 -0500 I am also working on trying to port Hurd to OSF mach. I need to get a hold of a mig that generates the correct code for OSF mach, (without typchecking). Peter Bruin said he could get me one in a couple days but I was interested if knew where I could get one earlier? I removed the link to my OSF MiG package from my homepage a while ago, but you can still find it at: http://www.science.uva.nl/~kettenis/osfmk Enjoy, Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH] Mach's interface for modifying the LDT
Please be aware that the Mach LDT code still contains serious bugs. Setting the segment registers to something else than thier defaults is very likely to crash the kernel. I've tried to hunt down the bug, but didn't succeed. Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: gdbserver for GNU/Hurd
> Date: Sat, 23 Dec 2006 12:10:22 +0100 > From: Thomas Schwinge <[EMAIL PROTECTED]> > > Hello! > > Has anyone ever worked on porting the GDB distribution's gdbserver to > GNU/Hurd? I'm pretty sure the answer to that question is no. > In case you don't know: this would allow for debugging programs on > GNU/Hurd systems using a cross debugger running on another system (e.g. a > non GNU/Hurd one). This is of advantage if you're cross compiling and > then don't have to copy the source files to the target system for using > gdb locally on there. But it'd be difficult to have access to all the advanced features a native GNU/Hurd GDB offers. Mark ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
June offer from www.aberbid.com
Offer valid untill 12 July, FREE everyone 490$, who had quest four matching digits, for old and new customers. This action from our company. We could send you checks, e-gold, wire transfer. More info here: http://www.aberbid.com/ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Big apples
Title: jyh petalid Внимание! С 8 по 25 октября проводится акция «Оплачиваете за два уровня единовременно – третий изучаете бесплатно!» N Y L C Вот несколько причин, по которым Вы будете рады выбрать NYLC: 1.Обуч.аю.щие прог.раммы –ES..L(En.g.lish as a sec.ond lang.uage) 2.Ми.ни гру.ппы, индиви.дуальные, корпор.ативные 3.Фик.сиров.анная низкая стои.мость 4.Учи.теля из U.SA ,Анг.лии и Кан.ады 5.Провед.ение зан.ятий в удо.бных мест.ах расп.оложения 6.Каж.дый день нов.ые групп..ы! Удобное расписаниена выбор: предоставляются занятия в утреннее, дневное, вечернее время, а также группы выходного дня. Методы преподавания, которые доказывают, что Вы выучитесь быстро: наша программа делает акцент на рассмотрение ситуаций из реальной жизни. Вы начнете говорить по-английски с первого же дня обучения! Богатый опыт, великолепная репутация: Большинство наших учеников получают информацию о NYLC от бывших студентов, которые остались довольны нашей школой.Telephone 095 951-81-41 Satisf.action guar.anteed! It’s time to learn English you can do that easily and effectively at the NYLC in Moscow ,we are located in different locations in Moscow to provide convenience for our students, the NYLC has a professional staff of American teachers to help our students reach proficiency, the NYLC has been teaching English for many years all over the world. The NYLC is the key to future success so come and learn English today Употребляя спиртные напитки, твердо знайте свою норму. В противном случае вы рискуете выпить меньше. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
Revisited: Hurd on a cluster computer
Please excuse my raising my head above the parapet, most of the time I'm a lurker but I prefer the idea of a robustly-partitioned system and I think the industry-wide events of the last week or so reinforce that. >> [Brent said] The payoff is a supercomputer operating system that >> presents an entire cluster as a single POSIX system with hundreds >> of processors, terabytes of RAM, and petabytes of disk space. > [Richard replied] Most attempts in the past have failed. It seems > better to build specialiazed cluster computers on top of local > operating systems. Look for "single system image" on a search engine > for projects with this goal. Looking at this from an historical POV, I think there's another approach which is process migration without an SSI. Specifically, I'd highlight MOSIX and derivatives. Unlike e.g. Amoeba which I believe worked by locating a system with spare capacity and using that for a newly-started process, MOSIX worked by starting a new process on the local computer, then migrating it to another system retaining local stubs for communication with the kernel. A process could be moved multiple times to track spare capacity, but it continued to talk to its original kernel via the stubs. I had it running something like 15 years ago, and found that it was robust enough that if a collaborating system were booted during e.g. a kernel compilation then work would immediately migrate onto it, with no user involvement at all. It was, obviously, sensitive to systems dying without due warning: there was no checkpointing or program restart but even as it stood it was one of the more impressive things I've seen in the industry. I believe it was originally research with anticipated commercial spinoff. It was open sourced as OpenMOSIX, and later renamed to LinuxPMI (Process Migration Infrastructure). I put enough time into it a couple of years ago to determine which versions of Linux kernel and compiler it was compatible with (roughly speaking, Debian "Lenny") and I don't think anybody has done much more: more than anything else Linux is too much of a moving target for something which has fallen behind to ever catch up, and its monolithic architecture probably doesn't help. Apart from that, known problems were that it relied on kernel extensions written in assembler, it had no negotiation to ensure that collaborating systems were binary-compatible, it had no authentication or capabilities tracking, and it's probably not friendly to applications which use shared memory for their IPC. Finally, what is the Hurd portability situation? Way back I worked on a microkernel in '386 protected mode that used segmentation heavily, am I correct in assuming that that sort of thing is completely deprecated in the interest of portability? When I were a lad we used logic analysers to debug our code... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Revisited: Hurd on a cluster computer
On 21/05/17 13:45, Justus Winter wrote: Samuel Thibault writes: Though there was some work, a reimplementation if memory serves, of the netmsg servers. The archive should have some infos on that. Yes, by Brent who was the instigator of the original thread that I was belatedly commenting to :-) Well, that's unrelated to the question above, which was actually unrelated to the original thread, which you are answering now :) Ah, segmentation... Indeed, I wasn't reading that carefully, I thought is was related to the in-kernel forwarding of Mach messages across networks... Which is of course an interesting question in itself, and one which entirely by chance a hardware engineer of my acquaintance has been casually pondering. Incidentally, I've also just remembered http://www.scalemp.com/products/product-comparison/ which is another interesting attempt to build a cluster on top of Linux. Finally, I'm not entirely sure where IBM mainframe operating systems stand on the "SSI or not SSI" question: they have, of course, been doing this sort of thing for decades. My understanding is that a single computer (i.e. one "frame") is basically SMP with SSI, but that a sysplex has multiple OS instances with jobs moved around as required. It's perhaps interesting that Moshe Bar, who was originally responsible for MOSIX, is occasionally seen hanging out in IBM mainframe mailing lists. CC not necessary, I'm subscribed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Trying to get a basic installation working
I spent a while yesterday trying to get an installation going on a fairly standard Intel P4 system, but was consistently getting a kernel panic shortly after selecting a mirror or, if I skipped that, shortly after Tasksel was run. The CD image I was using was $ cksum *iso 4089521537 678834176 cd-1.iso $ sha1sum *iso 9239135037b664a08d355e2f7ece69bfa7576f07 cd-1.iso If it would help I could possibly transcribe the panic from a photograph, but since the CD appeared to be reading at 1x this is frustratingly time-consuming. Is there a more recent version of that I should be using, or should I be reverting to the somewhat older image described at https://www.gnu.org/software/hurd/index.html ? CC not necessary, I'm subscribed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Trying to get a basic installation working
On 27/06/17 14:23, Samuel Thibault wrote: Mark Morgan Lloyd, on mar. 27 juin 2017 08:06:59 +, wrote: The CD image I was using was $ cksum *iso 4089521537 678834176 cd-1.iso $ sha1sum *iso 9239135037b664a08d355e2f7ece69bfa7576f07 cd-1.iso This looks like the snapshot from january. There's the 2017 release from may on http://www.debian.org/ports/hurd/hurd-cd Thanks, for the last few hours I've been running the netinst from ~sthibault/hurd-i386/installer/cdimage/weekly-1/ which is chugging along in semi-graphical mode (text-mode bombed with something about "unable to create /run/screen"). Installation completed after about 10 hours, during most of which time the CD LED was flickering at about 20 Hz. It barfed at something coming from the mirror and there's no working network, boot message about ifup /dev/eth0 failing. Since the base network files etc. are there, as an experiment I told it to install openssh-server, this fetched the packages from CD at the expected speed. I have absolutely no reason to think that the off-the-shelf PC I was using has significant problems, and I'm fairly confident in the boot media and drives. I'm afraid that there might be something broken in the installation kernel etc., and even though I'm interested I'm going to find it very hard indeed to justify more time on this :-( CC not necessary, I'm (still) subscribed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Trying to get a basic installation working
Initially bounced at GNU servers, re-sent. On 27/06/17 14:23, Samuel Thibault wrote: > Mark Morgan Lloyd, on mar. 27 juin 2017 08:06:59 +, wrote: >> The CD image I was using was >> >> $ cksum *iso >> 4089521537 678834176 cd-1.iso >> >> $ sha1sum *iso >> 9239135037b664a08d355e2f7ece69bfa7576f07 cd-1.iso > > This looks like the snapshot from january. There's the 2017 release from may on > http://www.debian.org/ports/hurd/hurd-cd Thanks, for the last few hours I've been running the netinst from ~sthibault/hurd-i386/installer/cdimage/weekly-1/ which is chugging along in semi-graphical mode (text-mode bombed with something about "unable to create /run/screen"). Installation completed after about 10 hours, during most of which time the CD LED was flickering at about 20 Hz. It barfed at something coming from the mirror and there's no working network, boot message about ifup /dev/eth0 failing. Since the base network files etc. are there, as an experiment I told it to install openssh-server, this fetched the packages from CD at the expected speed. I have absolutely no reason to think that the off-the-shelf PC I was using has significant problems, and I'm fairly confident in the boot media and drives. I'm afraid that there might be something broken in the installation kernel etc., and even though I'm interested I'm going to find it very hard indeed to justify much more time on this :-( CC not necessary, I'm (still) subscribed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: Trying to get a basic installation working
On 28/06/17 08:38, Mark Morgan Lloyd wrote: This looks like the snapshot from january. There's the 2017 release from may on http://www.debian.org/ports/hurd/hurd-cd Page fault trap, either shortly after selecting the mirror or shortly after tasksel (with nothing non-standard selected). CC not necessary, I'm (still) subscribed. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: [GSoC 2017] Number fo sockets
Hi, Joan Lledó writes: > As I mentioned in my previous post about ioctl operations[1], LwIP > establishes a maximum limit of sockets, which is a big problem for a > system like the Hurd. Now I've finished all tasks in my initial > proposal, I thought it was a good idea to spend some time studying > this issue and trying to find a solution. > > The problem is this: in LwIP, sockets are stored in a fixed-size > array, which is the best solution for embedded systems as it is a > natural way of indexing items without need of additional variables and > allows the user to directly access any socket from its index taking > the same time. If we remove the limited amount of sockets, then we > cannot keep using an array, and another solution is required to handle > all this. > > In the LwIP translator, I've chosen to replace the array for a linked > list, and that has some implications: the need to iterate the list any > time we need to create, destroy or look for a particular socket, I would be good to avoid having socket lookup require time proportional to the number of sockets. The number of sockets may grow quite large in some applications. Instead of a linked list, how about using a dynamic array? https://en.wikipedia.org/wiki/Dynamic_array This would give you constant-time lookups, amortized constant time insertions and deletions, and better data locality and cache behavior. What do you think? Mark
GNU Mach & Hurd overview
I was interested in the current state of affairs for the GNU microkernel. project so I went to hurd home page. I find the microkernel. concept very interesting for parallel computers made up of Systems On a Chip (SOCs), an area of interest to me for twenty years. I would agree with your assessment of reference manual as being sub optimal as a tutorial. Since it's probably not intended as such I wasn't sure how to make suggestions so I'll start with an email and we can go from there. A faq would be a nice way to find out what people don't understand and would like to know. This format is easy to follow and often become self organizing after a short while. A basic tutorial on OSes would be nice. A single graphic of the different lays from machine hardware to microkernel to services to user apps would do. It could also be compared with integrated kernels, machine hardware to kernel to apps. A brief discussion of the pros and cons and why the world has not seen the light yet would also be helpful. It's been my experience, both as a developer and a development manager, that getting developers to document is painful but getting them to answer specific questions is less so. Clearly you don't want them to spend their time writing doc instead of writing code but a little doc is a wonderful thing. Thanks Mark ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
