headers
wgrim | 1 Aug 04:44
Favicon

Re: NetBSD drivers on HURD?

Hi!

Daniel, thanks for your comments.  Starting from scratch would be
easier-and-harder.  It'll be easier in the sense that I can keep the code in my
head better, but it'll be harder in the sense that I would have to start over
and rewrite a bunch of code.  I'll probably use some of your code to handle a
few things I never thought about... you seem more experienced in C/hardware
development than I am.

When it comes to libfthread, I haven't really looked at it much.  To tell the
truth, I haven't looked at deva/fabrica's code much, because I am trying to
understand the core part of the Hurd/L4 first.  However, if it's a threading
library, wouldn't it make more sense to put threading calls into deva and have
deva make the appropriate threading calls on each OS, or is libfthread necessary
to create a faster version of threading for the purpose of the device drivers?

I'm basically trying to understand about a couple things in order to reach a
possible compromise in the design:
1) If I create the threading library, I'll have to make it work on multiple
architectures, doing essentially parallel work to most OS out there.  Is it
worth me doing that?
2) Does libfthread offer an advantage over normal OS threading libraries?

Thanks for any input!

--Mike Grim
-------------------------------------------------
SIUE Web Mail
Permalink | Reply | 501 comments |
headers
Christian Helmuth | 1 Aug 09:54
Picon
Favicon

Re: Device Drivers (Which is better!)

Hello,

On Sun, Jul 31, 2005 at 12:56:00PM +0430, MT Rezaie wrote:
> Hi!
> I want to build device drivers on l4 and I found two solutions:
> 
>    - l4hurd 
>    - kenge - Iguana - Wombat 

For L4.V2/Fiasco-based systems I'd like to mention

    - L4Env (packages: serial, input, l4io)
    - Linux Device Driver Environment

Both are available from http://os.inf.tu-dresden.de/l4env/ or TU Dresden's
remote CVS http://os.inf.tu-dresden.de/drops/download.html.

> Each of theme has some device drivers but I can't decide which is better. 
> For the first phase I want drivers for serial port on x86. 
> Does anyone have any solutions about this?

Maybe L4Env's serial package could help you here.

Ciao
--

-- 
Christian Helmuth

TU Dresden, Dept. of CS
Operating Systems Group
http://os.inf.tu-dresden.de/~ch12
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Wagner | 2 Aug 15:06

Re: NetBSD drivers on HURD?

> When it comes to libfthread, I haven't really looked at it much.  To tell
> the truth, I haven't looked at deva/fabrica's code much, because I am
> trying to understand the core part of the Hurd/L4 first.  However, if it's
> a threading library, wouldn't it make more sense to put threading calls
> into deva and have deva make the appropriate threading calls on each OS, or
> is libfthread necessary to create a faster version of threading for the
> purpose of the device drivers?

The threading library provides a nicer/richer interface to the deva 
interfaces. Basically, you need to talk to the deva server from your drivers. 
This communication can be wrapped with the threading library. Note, that the 
calls to create new threads etc were also planned to go through deva to end 
up in the OS. What you described is what the library should have been...

> I'm basically trying to understand about a couple things in order to reach
> a possible compromise in the design:
> 1) If I create the threading library, I'll have to make it work on multiple
> architectures, doing essentially parallel work to most OS out there.  Is it
> worth me doing that?

If you want to have drivers for other OSes this makes sens. If you want to 
support only Hurd/L4 the answer is no.

> 2) Does libfthread offer an advantage over normal OS threading libraries?

Yes, you don't need everything, you can use a very lightweight version which 
is optimised for driver use (whatever that means).

daniel
(Continue reading)

Permalink | Reply | 502 comments |
headers
wgrim | 2 Aug 23:03
Favicon

Re: NetBSD drivers on HURD?

Okay, I'm trying to take all that in.  I've started putting together a
requirements analysis of what needs to be achieved to have a working deva/ddm
(device driver managers) implementation.

I had one question though...

When looking at the original deva/fabrica outline in the GNU/Hurd-L4 2003
document, I noticed that a lot of device managers could be loaded.  Was the
original reasoning behind this so that normal users could load their own device
managers, or was it because the superuser may run different device driver
managers for different classifications of devices?

Thanks!

--Mike

Quoting Daniel Wagner <wagi <at> monom.org>:

> > When it comes to libfthread, I haven't really looked at it much.  To tell
> > the truth, I haven't looked at deva/fabrica's code much, because I am
> > trying to understand the core part of the Hurd/L4 first.  However, if it's
> > a threading library, wouldn't it make more sense to put threading calls
> > into deva and have deva make the appropriate threading calls on each OS, or
> > is libfthread necessary to create a faster version of threading for the
> > purpose of the device drivers?
>
> The threading library provides a nicer/richer interface to the deva
> interfaces. Basically, you need to talk to the deva server from your drivers.
> This communication can be wrapped with the threading library. Note, that the
> calls to create new threads etc were also planned to go through deva to end
(Continue reading)

