Re: [riot-devel] NSTF - Naming the stack

[Francesco Ermini]

Hi,
If it can help brainstorming, "non-specific"  is a synonym for generic e.g
 ns_ as "non-specific network stack".

2015-05-18 19:44 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/18/15 16:17, Oleg Hahm wrote:
> >> +1 for "generic", but do we need the abbrevation?
> >
> > Aren't you usually the one arguing for short variable names and the like?
> Yes, but "gnrc"... ;)
>
> gns (generic network stack), gn, gnet, gen, g, ... ?
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



-- 
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hey,

On 05/18/15 16:17, Oleg Hahm wrote:
>> +1 for "generic", but do we need the abbrevation?
> 
> Aren't you usually the one arguing for short variable names and the like?
Yes, but "gnrc"... ;)

gns (generic network stack), gn, gnet, gen, g, ... ?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Hauke Petersen]

Hi,

I also can live very well with gnrc aka generic.

Cheers,
Hauke

P.S. +1 for 'Google never really called' :-)


On 18.05.2015 17:56, Martine Lenders wrote:

Hi,
given that I was asked today what the "R" means in RIOT (and Thomas W. 
giving the most excellent to my "revelutionary" or "restricted": 
"RIOT") I really like gnrc. Let's find some alternative meanings for 
that! :D "Generic newly retained code"? "Great networking! RIOT 
certified"? "Google never really called [us]"?


Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm >:


Hey Kaspar!

> +1 for "generic", but do we need the abbrevation?

Aren't you usually the one arguing for short variable names and
the like?

Cheers,
Oleg
--
WHO HAS ANY ARP JOKES?

___
devel mailing list
devel@riot-os.org 
https://lists.riot-os.org/mailman/listinfo/devel




___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi,
given that I was asked today what the "R" means in RIOT (and Thomas W.
giving the most excellent to my "revelutionary" or "restricted": "RIOT") I
really like gnrc. Let's find some alternative meanings for that! :D
"Generic newly retained code"? "Great networking! RIOT certified"? "Google
never really called [us]"?

Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm :

> Hey Kaspar!
>
> > +1 for "generic", but do we need the abbrevation?
>
> Aren't you usually the one arguing for short variable names and the like?
>
> Cheers,
> Oleg
> --
> WHO HAS ANY ARP JOKES?
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hey Kaspar!

> +1 for "generic", but do we need the abbrevation?

Aren't you usually the one arguing for short variable names and the like?

Cheers,
Oleg
-- 
WHO HAS ANY ARP JOKES?


pgpGuwdlBaDTu.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

+1 for "generic", but do we need the abbrevation?

On 05/18/15 15:55, Emmanuel Baccelli wrote:
> Hi everyone,
> 
> concerning the name of the new network stack, and assuming it is not
> going to be the only network stack that RIOT hosts, here's a suggestion.
> 
> The way I see it, the goal of this network stack was/is to be generic [1]:
> - one-size-fits-most
> - flexible/configurable/extendable 
> 
> In contrast, other stacks that RIOT supports (or is about to support)
> have more specific goals, e.g.
> - OpenWSN stack (focus on 802.15.4e and 6TiSCH)
> - Kaspar's IP stack focusing on fitting the memory constraints of Class
> 0 devices
> - CCN-lite stack focusing on NDN and CCN
> 
> So how about we simply name the new network stack "the generic stack"
> and, where needed in the code, we could abbreviate the word "generic" by
> eliding the vowels from the word, which then becomes the acronym/prefix
> "gnrc". 
> 
> Somehow, we can convene that "gnrc" could/can be pronounced almost like
> the original word "generic".
> 
> Cheers,
> 
> Emmanuel 
> 
> 
> [1] Word definition from Webster dictionary:
> Generic: Very comprehensive; pertaining or appropriate to large classes
> or their characteristics; -- opposed to specific. 
> http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=generic
> 
> On Wed, May 13, 2015 at 7:28 AM, Oleg Hahm  > wrote:
> 
> Hi Ludwig!
> 
> > Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me 
> if
> > I'm wrong) of the old stack and should be upgraded to use the lower 
> layer(s)
> > of the new stack? (What about OpenWSN?) Or are those layers not 
> considered
> > part of the stack?
> 
> Yes, you're right, ccn-lite can run directly on top of Link Layer (and
> actually more or less any other layer) and should be upgraded.
> 
> OpenWSN provides a full network stack from Link to Application Layer.
> 
> > >I think we cannot compare to Linux,
> > >BSD, and
> > >the like here. They can afford to make different modules somehow
> > >interoperable
> > >at cost of memory, we cannot.
> >
> > As far as I remember, the modularization of the new stack had exactly 
> this
> > as a goal.
> 
> Yes, that's correct. However, there will - as Kaspar pointed out -
> still exist
> other stack implementations. Actually, this might be another reason
> for a
> name: if one implements a new module for this stack, one should
> indicate that
> it is compatible to stack XYZ.
> 
> Cheers,
> Oleg
> 
> --
> panic("This never returns");
> linux-2.6.6/kernel/power/swsusp.c
> 
> ___
> devel mailing list
> devel@riot-os.org 
> https://lists.riot-os.org/mailman/listinfo/devel
> 
> 
> 
> 
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Emmanuel Baccelli]

