headers
David Leimbach | 1 Jun 01:12
Picon

Re: The need for an IDE driver

On 5/31/05, Matthieu Lemerre <racin <at> free.fr> wrote:
> Marco Gerards <metgerards <at> student.han.nl> writes:
> 
> >
> > Is it possible to use Xen?  Have you considered this option or is it
> > simply impossible?
> 
> I don't think L4 run on Xen for now -- and considering that L4 and Xen
> can do the same job, I don't think that it's likely to happen.
> 
> However, the paravirtualizations solutions on L4 seem very promising -
> I just propose to wait and see if they're mature enough.
> 
> Thanks,
> Matthieu
> 

Might be worth looking in to pre-virtualization/para-virtuatlization
"afterburner" stuff.  Supposedly this works to make a single binary
that works with L4 Linux Xen or natively.

Not sure if all of those 3 apply to what you are trying to do.

Here is the link(s):
http://l4ka.org/projects/virtualization/afterburn/
http://l4ka.org/projects/virtualization/afterburn/whitepaper.pdf

> 
> _______________________________________________
> L4-hurd mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ronald Aigner | 1 Jun 11:41
Picon
Favicon

Re: The need for an IDE driver

Salut Matthieu,

Matthieu Lemerre wrote:
> Hi,
>
> ** This could be done by having L4Linux running as a normal task,
>  launched by wortel. To do that, it seems that there is just a set of
>  interfaces (l4lxlib) to implement. This require a substancial amount
>  of work and maintainance. Moreover, it seems that it would be more
>  difficult to do this for l4linux2.6; and the l4linux project is not
>  supported anymore by the L4 team.
Let me clarify this. The L4Ka team announce that they will no longer
support their L4Linux2.4 version. The L4Linux2.6 versions from Dresden
and probably also the ones from Sydney are still maintained and will be
so for some time.

