Bug#185094: Patch consider_lmm_collect: Test always true

Package: gnumach Version: CVS 20030316 In gnumach/oskit/osenv_mem.c, consider_lmm_collect() looks as if it can stop short of transfering the optimal number of pages from VM to LMM due to an oversight. The variable `i' is decremented to 0 before it is compared to `batch'. Since `batch' is always

Re: Future use of OSKit facilities in gnumach

EAD&content-type=text/vnd.viewcvs-markup WHAT IT IS The plan here (or the dream anyway) is to take pieces of GNU Mach and put them into a Linux executable so you can run a Hurd program inside your terminal window and "reboot" back to th

Re: Future use of OSKit facilities in gnumach

ough, and I do not intend to support a separate, single-threaded configuration (for what? speed??). Btw, I am looking more closely at the OSKit Unix stuff and becoming more optimistic about it. Guess I'll have to roll my own mmap() though, or fish it out of /usr/lib/libc.a . T

Re: Future use of OSKit facilities in gnumach

r an IRC server, but fast enough to get my brother to try the Hurd. Oh, and NCPUS will be > 1 by default thanks to linuxthreads. -- John Tobey <[EMAIL PROTECTED]> \^-^ /\ /\ ## void tramp(int const* pseudo_code) # Wait for and service a kernel request to execute a syscall,

Future use of OSKit facilities in gnumach

utines.c:#include gnumach/oskit/osenv_log.c:#include Certainly, I would be replacing x86/main.c, and maybe some of the others in gnumach/oskit/. My question is, are there likely to be more files that use oskit/c stuff in the foreseeable future? Thanks -John --

Re: store_open() unforgiving in bootstrap fs

(unless given a bad string argument), and if it does then > that is the bug (in libc). I have made a little project of extracting the stack trace. Here is my proposed (untested!) patch: 2001-11-26 John Tobey <[EMAIL PROTECTED]> * hurd/hurdinit.c (_hurd_ports_use): Avoid a crash

Re: store_open() unforgiving in bootstrap fs

On Mon, Nov 26, 2001 at 06:48:42AM -0500, Roland McGrath wrote: > > The crash came in file_name_lookup() presumably because there is no > > working directory port yet. > > Don't presume, debug! There is no reason why file_name_lookup should ever > produce a crash (unless given a bad string arg

store_open() unforgiving in bootstrap fs

eck, but I don't know the best way for libstore to detect whether it is the bootstrap filesystem. Best, -John -- John Tobey <[EMAIL PROTECTED]> ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: cruft and forks

On Sun, Nov 25, 2001 at 01:12:35PM +0100, Marcus Brinkmann wrote: > You misunderstood Roland. OSKit already has support to run OSKit based > kernels on top of Unix. Thanks for the explanation, Marcus. I don't know if it's worth moving what I'm doing to the OSKit environment, but at least it giv

cruft and forks

of benefitting from future improvements, as compared to the GNU Mach approach. Thanks for your help. -John -- John Tobey <[EMAIL PROTECTED]> ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Kernel crash on device_map DEVICE_NULL

On Thu, Nov 22, 2001 at 01:51:12PM -0500, Roland McGrath wrote: > There is no meaningful sense in which ext2fs.static can "call device_map on > a null pointer". device_map is an RPC. The only way a user task "calls" > the kernel function is by sending an RPC. The RPC should never have gotten >

Kernel crash on device_map DEVICE_NULL

On Sun, Nov 18, 2001 at 09:25:56PM -0500, Roland McGrath wrote: > Well, frankly I think you're nuts. But more power to you. > For your stated goals and constraints, I would just go with plex86. > But if you really get this approach to work usably, it could be interesting. Now I don't know if the

Re: Hurd on Mach on GNU/Linux (verion 0.0.0)

here I have such a choice. However, I aim to keep both kinds to a minimum without needing to recompile userland Hurd code. Cheers, -John -- John Tobey <[EMAIL PROTECTED]> ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Hurd on Mach on GNU/Linux (verion 0.0.0)

ng I forgot to mention. This runs unprivileged. I do not trust plex86. -- John Tobey <[EMAIL PROTECTED]> ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Hurd on Mach on GNU/Linux (verion 0.0.0)

system; I guarantee the opposite. This code is not clean. You do not want to look too closely at this code. However, I thought people might be interested. Regards, -John ps, OTOP means "On Top Of POSIX" but there are a few Linux and i386 dependencies still in there. -- John Tob

gnumach Linux source in CVS formatted as HTML

(xloops), "=&a" (d0) + :"=d" (xloops), "=&a" (d0) :"1" (xloops),"0" (loops_per_sec)); __delay(xloops); } Regards, -John -- John Tobey <[EMAIL PROTECTED]> Take a minute for the defense of freedom: http://www.indefenseoffreedom.org/ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd