Bas Wijnen | 1 Nov 10:14 2004
Picon

Re: Questions

Sam Mason wrote:
> An interesting discussion then becomes how do we determine the
> permissions of everything?  We probably don't want remote users to be
> able to talk to whatever device was just plugged in.  But I guess this
> isn't anything of great immediate interest as it should be easy to
> leave this sort of policy till much later.

This problem is already solved in the Hurd on Mach.  The actual device 
drivers are translators on files.  A translator can only be started by 
the owner of a file.  By default, users will only follow translators 
owned by themselves or root.  If you want to use someone elses 
translator, you have to specifically say so, otherwise you end up 
accessing the file it connects to.

This is especially important for root, who doesn't want to risk 
executing user code every time an operation on untrusted files is 
performed.  The programs are still executed by the running user, which 
is root.

Thanks,
Bas
_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd
Sam Mason | 1 Nov 16:55 2004

Re: Questions about copy-on-write

Sam Mason wrote:
>I'll see if I can rewrite it so it makes [a bit more] sense to me.

I've included a few paragraphs I've managed to get together.
I don't think they're particularly amazing, but I was wondering if
it makes any sense to continue with it?

I don't really understand the capability stuff or how pages are
added/removed from a container so I've kind of glossed over those
bits for now.

I don't really understand the mechanics of how you give another
task a capability.

And I don't understand what capabilities are required to do a
"logical" copy of pages in a container.  Is the "access" capability
enough to do this and if so how to you create a container whose
contents are read-only?  or isn't that what containers are for and
you'd actually use some other mechanism to accomplish this?

Thanks,
  Sam
Attachment (hurd.tex): application/x-tex, 4309 bytes
_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd
(Continue reading)

Sam Mason | 1 Nov 18:04 2004

Problems compiling CVS HEAD

Just got an updated version of the code and I'm having toruble
compiling it.  There seems to be some ambiguity between the copy of
"bits/atomic.h" it should pull in.  There appears to be a version 
in "platform/atomic.h" as well as the copy that it wants, which
appears to be "libpthread/sysdeps/[arch]/bits/atomic.h" which is
getting ignored on my system.

Not sure what a good fix for this is, but one that comes to mind
is renaming the "bits" directory in "libpthread/sysdeps/[arch]/"
to "pthread-bits".  Not sure though as I don't really know what's
going on with all this stuff.

Cheers,
 Sam
Marcus Brinkmann | 1 Nov 20:58 2004
Picon

Re: Problems compiling CVS HEAD

At Mon, 1 Nov 2004 17:04:12 +0000,
Sam Mason <mason <at> f2s.com> wrote:
> 
> Just got an updated version of the code and I'm having toruble
> compiling it.  There seems to be some ambiguity between the copy of
> "bits/atomic.h" it should pull in.

Update again, I just fixed it a couple of hours ago.

> Not sure what a good fix for this is, but one that comes to mind
> is renaming the "bits" directory in "libpthread/sysdeps/[arch]/"
> to "pthread-bits".  Not sure though as I don't really know what's
> going on with all this stuff.

The atomic.h from glibc, which I put into platform, is the one to use.
I changed pthread to use it.

Before we know which parts end up to be in glibc, and which not, and
what the dependencies are, these things will naturally be a bit messy
and vague.  But at least the atomic.h in platform is from current
glibc, and available for quite some architectures (nptl also uses it).