> ** L4-env and their DDE
>    (http://os.inf.tu-dresden.de/l4env/download.xml) 
There already exists an IDE driver using DDE. Downside is, that it is
currently only tested on Fiasco, that is, L4 V2.

HTH, Ron.
--

-- 
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/
Permalink | Reply | 1 comment |
headers
Neal H. Walfield | 1 Jun 19:37

Re: Mechanism to request physical memory with certain properties, new algorithm

Minus some typos in your pseudo code, this approach looks good.  A few
of comments.

We need to remember the constraints under which memory is allocated so
that should an allocation with a tighter constraint be requested, we
can relocate--should we choose--the old memory.

As a corollary, some memory can't be moved: e.g. memory which is being
used for DMA.

We need to evenly distribute allocations across physical memory.  In
this way, we avoid flooding interesting zones (i.e. the set of frames
which satisfies a common constraint e.g. memory which can be used for
DMA and memory of a particular color) and hence reduce the amount of
relocation when there is little free memory.  We could set priorities
for different memory zones but that is complicated.  Simply having a
counter in find_node and incrementing and checking the least
significant bit each time we are about to do an unconstrained recurse
to a left or right node should offer a reasonable distribution.

Finally, there should be a way to make constraints weak.  That is, the
provided constraints represent a preference (e.g. for a memory color)
but not a hard requirement.

Thanks,
Neal
Permalink | Reply | 0 comments |
headers
Matthieu Lemerre | 3 Jun 15:10
Picon
Favicon

Re: The need for an IDE driver


Hi Ronald,

Ronald Aigner <ra3 <at> os.inf.tu-dresden.de> writes:

>> ** This could be done by having L4Linux running as a normal task,
>>  launched by wortel. To do that, it seems that there is just a set of
>>  interfaces (l4lxlib) to implement. This require a substancial amount
>>  of work and maintainance. Moreover, it seems that it would be more
>>  difficult to do this for l4linux2.6; and the l4linux project is not
>>  supported anymore by the L4 team.
> Let me clarify this. The L4Ka team announce that they will no longer
> support their L4Linux2.4 version. The L4Linux2.6 versions from Dresden
> and probably also the ones from Sydney are still maintained and will be
> so for some time.

OK, Thank you. However the L4Linux2.6 project does not seem to work on
Pistachio right now, and porting it would require additional efforts.

The Wombat port of L4Linux from the National ICT Australia works on
Pistachio, but it seems that you can't use linux drivers with it for
now.

>
>> ** L4-env and their DDE
>>    (http://os.inf.tu-dresden.de/l4env/download.xml) 
> There already exists an IDE driver using DDE. Downside is, that it is
> currently only tested on Fiasco, that is, L4 V2.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
olafBuddenhagen | 5 Jun 02:00
Picon

Re: Drivers

Hi,

Thanks for all the input :-)

> > For one, with drivers at POSIX level, there is no need for a
> > sophisticated, full-featured special driver framework: Library
> > functions, loading and unloading drivers, communication amongst
> > drivers and to the outside world, configuration management/parameter
> > passing, resource management -- it's all already there, using the
> > ordinary POSIX/Hurd interfaces. All we need are a few extensions to
> > the standard POSIX/Hurd mechanisms, to allow for driver-specific
> > stuff like IRQ handling and I/O port access.
> > 
> 
> That depends on what you mean by 'POSIX level'. Drivers should be
> 'user processes', but they don't need the full POSIX functionality.
> Actually most of the posix functions are useless for driver
> programming.

Many functions are probably useless, but they do not do any harm either.
Originally I wasn't even sure about using the standard libc myself; the
proposal would work with a stripped down driver-specific library as
well. But how do you know in advance which functions really a driver
developer might want to use? Where do you draw the line between
low-level drivers using a stripped down library, and higher level stuff
using the standard libc? What about parts of a user-space UNIX program
being turned into a Hurd driver? After thinking about it a bit, I
arrived at the conclusion that unless there are some very good reasons
not to, we should use the standard libc. So far, I haven't found any
such reasons.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niels Möller | 7 Jun 18:54
Picon
Picon
Picon
Favicon

Comments on the hurd-on-l4 document

I've reread the current version of doc/hurd-on-l4, and I'd like to
post my comments and questions before I forget them again.

Section 3.3: Notifications

I think all notifications can be associated with a server state,
where notifications are sent whenever the state changes. If we focus
on death notifications, the corresponding state is the set of dead
objects that the client owns references to.

>From this point of view, robustness can be guaranteed if the client
also polls the server state occasionally, although any tricks that
let's the client know for sure that no polling is needed during long
periods of inactivity would be nice to have. One wouldn't want to page
in all clients and servers in the system once every minute just to let
them assure each other that nothing's happened.

If a client uses one thread per server it wants notifications from,
it's fairly simple:

It reduces to a loop over the function "tell me what's happened since
last time" which blocks until something actually happens, or returns
immediately if there are any changes the client hasn't heard about
before. On the client side, it is sent with infinite read and write
timeout, on the server side, it's a recv operation that just records
that the client wants to be kept informed, and a send operation that
takes place when anything interesting happens. If something happens at
the server side when the client isn't listening, the server sets a
flag, and reports this change next time the client asks (and then the
client may need further exchanges with the server to sort things out).
(Continue reading)

Permalink | Reply | 668 comments |
headers
Marcus Brinkmann | 8 Jun 14:36
Picon
Favicon

Re: Comments on the hurd-on-l4 document

Hi Niels,

great to see you still being interested and your input is as always
appreciated.  Before diving into the details eventually, I want to
give you a head start that under the surface there are some radical
changes going on that are not reflected anywhere, not in the docs, not
in the source, and also not on the mailing list.  So you couldn't know
about it (sorry about that).

The most important changes are related to the capability system.  I am
convinced by now (and I think Neal agrees) that we simply can not
feasibly implement a capability system without support by a central
authority, either the kernel via its IPC system, or a trusted
capability server.

I can not pinpoint this on a single killer argument.  There are a
couple of things, among them:

* We are violating many security aspects of a traditional capability
  system, so e can not rely on existing literature and security
  analysis.  (For example, we are leaking too much internal information).
* In upcoming L4 designs, global thread IDs will be _gone_, and our
  design will not carry over without some fundamental changes anyway.
* Capability transfer requires too much trust.  We should be able to
  accept capabilities even if they come from untrusted sources.  The
  capability transfer mechanism I designed is a pure nightmare (I have
  a race-free design, and it is horribly complicated, and can hardly
  be optimized at all).
* Task info capabilities are just an insane concept to go with in the
  first place.  They are a sad excuse for a real capability and/or
(Continue reading)

Permalink | Reply | 10 comments |
headers
Marcus Brinkmann | 8 Jun 14:48
Picon
Favicon

Re: Comments on the hurd-on-l4 document

At 07 Jun 2005 18:54:51 +0200,
Niels Möller wrote:
> Section 6.2.1: Signals
> 3. "However, in Unix, there is always a race when sending a signal
>     using kill. The task server helps the users a bit here by not
>     reusing task IDs as long as possible."
> 
> I think 3 is plain wrong. When you write kill 4711 at the shell,
> there's a race condition, but that's far from the only way to use
> signals.

This is the generic case and that's the race meant. 

> When using kill to a child process, there's no race
> condition, since one is guaranteed that the pid isn't reused until the
> parent process has called one of the wait system calls.
>
> At least this use case must be supported without any races.

True, and it will quite naturally be without a race, I guess.

> And there's one more issue I'd like to mention, and that is the
> interaction with exec.

I am not sure my understanding of the signal system is good enough to
comment on that right now ;)

