Re: Some Hurd and Mach programming questions

2000-05-24 Thread Thomas Bushnell, BSG
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Fri, May 19, 2000 at 01:24:13PM +0200, Tomasz Wegrzanowski wrote: > > 1. > > How accurate are 1987-1989 CMU Mach papers if GNU Mach is considered. > > Depends entirely on what specific issue you look at. > For example, the Hurd has no nameserver,

Re: Some Hurd and Mach programming questions

2000-05-23 Thread Roland McGrath
> Well, do you think it would be useful to add a command like > "bootscript" into GRUB? This is a virtual example on how to use the > command: Yes, I had already planned to add exactly this once the rest of the support was done. As you say, this is a trivial piece.

Re: Some Hurd and Mach programming questions

2000-05-23 Thread OKUJI Yoshinori
From: Roland McGrath <[EMAIL PROTECTED]> Subject: Re: Some Hurd and Mach programming questions Date: Tue, 23 May 2000 04:09:41 -0400 (EDT) > time. My original notion when we were hashing out multiboot was that GRUB > would read a script like /boot/servers.boot and load all th

Re: Some Hurd and Mach programming questions

2000-05-23 Thread Roland McGrath
> What I'm wondering about is why Hurd doesn't let GRUB just load > multiple modules but uses one not-very-elegant module (serverboot) > instead. Didn't GRUB has the support to load multiple modules when > Hurd was born? GRUB does indeed, and always has (it supports the multiboot spec, after all

Re: Some Hurd and Mach programming questions

2000-05-22 Thread Tomasz Wegrzanowski
On Mon, May 22, 2000 at 03:27:59PM -0400, Daniel Burrows wrote: > On Fri, May 19, 2000 at 05:56:58PM +0100, Edmund GRIMLEY EVANS <[EMAIL > PROTECTED]> was heard to say: > > Mark Kettenis <[EMAIL PROTECTED]>: > > > > >8. > > >Does it make any sense to move most device drivers (scsi/ide) >

Re: Some Hurd and Mach programming questions

2000-05-22 Thread OKUJI Yoshinori
From: Roland McGrath <[EMAIL PROTECTED]> Subject: Re: Some Hurd and Mach programming questions Date: Mon, 22 May 2000 15:37:50 -0400 (EDT) > into physical memory, and tells the kernel where to find them. The first > program file (currently /boot/serverboot in the Hurd) knows about

Re: Some Hurd and Mach programming questions

2000-05-22 Thread Roland McGrath
> > Why would PCI bus have to be in the kernel? Why would you need support > > for a disk device in the kernel? > The first thing that springs to mind is that if you lack a disk device > you may have some difficulty in loading the server which provides it, in > paging it in or out, etc.. The code

Re: Some Hurd and Mach programming questions

2000-05-22 Thread Daniel Burrows
On Fri, May 19, 2000 at 05:56:58PM +0100, Edmund GRIMLEY EVANS <[EMAIL PROTECTED]> was heard to say: > Mark Kettenis <[EMAIL PROTECTED]>: > > >8. > >Does it make any sense to move most device drivers (scsi/ide) > >from Mach to user-space. > >I suppose than PCI bus etc. would s

Re: Some Hurd and Mach programming questions

2000-05-20 Thread Tomasz Wegrzanowski
On Sat, May 20, 2000 at 02:45:44AM +0900, OKUJI Yoshinori wrote: > From: Tomasz Wegrzanowski <[EMAIL PROTECTED]> > Subject: Re: Some Hurd and Mach programming questions > Date: Fri, 19 May 2000 18:37:04 +0200 > > > How much of IPCing really needs MIG and > > co

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Tomasz Wegrzanowski
On Fri, May 19, 2000 at 05:56:58PM +0100, Edmund GRIMLEY EVANS wrote: > Mark Kettenis <[EMAIL PROTECTED]>: > > >8. > >Does it make any sense to move most device drivers (scsi/ide) > >from Mach to user-space. > >I suppose than PCI bus etc. would still need to be in kernel. > >

RE: Some Hurd and Mach programming questions

2000-05-19 Thread Brent Fulgham
Title: RE: Some Hurd and Mach programming questions > > I suppose that you'll always need some basic support for a > > disk device in the Mach kernel.  Some other device drivers might be > > moved out to > > Why would PCI bus have to be in the kernel? Why w

Re: Some Hurd and Mach programming questions

2000-05-19 Thread OKUJI Yoshinori
From: Tomasz Wegrzanowski <[EMAIL PROTECTED]> Subject: Re: Some Hurd and Mach programming questions Date: Fri, 19 May 2000 18:37:04 +0200 > How much of IPCing really needs MIG and > couldn't be done by some set cpp macros or other way that > don't need inventing a new la

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Edmund GRIMLEY EVANS
Mark Kettenis <[EMAIL PROTECTED]>: >8. >Does it make any sense to move most device drivers (scsi/ide) >from Mach to user-space. >I suppose than PCI bus etc. would still need to be in kernel. > > I suppose that you'll always need some basic support for a disk device > in the Ma

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Tomasz Wegrzanowski
On Fri, May 19, 2000 at 02:19:40PM +0200, Mark Kettenis wrote: >Date: Fri, 19 May 2000 13:24:13 +0200 >From: Tomasz Wegrzanowski <[EMAIL PROTECTED]> > >Mach/MIG related : > >3. >How good is MIG ? >What special, non-obvious features are really in use if >compared to i

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Marcus Brinkmann
On Fri, May 19, 2000 at 02:28:14PM +0200, Marcus Brinkmann wrote: > I don't know what "current" means to you, though. All Hurd servers are > multithreaded and usually serve multiple users/processes. Reading Marks reply, I am enlightened. Forget this part of my message :) Marcus

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Marcus Brinkmann
On Fri, May 19, 2000 at 01:24:13PM +0200, Tomasz Wegrzanowski wrote: > 1. > How accurate are 1987-1989 CMU Mach papers if GNU Mach is considered. Depends entirely on what specific issue you look at. For example, the Hurd has no nameserver, but it has (still) cthreads, and the client/server basics

Re: Some Hurd and Mach programming questions

2000-05-19 Thread Mark Kettenis
Date: Fri, 19 May 2000 13:24:13 +0200 From: Tomasz Wegrzanowski <[EMAIL PROTECTED]> Mach/MIG related : 1. How accurate are 1987-1989 CMU Mach papers if GNU Mach is considered. I'm not entirely sure. Some of these papers are probably discussing things about Mach 2.5 and may be s