I am right now in the process of fixing the code to not break strict
aliasing rules (even though current gcc won't do global optimization,
but it's better to get it right from the beginning).  After that,
there are some changes to the task server I have not committed yet.

Thanks,
Marcus
(Continue reading)

Sam Mason | 1 Nov 21:32 2004

Re: Problems compiling CVS HEAD

Marcus Brinkmann wrote:
>Update again, I just fixed it a couple of hours ago.

OK, I waited a few hours and did a couple of updates and it was still
broken so concluded that something was missed. . .  Seems to build OK
now though!

>> Not sure what a good fix for this is, but one that comes to mind
>> is renaming the "bits" directory in "libpthread/sysdeps/[arch]/"
>> to "pthread-bits".  Not sure though as I don't really know what's
>> going on with all this stuff.
>
>The atomic.h from glibc, which I put into platform, is the one to use.
>I changed pthread to use it.

OK, the definitions in the two files did seem to mirror each other
somewhat.

>Before we know which parts end up to be in glibc, and which not, and
>what the dependencies are, these things will naturally be a bit messy
>and vague.  But at least the atomic.h in platform is from current
>glibc, and available for quite some architectures (nptl also uses it).

Interesting to know - it'll be interesting to watch the migration!

>I am right now in the process of fixing the code to not break strict
>aliasing rules (even though current gcc won't do global optimization,
>but it's better to get it right from the beginning).  After that,
>there are some changes to the task server I have not committed yet.

(Continue reading)

Sam Mason | 2 Nov 01:01 2004

Booting Hurd-L4 under qemu

Marcus Brinkmann wrote:
>I use qemu.

Just tried qemu but haven't had as much luck as with bochs.  I've
tried both the latest relased and CVS versions of qemu with the disk
image I was using with bochs to no avail.  P2-mate (on IRC)
reccommended trying compiling Pistachio for an i586 processor.  It
does a little better now and Pistachio boots, but Sigma0 dies with
"s0: no page-size mask" - I'm guessing this comes from Sigma0 as the
binary contains that string!  The IP also verifies this; eip=00041344
when it dies and I get this boot message:

  Sigma0: Low 0x40000, High 0x483a0, IP 0x41950, SP 0x0

Any ideas on what I've got wrong?

Thanks,
  Sam
Rian Hunter | 2 Nov 01:33 2004
Picon

Re: Booting Hurd-L4 under qemu

Sam Mason wrote:

>Marcus Brinkmann wrote:
>  
>
>>I use qemu.
>>    
>>
>
>Just tried qemu but haven't had as much luck as with bochs.  I've
>tried both the latest relased and CVS versions of qemu with the disk
>image I was using with bochs to no avail.  P2-mate (on IRC)
>reccommended trying compiling Pistachio for an i586 processor.  It
>does a little better now and Pistachio boots, but Sigma0 dies with
>"s0: no page-size mask" - I'm guessing this comes from Sigma0 as the
>binary contains that string!  The IP also verifies this; eip=00041344
>when it dies and I get this boot message:
>
>  Sigma0: Low 0x40000, High 0x483a0, IP 0x41950, SP 0x0
>
>Any ideas on what I've got wrong?
>  
>
Hmm, well first the stack pointer is (SP) is 0x0, and that isn't exactly 
right. Also that error comes only if the PageSizeMask field of the KIP 
is empty and it really really shouldn't be. How are you booting? Try a 
standard L4 boot just to see if your kernel and userland apps were 
compiled correctly, in grub:

--
(Continue reading)

Marcus Brinkmann | 2 Nov 01:35 2004
Picon

Re: Questions about copy-on-write

At Mon, 1 Nov 2004 15:55:25 +0000,
Sam Mason <mason <at> f2s.com> wrote:
> I've included a few paragraphs I've managed to get together.

I've read them, and they are very clear and pretty accurate.  I won't
go into nitpicking here.

> I don't think they're particularly amazing, but I was wondering if
> it makes any sense to continue with it?

Depends on what you are aiming at.  What should the end result be?

> I don't really understand the capability stuff or how pages are
> added/removed from a container so I've kind of glossed over those
> bits for now.

Pages are added/removed with RPCs to physmem (ie, some
container_allocate function).  If you have specific questions, ask.

> I don't really understand the mechanics of how you give another
> task a capability.

The basic process is simple enough: You tell the server which cap
should be given to which task, and then you tell the task about the
"box ID" that identifies the transaction.  The receiving task then
calls the server to proceed with the transaction, and replies to the
sender so that the transaction box can be removed.

The description in the manual is a bit stale, but still very
applicable.  If you have specific questions, you know the drill :)
(Continue reading)

Sam Mason | 2 Nov 02:26 2004

Re: Booting Hurd-L4 under qemu

Rian Hunter wrote:
>Hmm, well first the stack pointer is (SP) is 0x0, and that isn't 
>exactly right.

Now you point it out (for some reason didn't notice it before - maybe
because it's zero) it doesn't look very happy does it.

>Also that error comes only if the PageSizeMask 
>field of the KIP is empty and it really really shouldn't be. How 
>are you booting?

How should I be booting?  It's coming off a disk image with an ext2
partition in it with grub installed.  Grub's configuration is a
copy/paste out of the README - I don't know what I'm doing enough yet
to change anything!

>Try a standard L4 boot just to see if your 
>kernel and userland apps were compiled correctly, in grub:

Both grabmem and pingpong appear to work as I'd expect under bochs.
I.e. grabmem says got some memory and pingpong lets me do some IPC
benchmarking.  But when running under qemu they both fail with the
same "s0: no page-size mask".

>What I would do is set the debug flag in the sigma0 source: (Line 
>49 in sigma0.cc, set verbose to > 0), make a clean build, then 
>seeing what sigma0 says about its KIP when it is booting before 
>it gets to init_mempool(). If that gives you no luck, also check 
>the code the is filing the KIP in the kernel. If all else fails, 
>get version 0.4 of Pistachio, do a clean build for the Pentium 
(Continue reading)

Sam Mason | 2 Nov 02:58 2004

Re: Questions about copy-on-write

Marcus Brinkmann wrote:
>> I don't think they're particularly amazing, but I was wondering if
>> it makes any sense to continue with it?
>
>Depends on what you are aiming at.  What should the end result be?

How about something that's useful to help someone else get started
with the project slightly easier.  Or is it actually more helpful
people asking lots of random questions at the moment?

>If you have specific questions, ask.

You answered the questions below!

>> I don't really understand the mechanics of how you give another
>> task a capability.
>
>The basic process is simple enough: You tell the server which cap
>should be given to which task, and then you tell the task about the
>"box ID" that identifies the transaction.  The receiving task then
>calls the server to proceed with the transaction, and replies to the
>sender so that the transaction box can be removed.

OK

>The description in the manual is a bit stale, but still very
>applicable.  If you have specific questions, you know the drill :)

Couldn't find the bit in the manual for some reason. . .  I've just
had another look and found it!
(Continue reading)


Gmane