> And even if we can't guarantee delivery of the signal, we need to
> provide some way for proc clients to deal with the fact that the
> signal thread for a process can change over time. We could require
(Continue reading)

Permalink | Reply | 668 comments |
headers
Niels Möller | 8 Jun 16:30
Picon
Picon
Picon
Favicon

Re: Comments on the hurd-on-l4 document

Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:

> great to see you still being interested and your input is as always
> appreciated.

Thanks. I'm browsing the list archives from time to time, to try to
see what's happening.

> Before diving into the details eventually, I want to
> give you a head start that under the surface there are some radical
> changes going on that are not reflected anywhere, not in the docs, not
> in the source, and also not on the mailing list.

Ooops ;-)

> The most important changes are related to the capability system.  I am
> convinced by now (and I think Neal agrees) that we simply can not
> feasibly implement a capability system without support by a central
> authority, either the kernel via its IPC system, or a trusted
> capability server.

It's still appealing to be able to do it with rudimentary kernel
support and all the rest locally in each task. But if the kernel
doesn't provide sufficient support, I guess the L4 way is to introduce
a central userspace server to do it (i.e. we have to figure out what
we would really like the "kernel" to do for us, and then implement
that "hurd kernel" as L4 + a bunch of extra servers).

Would all ipc go via the capability server (that would have quite
severe performance implications), or will it be used in some other
(Continue reading)

Permalink | Reply | 9 comments |
headers
Marcus Brinkmann | 8 Jun 17:32
Picon
Favicon

Re: Comments on the hurd-on-l4 document

At 08 Jun 2005 16:30:36 +0200,
Niels Möller wrote:
> Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:
> > The most important changes are related to the capability system.  I am
> > convinced by now (and I think Neal agrees) that we simply can not
> > feasibly implement a capability system without support by a central
> > authority, either the kernel via its IPC system, or a trusted
> > capability server.
> 
> It's still appealing to be able to do it with rudimentary kernel
> support and all the rest locally in each task.

Well, in my opinion there really are potentially overriding security
aspects, too.  For example, in some security models, it is an absolute
no-no to let the server know which tasks have a handle to the
capability, or even if there are any users at all, to suppress covert
channels.  There are other aspects that require consideration.

> But if the kernel
> doesn't provide sufficient support, I guess the L4 way is to introduce
> a central userspace server to do it (i.e. we have to figure out what
> we would really like the "kernel" to do for us, and then implement
> that "hurd kernel" as L4 + a bunch of extra servers).

In the end, it all boils down to a mix of kernel features, trusted
system services and local management.

> Would all ipc go via the capability server (that would have quite
> severe performance implications), or will it be used in some other
> way?
(Continue reading)

Permalink | Reply | 8 comments |

Gmane