Hi everyone,

concerning the name of the new network stack, and assuming it is not going
to be the only network stack that RIOT hosts, here's a suggestion.

The way I see it, the goal of this network stack was/is to be generic [1]:
- one-size-fits-most
- flexible/configurable/extendable

In contrast, other stacks that RIOT supports (or is about to support) have
more specific goals, e.g.
- OpenWSN stack (focus on 802.15.4e and 6TiSCH)
- Kaspar's IP stack focusing on fitting the memory constraints of Class 0
devices
- CCN-lite stack focusing on NDN and CCN

So how about we simply name the new network stack "the generic stack" and,
where needed in the code, we could abbreviate the word "generic" by eliding
the vowels from the word, which then becomes the acronym/prefix "gnrc".

Somehow, we can convene that "gnrc" could/can be pronounced almost like the
original word "generic".

Cheers,

Emmanuel


[1] Word definition from Webster dictionary:
Generic: Very comprehensive; pertaining or appropriate to large classes or
their characteristics; -- opposed to specific.
http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=generic

On Wed, May 13, 2015 at 7:28 AM, Oleg Hahm  wrote:

> Hi Ludwig!
>
> > Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if
> > I'm wrong) of the old stack and should be upgraded to use the lower
> layer(s)
> > of the new stack? (What about OpenWSN?) Or are those layers not
> considered
> > part of the stack?
>
> Yes, you're right, ccn-lite can run directly on top of Link Layer (and
> actually more or less any other layer) and should be upgraded.
>
> OpenWSN provides a full network stack from Link to Application Layer.
>
> > >I think we cannot compare to Linux,
> > >BSD, and
> > >the like here. They can afford to make different modules somehow
> > >interoperable
> > >at cost of memory, we cannot.
> >
> > As far as I remember, the modularization of the new stack had exactly
> this
> > as a goal.
>
> Yes, that's correct. However, there will - as Kaspar pointed out - still
> exist
> other stack implementations. Actually, this might be another reason for a
> name: if one implements a new module for this stack, one should indicate
> that
> it is compatible to stack XYZ.
>
> Cheers,
> Oleg
>
> --
> panic("This never returns");
> linux-2.6.6/kernel/power/swsusp.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi Ludwig!

> Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if
> I'm wrong) of the old stack and should be upgraded to use the lower layer(s)
> of the new stack? (What about OpenWSN?) Or are those layers not considered
> part of the stack?

Yes, you're right, ccn-lite can run directly on top of Link Layer (and
actually more or less any other layer) and should be upgraded.

OpenWSN provides a full network stack from Link to Application Layer.

> >I think we cannot compare to Linux,
> >BSD, and
> >the like here. They can afford to make different modules somehow
> >interoperable
> >at cost of memory, we cannot.
> 
> As far as I remember, the modularization of the new stack had exactly this
> as a goal.

