At Thu, 09 Apr 2015 10:36:23 +0200,
Richard Weinberger wrote:
>
> Am 31.03.2015 um 09:47 schrieb Hajime Tazaki:
> > right now arch/lib/Makefile isn't fully on the Kbuild
> > system: build file dependency is not tracked at all.
> >
> > while I should learn more about Kbuild, I'd be happy if you
At Thu, 09 Apr 2015 10:36:23 +0200,
Richard Weinberger wrote:
Am 31.03.2015 um 09:47 schrieb Hajime Tazaki:
right now arch/lib/Makefile isn't fully on the Kbuild
system: build file dependency is not tracked at all.
while I should learn more about Kbuild, I'd be happy if you
would
Am 31.03.2015 um 09:47 schrieb Hajime Tazaki:
> right now arch/lib/Makefile isn't fully on the Kbuild
> system: build file dependency is not tracked at all.
>
> while I should learn more about Kbuild, I'd be happy if you
> would suggest how the Makefile should be.
You definitely have to use
Am 31.03.2015 um 09:47 schrieb Hajime Tazaki:
right now arch/lib/Makefile isn't fully on the Kbuild
system: build file dependency is not tracked at all.
while I should learn more about Kbuild, I'd be happy if you
would suggest how the Makefile should be.
You definitely have to use Kbuild.
Hajime Tazaki writes:
> is it the following ? it's really cool stuff !
>
> https://github.com/rustyrussell/pettycoin/blob/master/test/mockup.sh
Yep. It's ugly, but it Works For Me(TM).
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hajime Tazaki taz...@wide.ad.jp writes:
is it the following ? it's really cool stuff !
https://github.com/rustyrussell/pettycoin/blob/master/test/mockup.sh
Yep. It's ugly, but it Works For Me(TM).
Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Thanks Rusty,
At Wed, 01 Apr 2015 11:59:39 +1030,
Rusty Russell wrote:
>
> Hajime Tazaki writes:
> > the issue here is the decision between 'no-ops' and
> > 'assert(false)' depends on the context. an auto-generated
> > mechanism needs some hand-written parameters I think.
>
> Yes, I used
Thanks Rusty,
At Wed, 01 Apr 2015 11:59:39 +1030,
Rusty Russell wrote:
Hajime Tazaki taz...@sfc.wide.ad.jp writes:
the issue here is the decision between 'no-ops' and
'assert(false)' depends on the context. an auto-generated
mechanism needs some hand-written parameters I think.
Yes,
Hajime Tazaki writes:
> the issue here is the decision between 'no-ops' and
> 'assert(false)' depends on the context. an auto-generated
> mechanism needs some hand-written parameters I think.
Yes, I used auto-generated (fprintf, abort) stubs for similar testing in
pettycoin, where if it failed
At Mon, 30 Mar 2015 08:41:52 +0200,
Richard Weinberger wrote:
> > one more concern on the out-of-arch-tree design is that how
> > to handle our asm-generic-based header files
> > (arch/lib/include/asm). we have been heavily used
> > 'generic-y' in the Kbuild file to reuse header files.
>
> As
At Mon, 30 Mar 2015 08:41:52 +0200,
Richard Weinberger wrote:
one more concern on the out-of-arch-tree design is that how
to handle our asm-generic-based header files
(arch/lib/include/asm). we have been heavily used
'generic-y' in the Kbuild file to reuse header files.
As noted
Hajime Tazaki taz...@sfc.wide.ad.jp writes:
the issue here is the decision between 'no-ops' and
'assert(false)' depends on the context. an auto-generated
mechanism needs some hand-written parameters I think.
Yes, I used auto-generated (fprintf, abort) stubs for similar testing in
pettycoin,
Am 29.03.2015 um 17:06 schrieb Hajime Tazaki:
>> What about putting libos into tools/testing/ and make it much more generic
>> and framework alike.
>
> it's trivial though, libos is not only for the testing (i.e., NUSE).
> # of course tools/libos or something can be the place.
Yep, tool/libos
Am 29.03.2015 um 17:06 schrieb Hajime Tazaki:
What about putting libos into tools/testing/ and make it much more generic
and framework alike.
it's trivial though, libos is not only for the testing (i.e., NUSE).
# of course tools/libos or something can be the place.
Yep, tool/libos is also
Am 29.03.2015 um 18:59 schrieb Antti Kantee:
> On 28/03/15 21:17, Richard Weinberger wrote:
>> Am 27.03.2015 um 16:17 schrieb Antti Kantee:
>>> Let me try to offer some insight. I've been working on something similar
>>> in mainline NetBSD for almost 8 years now, so in addition to ideas popping
On 28/03/15 21:17, Richard Weinberger wrote:
Am 27.03.2015 um 16:17 schrieb Antti Kantee:
Let me try to offer some insight. I've been working on something similar in
mainline NetBSD for almost 8 years now, so in addition to ideas popping into my
head I've also tested
them out in the real
Am 29.03.2015 um 17:36 schrieb Hajime Tazaki:
>
>
> At Sat, 28 Mar 2015 22:17:40 +0100,
> Richard Weinberger wrote:
>
>>> Continuous testing is paramount. Running the kernel as
>>> a lib provides an unparalleled method for testing most of
>>> the kernel. It will improve testing capabilities
At Sat, 28 Mar 2015 22:17:40 +0100,
Richard Weinberger wrote:
> > Continuous testing is paramount. Running the kernel as
> > a lib provides an unparalleled method for testing most of
> > the kernel. It will improve testing capabilities
> > dramatically,
> > and on the flipside it will keep
Hi Richard,
At Fri, 27 Mar 2015 10:21:59 +0100,
Richard Weinberger wrote:
> Just an idea popping out of my head...
>
> What about putting libos into tools/testing/ and make it much more generic
> and framework alike.
it's trivial though, libos is not only for the testing (i.e., NUSE).
# of
Hi Richard,
At Fri, 27 Mar 2015 10:21:59 +0100,
Richard Weinberger wrote:
Just an idea popping out of my head...
What about putting libos into tools/testing/ and make it much more generic
and framework alike.
it's trivial though, libos is not only for the testing (i.e., NUSE).
# of
At Sat, 28 Mar 2015 22:17:40 +0100,
Richard Weinberger wrote:
Continuous testing is paramount. Running the kernel as
a lib provides an unparalleled method for testing most of
the kernel. It will improve testing capabilities
dramatically,
and on the flipside it will keep the libos
Am 29.03.2015 um 17:36 schrieb Hajime Tazaki:
At Sat, 28 Mar 2015 22:17:40 +0100,
Richard Weinberger wrote:
Continuous testing is paramount. Running the kernel as
a lib provides an unparalleled method for testing most of
the kernel. It will improve testing capabilities
dramatically,
Am 29.03.2015 um 18:59 schrieb Antti Kantee:
On 28/03/15 21:17, Richard Weinberger wrote:
Am 27.03.2015 um 16:17 schrieb Antti Kantee:
Let me try to offer some insight. I've been working on something similar
in mainline NetBSD for almost 8 years now, so in addition to ideas popping
into my
On 28/03/15 21:17, Richard Weinberger wrote:
Am 27.03.2015 um 16:17 schrieb Antti Kantee:
Let me try to offer some insight. I've been working on something similar in
mainline NetBSD for almost 8 years now, so in addition to ideas popping into my
head I've also tested
them out in the real
Am 27.03.2015 um 16:17 schrieb Antti Kantee:
> Let me try to offer some insight. I've been working on something similar in
> mainline NetBSD for almost 8 years now, so in addition to ideas popping into
> my head I've also tested
> them out in the real world. I do think that all operating
Am 27.03.2015 um 16:17 schrieb Antti Kantee:
Let me try to offer some insight. I've been working on something similar in
mainline NetBSD for almost 8 years now, so in addition to ideas popping into
my head I've also tested
them out in the real world. I do think that all operating systems
On 27/03/15 09:21, Richard Weinberger wrote:
Am 27.03.2015 um 07:34 schrieb Hajime Tazaki:
it (arch/lib) is a hardware-independent architecture which
provides necessary features to the remainder of kernel code,
isn't it ?
The stuff in arch/ is the code to glue the kernel to
a specific piece
Am 27.03.2015 um 07:34 schrieb Hajime Tazaki:
>>> it (arch/lib) is a hardware-independent architecture which
>>> provides necessary features to the remainder of kernel code,
>>> isn't it ?
>>
>> The stuff in arch/ is the code to glue the kernel to
>> a specific piece of hardware.
>> Your code does
Hi Richard,
At Thu, 26 Mar 2015 19:55:06 +0100,
Richard Weinberger wrote:
> >> feeling that "lib" is the wrong name.
> >> It has not much do to with an architecture.
> >
> > could you care to elaborate your feeling more explicitly ?
> >
> > what is an architecture here and what is _not_ an
>
Hi Rusty,
At Fri, 27 Mar 2015 14:01:22 +1030,
Rusty Russell wrote:
>
> Richard Weinberger writes:
> > This also infers that arch/lib will be broken most of the time as
> > every time the networking stack references a new symbol it
> > has to be duplicated into arch/lib.
> >
> > But this does
Hi Richard,
At Thu, 26 Mar 2015 19:55:06 +0100,
Richard Weinberger wrote:
feeling that lib is the wrong name.
It has not much do to with an architecture.
could you care to elaborate your feeling more explicitly ?
what is an architecture here and what is _not_ an
architecture ?
Hi Rusty,
At Fri, 27 Mar 2015 14:01:22 +1030,
Rusty Russell wrote:
Richard Weinberger rich...@nod.at writes:
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
has to be duplicated into arch/lib.
But this does
Am 27.03.2015 um 07:34 schrieb Hajime Tazaki:
it (arch/lib) is a hardware-independent architecture which
provides necessary features to the remainder of kernel code,
isn't it ?
The stuff in arch/ is the code to glue the kernel to
a specific piece of hardware.
Your code does something
On 27/03/15 09:21, Richard Weinberger wrote:
Am 27.03.2015 um 07:34 schrieb Hajime Tazaki:
it (arch/lib) is a hardware-independent architecture which
provides necessary features to the remainder of kernel code,
isn't it ?
The stuff in arch/ is the code to glue the kernel to
a specific piece
Am 27.03.2015 um 04:49 schrieb Geert Uytterhoeven:
> On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell wrote:
>> Richard Weinberger writes:
>>> This also infers that arch/lib will be broken most of the time as
>>> every time the networking stack references a new symbol it
>>> has to be duplicated
On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell wrote:
> Richard Weinberger writes:
>> This also infers that arch/lib will be broken most of the time as
>> every time the networking stack references a new symbol it
>> has to be duplicated into arch/lib.
>>
>> But this does not mean that your idea
Richard Weinberger writes:
> This also infers that arch/lib will be broken most of the time as
> every time the networking stack references a new symbol it
> has to be duplicated into arch/lib.
>
> But this does not mean that your idea is bad, all I want to say that
> I'm not sure whether
Hi!
Am 26.03.2015 um 17:24 schrieb Hajime Tazaki:
> thank you for your deep review on the source code !
>
>> feeling that "lib" is the wrong name.
>> It has not much do to with an architecture.
>
> could you care to elaborate your feeling more explicitly ?
>
> what is an architecture here and
Hi Richard,
At Wed, 25 Mar 2015 23:50:23 +0100,
Richard Weinberger wrote:
>
> Hi!
>
> Am 25.03.2015 um 15:48 schrieb Hajime Tazaki:
> >
> > At Tue, 24 Mar 2015 16:27:51 +0100,
> > Richard Weinberger wrote:
> >>
> >> I'd say you should try hard to re-use/integrate your work in arch/um.
> >>
Richard Weinberger rich...@nod.at writes:
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
has to be duplicated into arch/lib.
But this does not mean that your idea is bad, all I want to say that
I'm not sure whether
Am 27.03.2015 um 04:49 schrieb Geert Uytterhoeven:
On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Richard Weinberger rich...@nod.at writes:
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
On Fri, Mar 27, 2015 at 4:31 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Richard Weinberger rich...@nod.at writes:
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
has to be duplicated into arch/lib.
But this does
Hi Richard,
At Wed, 25 Mar 2015 23:50:23 +0100,
Richard Weinberger wrote:
Hi!
Am 25.03.2015 um 15:48 schrieb Hajime Tazaki:
At Tue, 24 Mar 2015 16:27:51 +0100,
Richard Weinberger wrote:
I'd say you should try hard to re-use/integrate your work in arch/um.
With um we already
Hi!
Am 26.03.2015 um 17:24 schrieb Hajime Tazaki:
thank you for your deep review on the source code !
feeling that lib is the wrong name.
It has not much do to with an architecture.
could you care to elaborate your feeling more explicitly ?
what is an architecture here and what is
Hi!
Am 25.03.2015 um 15:48 schrieb Hajime Tazaki:
>
> At Tue, 24 Mar 2015 16:27:51 +0100,
> Richard Weinberger wrote:
>>
>> I'd say you should try hard to re-use/integrate your work in arch/um.
>> With um we already have an architecture which targets userspace,
>> having two needs a very good
At Tue, 24 Mar 2015 16:27:51 +0100,
Richard Weinberger wrote:
>
> I'd say you should try hard to re-use/integrate your work in arch/um.
> With um we already have an architecture which targets userspace,
> having two needs a very good justification.
in addition to the case of my previous email,
At Tue, 24 Mar 2015 16:27:51 +0100,
Richard Weinberger wrote:
I'd say you should try hard to re-use/integrate your work in arch/um.
With um we already have an architecture which targets userspace,
having two needs a very good justification.
in addition to the case of my previous email,
Hi!
Am 25.03.2015 um 15:48 schrieb Hajime Tazaki:
At Tue, 24 Mar 2015 16:27:51 +0100,
Richard Weinberger wrote:
I'd say you should try hard to re-use/integrate your work in arch/um.
With um we already have an architecture which targets userspace,
having two needs a very good
Am 24.03.2015 um 16:24 schrieb Hajime Tazaki:
> I was thinking that such 'architectural' differences in core
> idea (like system call handling, execution model, process
> context design, etc) is better to have a different architecture
> even if some part of the code is similar.
>
> Isn't it also
At Tue, 24 Mar 2015 15:32:05 +0100,
Richard Weinberger wrote:
>
> Am 24.03.2015 um 15:25 schrieb Hajime Tazaki:
> > At Tue, 24 Mar 2015 14:21:49 +0100,
> > Richard Weinberger wrote:
> >>
> >> Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
> >> > == More information ==
> >>>
> >>> The crucial
Am 24.03.2015 um 15:25 schrieb Hajime Tazaki:
> At Tue, 24 Mar 2015 14:21:49 +0100,
> Richard Weinberger wrote:
>>
>> Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
>> > == More information ==
>>>
>>> The crucial difference between UML (user-mode linux) and this approach
>>> is that we allow
Hi,
thanks for your comment.
At Tue, 24 Mar 2015 14:21:49 +0100,
Richard Weinberger wrote:
>
> Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
> > == More information ==
> >
> > The crucial difference between UML (user-mode linux) and this approach
> > is that we allow multiple network stack
Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
> == More information ==
>
> The crucial difference between UML (user-mode linux) and this approach
> is that we allow multiple network stack instances to co-exist within a
> single process with dlmopen(3) like linking for easy debugging.
Is this
This is an introduction of library operating system (LibOS) for Linux.
Our objective is to build the kernel network stack as a shared library
that can be linked to by userspace programs to provide network stack
personalization and testing facilities, and allow researchers to more
easily simulate
This is an introduction of library operating system (LibOS) for Linux.
Our objective is to build the kernel network stack as a shared library
that can be linked to by userspace programs to provide network stack
personalization and testing facilities, and allow researchers to more
easily simulate
Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
== More information ==
The crucial difference between UML (user-mode linux) and this approach
is that we allow multiple network stack instances to co-exist within a
single process with dlmopen(3) like linking for easy debugging.
Is this the
Hi,
thanks for your comment.
At Tue, 24 Mar 2015 14:21:49 +0100,
Richard Weinberger wrote:
Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
== More information ==
The crucial difference between UML (user-mode linux) and this approach
is that we allow multiple network stack instances
Am 24.03.2015 um 16:24 schrieb Hajime Tazaki:
I was thinking that such 'architectural' differences in core
idea (like system call handling, execution model, process
context design, etc) is better to have a different architecture
even if some part of the code is similar.
Isn't it also the
At Tue, 24 Mar 2015 15:32:05 +0100,
Richard Weinberger wrote:
Am 24.03.2015 um 15:25 schrieb Hajime Tazaki:
At Tue, 24 Mar 2015 14:21:49 +0100,
Richard Weinberger wrote:
Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
== More information ==
The crucial difference between UML
Am 24.03.2015 um 15:25 schrieb Hajime Tazaki:
At Tue, 24 Mar 2015 14:21:49 +0100,
Richard Weinberger wrote:
Am 24.03.2015 um 14:10 schrieb Hajime Tazaki:
== More information ==
The crucial difference between UML (user-mode linux) and this approach
is that we allow multiple network stack
60 matches
Mail list logo