Permalink | Reply | 1 comment |
headers
MT Rezaie | 3 Aug 10:28
Picon

Re: Device Drivers (Which is better!)

Thank for your answer!

I found that there is some works in l4hurd (deva) and Iguana.
I know that in Iguana there is UART's driver but it's to hard to work with it, because there isn't good documentation for it.

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd
Permalink | Reply | 0 comments |
headers
Giuseppe Scrivano | 6 Aug 14:33
Picon

Update README patch for ipc.cc

This is an update for the ipc.cc patch in the README file to apply against current pistachio CVS version.
Other pieces seem to work correctly.

Regards,
Giuseppe Scrivano

--- pistachio/kernel/src/api/v4/ipc.cc.old	2005-08-06 13:56:45.000000000 +0200
+++ pistachio/kernel/src/api/v4/ipc.cc	2005-08-06 14:06:12.000000000 +0200
@@ -318,6 +318,9 @@
 		 && (current->get_space() == virt_sender->get_space() ||
 		     current->get_space() == to_tcb->get_space()))
 	    {
+    if (virt_sender->get_state().is_waiting() &&
+		    virt_sender->get_partner() == sender_id)
+		  virt_sender->set_partner(to_tid);
 		sender_id = current->get_virtual_sender();
 	    }
 	    else
@@ -339,7 +342,7 @@
 	if (EXPECT_FALSE(
 	    (!to_tcb->get_state().is_waiting())  ||
 	    (	// Not waiting for sender (may be virtual sender)?
-		to_tcb->get_partner() != sender_id &&
+    ( to_tcb->get_partner() != current->get_global_id() &&
 		// Not open wait?
 		!to_tcb->get_partner().is_anythread() &&
 		// Not open local wait?
Permalink | Reply | 0 comments |
headers
Giuseppe Scrivano | 6 Aug 15:29
Picon

Re: Update README patch for ipc.cc

oops. I forgot a ). This should work better. Sorry for the flood.

Giuseppe

--- pistachio/kernel/src/api/v4/ipc.cc.old	2005-08-06 15:06:33.000000000 +0200
+++ pistachio/kernel/src/api/v4/ipc.cc	2005-08-06 15:17:40.000000000 +0200
@@ -318,6 +318,9 @@
 		 && (current->get_space() == virt_sender->get_space() ||
 		     current->get_space() == to_tcb->get_space()))
 	    {
+    if (virt_sender->get_state().is_waiting() &&
+		    virt_sender->get_partner() == sender_id)
+		  virt_sender->set_partner(to_tid);
 		sender_id = current->get_virtual_sender();
 	    }
 	    else
@@ -339,14 +342,14 @@
 	if (EXPECT_FALSE(
 	    (!to_tcb->get_state().is_waiting())  ||
 	    (	// Not waiting for sender (may be virtual sender)?
-		to_tcb->get_partner() != sender_id &&
+    ( to_tcb->get_partner() != current->get_global_id() &&
 		// Not open wait?
 		!to_tcb->get_partner().is_anythread() &&
 		// Not open local wait?
 		!(to_tcb->get_partner().is_anylocalthread() && 
 		  to_tcb->get_space() == current->get_space()) &&
 		// Not waiting for actual sender (if propagating IPC)?
-		to_tcb->get_partner() != current->get_global_id()   )))
+               to_tcb->get_partner() != current->get_global_id()   ))))
 	{
 	    TRACE_IPC ("dest not ready (%t, is_wt=%d)\n", 
 		       to_tcb, to_tcb->get_state().is_waiting());
Permalink | Reply | 0 comments |
headers
Matthieu Lemerre | 6 Aug 19:10
Picon
Favicon

Boot protocol


Hi,

I really want your advice on this because I'm not sure of having found
a good solution, and writing a solution for this problem would be
quite long.  Let me expose the problem:

I have a basically working libhurd-cap-server for L4ng here, and I'd
like to use it in replacement in all servers.  This complicates a lot
the bootstrap procedure, because sharing a capability requires the cap
server to be running.

The current boot protocol is the following: 

* physmem is launched by wortel.  It starts up, and create a bucket.

* physmem asks wortel for all the frames containing the modules,
  creating the necessary container and giving the cap handle.

* physmem calls bootstrap_final, and wortel starts the other servers like this:

* a startup code is booted in the new address space, which requests
  physmem to map the memory in the containers.

* Then the task initialize its pager and memory management stuff.

* Then initialize its bucket, and respond to wortel askings, and so on.

There are many problems when introducing the cap server:

-You can't create a bucket when cap isn't running, nor injecting them.
 You can't create capabilities, in fact :).

-So, cap must boot on memory provided by physmem, without using
 regular RPCs.  So, physmem must provide memory to the cap
 server... This suggest for me that we have to use physmem as the
 initial pager, as was planned from what I can see.  Except that it
 can't use a special container or anything: instead the pager should
 keep track of every memory it has given, and when cap is boot up, it
 should put all this in a container and give it to cap.

-Once cap is booted, physmem would make wortel_cap_request/reply like
 calls to cap, and cap will forward them to wortel. Then, cap could
 create a cap buffer for every server, containing all the cap boxes a
 server need.  

-When the other servers boot, they make a call to cap to acquire their
 capabilities on the already-booted servers, then bootup, make their
 cap_request/reply calls to cap, then asks for the rest of the
 capabilities.  They could have a special container for using physmem
 as a pager.

What do you think of this?  Is it worth implementing this right now,
or a hack would be sufficient for now, because having this new
libhurd-cap-server is quit urgent (I guess that with capability
passing, we could begin work on swap servers or so on?)

Thanks,
Matthieu
Permalink | Reply | 1 comment |
headers
Giuseppe Scrivano | 6 Aug 21:41
Picon

libc compiling problem

I am trying to compile libc how described in hurd-l4/libc/README but I get the following problem.  Any suggestion?
My gcc -version is: gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)

Regards,
Giuseppe Scrivano 

make[5]: Entering directory `/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc/iconv'
gcc -nostdlib -nostartfiles -o
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/iconvconfig      -Wl,-z,relro
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/csu/crt1.o/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/csu/crti.o
`gcc --print-file-name=crtbegin.o`
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/iconvconfig.o
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/strtab.o
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/xmalloc.o
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/hash-string.o 
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a  -lgcc-Wl,--as-needed -lgcc_s 
-Wl,--no-as-needed /home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a -lgcc
-Wl,--as-needed -lgcc_s  -Wl,--no-as-needed `gcc --print-file-name=crtend.o` /home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/csu/crtn.o
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a(abort.o): In function `abort':
../sysdeps/generic/abort.c:131: warning: warning: _exit is not implemented and will always fail
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a(libc-start.o): In function `__libc_start_main':
../sysdeps/generic/libc-start.c:249: warning: warning: __exit_thread is not implemented and will
always fail
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/iconv/iconvconfig.o: In function `write_output':
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc/iconv/iconvconfig.c:1225: warning: warning:
fchmod is not implemented and will always fail
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc/iconv/iconvconfig.c:1232: warning: warning:
close is not implemented and will always fail
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc/iconv/iconvconfig.c:1233: warning: warning:
unlink is not implemented and will always fail
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a(tempname.o): In function `__gen_tempname':
../sysdeps/posix/tempname.c:313: warning: warning: __lxstat64 is not implemented and will always fail
/usr/bin/ld: errno: TLS definition in
/home/gscrivano/hurd/hurd-l4/withlibc/libc/libc-build/libc.a(errno.o) section .tbss
mismatches non-TLS definition in /lib/libc.so.6 section .bss
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
Permalink | Reply | 0 comments |
headers
Ludovic Courtès | 8 Aug 18:07
Picon
Picon
Favicon

Capabilities in Amoeba

Hi,

The following might already have obvious answers, but anyway: did anyone
consider a distributed, cryptography-based, capability system à la
Amoeba [1]?

In his LSM talk intro, Marcus rejected the idea of relying on
cryptography to implement capabilities arguing that this would incur too
much overhead.  Looking at how Amoeba does it, this assertion doesn't
seem so obvious.  Shapiro and the erights.org people would have been a
good source of criticism but they don't seem to mention Tanenbaum's
work.

In Amoeba, capabilities have "value semantics" and can therefore be
copied from task to task without requiring anything special.  In order
to achieve this, capabilities contain (among other things) a global port
identifier.  While L4 X.2 provides global IDs for threads, L4ng, as I
understand it, will _not_ provide any global resource ID, therefore
precluding capability implementations à la Amoeba (I understand that
global thread IDs are not always desirable, e.g. as part of a resource
name within a multi-threaded server, but that's another issue).

Amoeba capabilities also make it possible for a client owning a
capability to a remote resource to locally create from it a new one with
restricted rights (e.g. creating a read-only capability from a
read-write one).  Thanks to the cryptographic techniques being used, no
RPC is required for this.

Finally, Amoeba's capabilities contain an "object name" field "only
meaningful to the server managing the object".  In cases where the
capability-providing server is trusted, we could even imagine coding
object types as part of this object name.  This would allow for local
type identification of capability-designated resources.

I hope what I just wrote is not so trivial that it could be considered
as an offense.  ;-)  In case this has already been answered elsewhere,
could anyone refer me to the relevant documents?

Thanks and happy hacking!

Ludovic.

[1] E.g., A. Tanenbaum, "Using Sparse Capabilities in a Distributed
    Operating System".
Permalink | Reply | 0 comments |

Gmane