Yes, that's correct. However, there will - as Kaspar pointed out - still exist
other stack implementations. Actually, this might be another reason for a
name: if one implements a new module for this stack, one should indicate that
it is compatible to stack XYZ.

Cheers,
Oleg

-- 
panic("This never returns");
linux-2.6.6/kernel/power/swsusp.c


pgpUF9jUp9uHw.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Ludwig Ortmann]

Hi,

Am 12. Mai 2015 20:26:58 MESZ, schrieb Oleg Hahm :
>Hi!
>
>> what about `ipc_stack` due to its utilization of the former? But
>still: I'm
>> still not convinced of the reason to give it a name. All operating
>systems
>> have a default stack but no one is bound to use it and can use their
>> `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is
>> mainly historic, since it started out as a seperate project. As far
>as I
>> know TinyOS' stack has no name either.
>
>Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We
>have
>ccn-lite, OpenWSN, and this one.

Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm 
wrong) of the old stack and should be upgraded to use the lower layer(s) of the 
new stack? (What about OpenWSN?) Or are those layers not considered part of the 
stack?

>I think we cannot compare to Linux,
>BSD, and
>the like here. They can afford to make different modules somehow
>interoperable
>at cost of memory, we cannot.

As far as I remember, the modularization of the new stack had exactly this as a 
goal.

Cheers, Ludwig
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi!

> what about `ipc_stack` due to its utilization of the former? But still: I'm
> still not convinced of the reason to give it a name. All operating systems
> have a default stack but no one is bound to use it and can use their
> `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is
> mainly historic, since it started out as a seperate project. As far as I
> know TinyOS' stack has no name either.

Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have
ccn-lite, OpenWSN, and this one. I think we cannot compare to Linux, BSD, and
the like here. They can afford to make different modules somehow interoperable
at cost of memory, we cannot.

Won't repeat the arguments for naming.

Cheers,
Oleg
-- 
panic("huh?\n");
linux-2.2.16/arch/i386/kernel/smp.c


pgpu7qjcHC363.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hey,

