Re: Questions

[Ludovic Courtès]

Hi,

Designing computer programs, in general, is always a tradeoff between
flexibility and performance AFAIK: The more flexible the system is, the
more resource-consuming it is.  So, micro-kernel based multi-server
systems may be slower than monolithic kernel based systems (although
recent micro-kernels implementations such as L4Ka::Pistachio seem to
perform much better than first-generation ukernels), but it's probably
worth paying this price to have highly customizable system.

GNU Emacs is a good example: it may be slower and bigger than Vim but
offers a much higher degree of configuration. ;)

Ludovic.

On Mon, Oct 27, 2003 at 01:53:58PM +0100, Martin Schaffner wrote:
> I have two questions:
> 
> 1) Performance:
> 
> In 06/04/2001, "sjames" wrote on slashdot
> (http://slashdot.org/comments.pl?sid=11531&cid=310196):
> 
> > The biggest problem for microkernels is that they have to switch
> > contexts far more frequently than a monokernel (in general).
> >
> > For a simple example, a user app making a single system call. In a
> > monokernel, The call is made. The process transitions from the user to
> > the kernel ring (ring 3 to ring 0 for x86). The kernel copys any data
> > and parameters (other than what would fit into registers) from
> > userspace, handles the call, possably copies results back to
> > userspace, and transitions back to ring3 (returns).
> >
> > In a microkernel, the app makes a call, switch to ring 0, copy data,
> > change contexts, copy data to daemon, transition to ring3 in server
> > daemon's context, server daemon handles call, transitions to ring 0,
> > data copied to kernelspace, change contexts back to user process, copy
> > results into user space, transition back to ring3 (return).
> >
> 
> Am I right in thinking that a syscall on hurd/l4 would work differently?
> If i understand correctly, it would work like this (example: reading data
> from a file):
> 
> The app has previously aquired a capability for the file it wants to read,
> and allocated a buffer. When it calls "read", the glibc function makes an RPC
> directly to the filesystem translator (no going to ring 0, assuming the
> translator is owned by the same user as the calling process), which in turn 
> RPCs
> the driver of the backing store (will probably reside in ring 0) for the data.
> 
> Assuming zero-copy, there is a minimum of data copying, but there are still
> four context switches, which can't be done with super-fast IPCs, since they
> concern three different processes (app, translator, driver).
> 
> Is it likely that l4/hurd will be slower than linux, for things like
> filesystem operations?
> 
> 
> 2) Translators on linux
> 
> In 12/04/1999, Marcus Brinkmann wrote on help-hurd
> (http://www.geocrawler.com/mail/msg.php3?msg_id=2949290&list=333):
> 
> > > make more useful translators. Then either Linux will switch to
> > > translators or we will swich to not using Linux.
> > > This is the greatest idea of Hurd, but not widely used yot.
> > > And its already partially implemented in Linux
> >
> > I don`t think it is feasible to add this to Linux, especially if you
> > consider security issues.
> >
> 
> Does this mean that the Linux Userland Filesystem
> (http://lufs.sourceforge.net/lufs/intro.html) poses security risks?
> 
> 
> 
> Thanks,
> Martin
> 
> 
> -- 
> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
> 
> Jetzt kostenlos anmelden unter http://www.gmx.net
> 
> +++ GMX - die erste Adresse für Mail, Message, More! +++
> 
> 
> 
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/l4-hurd