Re: mailing list

Sorry for the late reaction.  As far as I am concerned you are both very 
welcome help.  If I hear no objections before monday, I'll add you to 
the admin list.

Thanks!
Bas

Alfred M. Szmidt wrote:
 > Bas, Johan, if you need any help in moderating, then I can help and
 > pitch in a bit.

Arthur Ulfeldt wrote:
> I also am interested in maintaining mailing list, i will even moderate
> it, so as to not propagate evil spam!

--

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: capabilities and client ids

At Wed, 01 Dec 2004 00:28:09 +0100,
Marcus Brinkmann wrote:
> 
> At Mon, 29 Nov 2004 10:34:56 +0000,
> Neal H. Walfield wrote:
> > As I understand client IDs, the entry that a server allocates in the
> > current bucket's client_entry array serves as a client's client ID.
> 
> The client ID is, from the outside point of the system, just a token
> of identification that the client provides.

As we discussed off line these are semantics that a server may
introduce to a capability handle.  As far as a client is concerned, a
capability handle is an opaque work.  It so happens that the current
libhurd-cap-server separates the capability handle into a client id
and a capability id, however, this is only useful for the server.
This change was introduced in hurd and libhurd-cap-server.  The start
of the ChangeLog for the latter is:

2004-12-01  Neal H. Walfield  <neal <at> gnu.org>

        * cap-server-intern.h (_HURD_CAP_CLIENT_ID_BITS): Move from
        ../hurd/types.h.  Prepend underscore and update names in
        definition as needed.

> Maybe the best argument in favor of encoding the client ID in the word
> specifiying the capability is that it allows for different
> implementations, while relying on the task ID restricts what you can
> do in the server.  Even if we were to choose to use the task ID as the
> client ID in the implementation, I would insist on passing the client

Re: capabilities and client ids

> However, it does mean that we can unify the client entry
> (_hurd_cap_client_entry_t) and client (_hurd_cap_client_t) data
> structures thereby eliminating a level of indirection.  The attached
> patch does this.  Let me know if it is all right.
> 
> 2004-12-01  Neal H. Walfield  <neal <at> gnu.org>
> 
> 	* cap-server-intern.h (struct _hurd_cap_client): Fold the struct
> 	_hurd_cap_client_entry into the struct _hurd_cap_client.
> 	* bucket-create.c (_hurd_cap_client_death): Change all uses of
> 	_hurd_cap_client_entry_t to use the merged _hurd_cap_client_t.
> 	(hurd_cap_bucket_create): Likewise.
> 	* bucket-manage-mt.c (lookup_client): Likewise.
> 	* client-create.c (_hurd_cap_client_create): Likewise.
> 	* client-release.c (_hurd_cap_client_release): Likewise.

Based on private discussion with marcus, I have checked this in.

[Fwd: Re: mailing list]

Both are added to the list of administrators.

-------- Original Message --------
Subject: Re: mailing list
Date: Wed, 01 Dec 2004 14:51:16 +0100
From: Bas Wijnen <b.wijnen <at> phys.rug.nl>
To: Arthur Ulfeldt <arthur <at> ulfeldt.com>,  ams <at> kemisten.nu
CC: l4-hurd <at> gnu.org
References: <419ECF74.1040201 <at> ulfeldt.com>

Sorry for the late reaction.  As far as I am concerned you are both very
welcome help.  If I hear no objections before monday, I'll add you to
the admin list.

Thanks!
Bas

Alfred M. Szmidt wrote:
  > Bas, Johan, if you need any help in moderating, then I can help and
  > pitch in a bit.

Arthur Ulfeldt wrote:
> I also am interested in maintaining mailing list, i will even moderate
> it, so as to not propagate evil spam!

--

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.

duplicate flag checks

Hi there,

I was kinda wondering about some of the laden code, more specifically in 
the ia32-cmain.c file. In the cmain function I'm seeing this:
if (!CHECK_FLAG (mbi->flags, 0) && !CHECK_FLAG (mbi->flags, 6))
     panic ("Bootloader did not provide a memory map");

But then later on in the find_components and debug_dump functions I see 
the exact same checks.  So maybe I'm missing something here, but why not 
just check them once and be done with it?  Or maybe the reasoning is 
that the compiler will just optimize it all away anyway?

Any insight into this would be appreciated.

Thanks,
Glen

Re: duplicate flag checks

> I was kinda wondering about some of the laden code, more specifically in 
> the ia32-cmain.c file. In the cmain function I'm seeing this:
> if (!CHECK_FLAG (mbi->flags, 0) && !CHECK_FLAG (mbi->flags, 6))
>      panic ("Bootloader did not provide a memory map");
> 
> But then later on in the find_components and debug_dump functions I see 
> the exact same checks.  So maybe I'm missing something here, but why not 
> just check them once and be done with it?  Or maybe the reasoning is 
> that the compiler will just optimize it all away anyway?

They are not exactly the same checks.  The first check makes sure that
at least one of flag 0 and flag 6 is set.  The code in find_components
does some things if flag 6 is set, if not and flag 0 is set (which it
must be according to the above check) then it does some others..
Arguably, we could just do:

  /* Now add what GRUB tells us.  */
  if (CHECK_FLAG (mbi->flags, 6))
    {
       ...
    }
  else
    {
       assert (CHECK_FLAGS (mbi->flags, 0));
       ...
    }

but the way it is currently written is not wrong.

Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)

Hello all,

At the start of next year FOSDEM, the most important Belgian Free
Software event will be back again. As on the previous occasions there
will also be an embedded track, for which we are looking for speakers.
All the necessary info can be found in the following call for papers.
Feel free to distribute, and tell other people about it.

3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005
===============================================================

26 - 27 February 2005, Brussels

Call for papers
----------------

The 2005 edition of FOSDEM (Free and Open Source Developers' European
Meeting; http://www.fosdem.org) will take place in Brussels, Belgium 
on 26 and 27 February 2005. For the third time, a track on Embedded 
Systems and Operating Systems will be organized. The second edition 
was quite succesful and attracted up to 150 attendants for certain
topics.

For last year's program see: 
http://www.embedded-kernel-track.org/2004/papers.html

The use of Free Software in the infrastructure of embedded systems 
is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS 
and many other Free Software components. More companies are supporting
embedded Free Software each day because of the reliability and cheap

a few typos

Sorry in advance if this isn't the appropriate place for this sort of 
thing, but I've noticed a few typos in the documentation:

Line 1110 of ipc.tex should probably read "the server remains safe from 
potential DoS attacks" and not "the server remains save from potential 
DoS attacks"

And line 433 of vmm.tex should probably be "To facilitate this..." and 
not "To facility this..."

Glen

Re: a few typos

Hi Glen,

Thanks for the report.  This is the correct place for these sorts of
reports.

I have a bunch of pending changes to both of these files and will
include theses fixes when I check them in.

Thanks,
Neal

L4-hurd

 Hi.
 Dear HURD/L4 Engeneers. Congratulations for you
enforts an courage to try GNU/OS to run.

So what is the official status of HURD on top of L4
=:questionmark:=

Is there any HURD server ported to run on top of L4
=:questionmark:=

The problems with Inter Process Comunications is fixed
=:questionmark:= and the assyncronous/syncronous
messages rewrited =:questionmark:= 
If not, what is the bigest problem to do it
=:questionmark:= 

Thank you very much

Best wishes
   Marcelo Fortes

	
	
		
_______________________________________________________ 
Yahoo! Mail - Agora com 250MB de espaço gratuito. Abra 
uma conta agora! http://br.info.mail.yahoo.com/