what about `ipc_stack` due to its utilization of the former? But still: I'm
still not convinced of the reason to give it a name. All operating systems
have a default stack but no one is bound to use it and can use their
`ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is
mainly historic, since it started out as a seperate project. As far as I
know TinyOS' stack has no name either.

Cheers,
Martine

2015-05-12 13:02 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/12/2015 09:54 AM, Oleg Hahm wrote:
>
>> I just stumbled across ng_netconf - we should rename this to avoid
>> confusion
>> with RFC 6241 [1]. If the stack would have a name, we could simply call it
>> _conf...
>>
>
> If "nameless" sticks, we could just replace all "ng_" with "nl_" ... Until
> we port libnl, of course.
>
> Kaspar
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hey,

On 05/12/2015 09:54 AM, Oleg Hahm wrote:

I just stumbled across ng_netconf - we should rename this to avoid confusion
with RFC 6241 [1]. If the stack would have a name, we could simply call it
_conf...


If "nameless" sticks, we could just replace all "ng_" with "nl_" ... 
Until we port libnl, of course.


Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Hauke Petersen]

Hi,

Martine and me had the same discussion yesterday. Until we have a name, 
NG_NETOPT would be the natural choice I guess...


Cheers,
Hauke


On 12.05.2015 09:54, Oleg Hahm wrote:

Hi,

I just stumbled across ng_netconf - we should rename this to avoid confusion
with RFC 6241 [1]. If the stack would have a name, we could simply call it
_conf...

Cheers,
Oleg

[1] https://tools.ietf.org/html/rfc6241


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi,

I just stumbled across ng_netconf - we should rename this to avoid confusion
with RFC 6241 [1]. If the stack would have a name, we could simply call it
_conf...

Cheers,
Oleg

[1] https://tools.ietf.org/html/rfc6241
-- 
panic("Alas, I survived.\n");
linux-2.6.6/arch/ppc64/kernel/rtas.c


pgpWdghPARJI1.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi!

> giving the ng_stack a name sounds like a very good idea to me (and as far as
> I remembered I already mentioned this last summer...). Though finding a name
> is tough and I don't like the obvious once (flexnet_, default_, riotnet_,
> etc...).

To make it easier, I think we can even discard the name prefix. It's very
unlikely that we want to have to have two IPv6 implementations running
parallel. So, assume we have `default_stack` and `tiny_stack`, it's fine if
both define `ipv6_send()` instead of `default_ipv6_send()`.

> Also 'cutting' out the re-usable parts as headers, header parsing, checksum
> calculation and some others might make sense, though with this I think we
> have to keep in mind, that not every network stack implementation has to use
> those 'generic' building blocks, as these implementations might have their
> own requirements to certain function signatures etc...

Sure, that remains to be seen, but I think for some basic functionalities it
might be possible.
 
> When it comes to protocol header files, as 'net/udp.h', I would be even more
> careful. I don't think we will have a generic udp header, that each network
> stack will comply to. In my opinion, each network stack should just define
> it's own header files, as these will differ depending on their internal
> implementation...

Things like protocol headers will be exactly the same for every implementation
of this protocol, so cutting these out is a MUST. Everything implementation
specific should, of course, stay in separate headers.

Cheers,
Oleg
-- 
printk(KERN_ERR "ide: huh? queue was plugged!\n");
linux-2.6.6/drivers/ide/ide-io.c:


pgpY7FFKaG7Xj.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Hauke Petersen]

Hi everyone,

giving the ng_stack a name sounds like a very good idea to me (and as 
far as I remembered I already mentioned this last summer...). Though 
finding a name is tough and I don't like the obvious once (flexnet_, 
default_, riotnet_, etc...).


Also 'cutting' out the re-usable parts as headers, header parsing, 
checksum calculation and some others might make sense, though with this 
I think we have to keep in mind, that not every network stack 
implementation has to use those 'generic' building blocks, as these 
implementations might have their own requirements to certain function 
signatures etc...


When it comes to protocol header files, as 'net/udp.h', I would be even 
more careful. I don't think we will have a generic udp header, that each 
network stack will comply to. In my opinion, each network stack should 
just define it's own header files, as these will differ depending on 
their internal implementation...


The only important thing is, that we will have a clearly defined 
interface for applications (e.g. RIOT sockets, CoAP or whatever).


So I would say: let's find a name?!

Cheers,
Hauke


On 04.05.2015 10:22, Kaspar Schleiser wrote:

Hi,

On 05/03/15 14:52, Martine Lenders wrote:

Perfect. Still, what do we refer to when talking about "this new tack"?
"the default stack"?

Yes.

The problem here is that the interfaces someone uses will imply the
implementation.

For example, if someone includes "net/udp.h", after dropping the "ng_"
prefix, you get the "default stack" udp include file.

IMHO that file should include a stack agnostic interface whose
implementation is selected by e.g., USEMODULE.

Same for all other developer-accessible protocols.

I'm happy with having a default network stack. I'm not happy if that
stack's specific interface ends up as de-facto standard interface,
making switching stacks practically impossible.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hi,

On 05/03/15 14:52, Martine Lenders wrote:
>> Perfect. Still, what do we refer to when talking about "this new tack"?
>> "the default stack"?
> 
> Yes.
The problem here is that the interfaces someone uses will imply the
implementation.

For example, if someone includes "net/udp.h", after dropping the "ng_"
prefix, you get the "default stack" udp include file.

IMHO that file should include a stack agnostic interface whose
implementation is selected by e.g., USEMODULE.

Same for all other developer-accessible protocols.

I'm happy with having a default network stack. I'm not happy if that
stack's specific interface ends up as de-facto standard interface,
making switching stacks practically impossible.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi,

2015-05-03 14:50 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 05/03/15 13:46, Martine Lenders wrote:
> >> The idea is that if someone uses another stack, he should be able to
> >> remove e.g., the "tiny" folder in order to check for unintended
> >> dependencies.
> >>
> >
> > This is already the case, at least with the stuff I implemented:
> `ng_ipv6`
> > is dependent on `ng_ipv6_addr` etc. while `ng_ipv6_addr` etc. is not
> > dependent on `ng_ipv6`.
>
> Perfect. Still, what do we refer to when talking about "this new tack"?
> "the default stack"?
>

Yes.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hey,

On 05/03/15 13:46, Martine Lenders wrote:
>> The idea is that if someone uses another stack, he should be able to
>> remove e.g., the "tiny" folder in order to check for unintended
>> dependencies.
>>
> 
> This is already the case, at least with the stuff I implemented: `ng_ipv6`
> is dependent on `ng_ipv6_addr` etc. while `ng_ipv6_addr` etc. is not
> dependent on `ng_ipv6`.

Perfect. Still, what do we refer to when talking about "this new tack"?
"the default stack"?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi Kaspar,

2015-05-03 13:42 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 05/03/15 13:04, Martine Lenders wrote:
> >> In all seriousness: I think Ludwigs proposal is better.
> >
> > In other words: the new stack will be the default one, while smaller
> > implementations can be called `tiny_`, `micro_` or whatever. The proposed
> > architecture, that other implementations can use `ipv6/hdr.h`,
> > `ipv6/addr.h` or similar is mostly in place already.
>
> IMHO we should put implicit headers, like an ipv6 network header .h,
> into net/something. Everything stack related should go somewhere else,
> like "net/tiny/*" or even "net/angie/*".
>
> The idea is that if someone uses another stack, he should be able to
> remove e.g., the "tiny" folder in order to check for unintended
> dependencies.
>

This is already the case, at least with the stuff I implemented: `ng_ipv6`
is dependent on `ng_ipv6_addr` etc. while `ng_ipv6_addr` etc. is not
dependent on `ng_ipv6`.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Kaspar Schleiser]

Hi,

On 05/03/15 13:04, Martine Lenders wrote:
>> In all seriousness: I think Ludwigs proposal is better.
> 
> In other words: the new stack will be the default one, while smaller
> implementations can be called `tiny_`, `micro_` or whatever. The proposed
> architecture, that other implementations can use `ipv6/hdr.h`,
> `ipv6/addr.h` or similar is mostly in place already.

IMHO we should put implicit headers, like an ipv6 network header .h,
into net/something. Everything stack related should go somewhere else,
like "net/tiny/*" or even "net/angie/*".

The idea is that if someone uses another stack, he should be able to
remove e.g., the "tiny" folder in order to check for unintended
dependencies.

I'm not saying that we shouldn't have this default stack, I just have
the feeling that we should make sure that we don't re-implement the
wheel multiple times, and clear but independend stuff (like header
definitions, address parsing) should end up in "common" directories.

I'm afraid that having an un-seperated default network stack leads to
confusion.

Is it that much of a hassle to name the default stack and move the
specific includes & implementations into subfolders?

Kaspar

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi Oleg,


2015-05-03 12:59 GMT+02:00 Oleg Hahm :
>
> > I'm not in favor of keeping the prefix. Three reasons:
>
> Forget about the ng, that's unrelated to the question that we need a name
> for
> the stack.
>

As stated in the previous e-mail:

> In all seriousness: I think Ludwigs proposal is better.

In other words: the new stack will be the default one, while smaller
implementations can be called `tiny_`, `micro_` or whatever. The proposed
architecture, that other implementations can use `ipv6/hdr.h`,
`ipv6/addr.h` or similar is mostly in place already.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi!

> I'm not in favor of keeping the prefix. Three reasons:

Forget about the ng, that's unrelated to the question that we need a name for
the stack.

Cheers,
Oleg
-- 
printk("NONONONOO\n");
linux-2.6.6/drivers/atm/zatm.c


pgph9eCWJfIRE.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Martine Lenders]

Hi,
I'm not in favor of keeping the prefix. Three reasons:

1. https://github.com/RIOT-OS/RIOT/pull/2731#discussion_r27350056
2. I'm really looking forward to the day when I don't need to prepend the
ng_ prefix anymore
3. "Angie" sounds to me like a political statement ;-)

In all seriousness: I think Ludwigs proposal is better.

Cheers,
Martine

2015-05-03 2:04 GMT+02:00 Oleg Hahm :

> Hi!
>
> > > What do you think?
> >
> > Due to its known meaning "ng" is as bad a name as "new" or "next",
> > because it will loose this meaning in the foreseeable future.
>
> Star Trek TNG hasn't lost its meaning even after twenty years... But I'm
> really not in favor of any particular name.
>
> > I'm not sure if naming is necessary at all. I think public/shared
> > headers can be used without a problem, and non-default implementations
> > (I assume the current "ng" implementation will be the default)
> > can as well get a characterizing suffix like "_light" or "_tiny" if
> > and when they arrive.
>
> As long as there are only headers to be shared, no problem, but for
> functions
> it's getting more complicated.
>
> Cheers,
> Oleg
> --
> /* When we have more time, we can teach the penguin to say
>  * "By your command" or "Activating turbo boost, Michael".
>  */
> linux-2.2.16/arch/sparc/prom/sun4prom.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Hi!

> > What do you think?
> 
> Due to its known meaning "ng" is as bad a name as "new" or "next",
> because it will loose this meaning in the foreseeable future.

Star Trek TNG hasn't lost its meaning even after twenty years... But I'm
really not in favor of any particular name.

> I'm not sure if naming is necessary at all. I think public/shared
> headers can be used without a problem, and non-default implementations
> (I assume the current "ng" implementation will be the default)
> can as well get a characterizing suffix like "_light" or "_tiny" if
> and when they arrive.

As long as there are only headers to be shared, no problem, but for functions
it's getting more complicated.

Cheers,
Oleg
-- 
/* When we have more time, we can teach the penguin to say 
 * "By your command" or "Activating turbo boost, Michael".
 */
linux-2.2.16/arch/sparc/prom/sun4prom.c


pgpbGtaOCH3qM.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] NSTF - Naming the stack

[Ludwig Ortmann]

Hi,

On Sat, May 02, 2015 at 05:12:55PM +0200, Oleg Hahm wrote:
> After thinking just for some minutes over a new name for the stack, I thought
> that "NG" (pronounced Angie? ;)) may be not a bad idea after all and would
> save us from quite some renaming... All we would have to do then is to extract
> the common functionality and move it generic IPv6 and co. files.
> 
> What do you think?

Due to its known meaning "ng" is as bad a name as "new" or "next",
because it will loose this meaning in the foreseeable future.

I'm not sure if naming is necessary at all. I think public/shared
headers can be used without a problem, and non-default implementations
(I assume the current "ng" implementation will be the default)
can as well get a characterizing suffix like "_light" or "_tiny" if
and when they arrive.

Cheers, Ludwig
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] NSTF - Naming the stack

[Oleg Hahm]

Dear roaring IOTlers,

after some discussion with Kaspar yesterday, we came to the conclusion that it
would probably make sense to give a name to the new IPv6 network stack. The
rational (aside from making it easier to refer to it) is that some parts of
its implementation can serve as common ground for other network stacks, while
other parts are specific to this particular stack. If someone wants to
implement another IPv6 module, he/she could re-use, for instance, the IPv6
header structs. Hence, splitting the implementation in some common part and
some implementation specific part seems to be most sensible to me.

However, the current approach intends to rename ng_ipv6* to ipv6*, which means
that the developer pulls in the full IPv6 implementation of the currently
developed stack. Instead it should be possible select a module "IPv6" for
common features and a module that includes the concrete implementation.
(Actually, it might be unnecessary to define a module "IPv6" if it just
contains header definitions, but maybe, e.g., checksum functions can be
reused, too.)

After thinking just for some minutes over a new name for the stack, I thought
that "NG" (pronounced Angie? ;)) may be not a bad idea after all and would
save us from quite some renaming... All we would have to do then is to extract
the common functionality and move it generic IPv6 and co. files.

What do you think?

Cheers,
Oleg
-- 
/* Fuck me gently with a chainsaw... */
linux-2.0.38/arch/sparc/kernel/ptrace.c


pgpC2GzRoheL2.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel