[Ns-developers] [nsc/ns3] status and plans

[Florian Westphal]

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> After trying to use the nsc/ns-3 trees for the attribute stuff, I have
> to confess that I am really scared about the whole user experience, and
> I think that there are a few things which really need to be addressed
> before trying to keep working on the linux 2.6.26 code.

Fair enough.

> 1) nsc must be separately downloaded, built, installed (with a couple of
> magic ln commands), and, then, we can build the nsc-ns-3 code. It would
> be _really_ helpful if you could make this whole process automatic
> within ns-3. Since sam finally moved to a mercurial repo for nsc, you
> should be able to use a strategy similar to the one used for the
> reference traces and download automatically with mercurial (or a tarball
> with wget) the nsc tree when it is needed (the user does not specify
> --disable-nsc).

I'll look into this.
This means that the first step is to allow the build system to
skip compiling the nsc glue code in case of a specific flag.

> Ideally, the ns-3 build system would also be able to
> invoke the nsc build system (scons), and, then, install nsc correctly to
> make ns-3 find it.

Yes, but i really don't understand why those 'magic ln commands'
are so scary. Are they scary because the user is asked to that manually,
or are you fundamentally opposed to using symbolic links in the first
place?

> 3) I see that your focus lately has been to try to bring in more
> protocols from newer kernels to work within nsc. This is great but it
> would be nice if we could figure out what is really the priority before
> merging your code in ns-3. I can see a couple of other (maybe not
> equally important) items so, here is a small list which I would like to
> discuss (feel free to add more to it):
>   a) add netlink sockets
>   b) make nsc use the native ipv4/arp stacks and ignore the ns-3
> ipv4/arp stacks.
>   c) bring in ipv6

d) add DCCP
(we can ignore it for the time being in favour of removing the
ns-3-nsc build system worries)

> It is clear to me that c) is not possible until the other ns-3 ipv6 code
> has made progress so, let's ignore it. I am not sure what a) would be
> really useful for so, we could ignore it. b) might be potentially much
> more interesting but might be too much work within the scope of a gsoc
> project.

Just for the archive:  b) requires to get proper routing and interface
support going, thats why its not as simple as it sounds.

> Neither 1 nor 2 are highly complex technical problems and I understand
> that they could be seen as being a bit boring :) Both, are, however,
> critical to make it possible to deploy nsc as largely as possible so, it
[..]
Just for the record, I agree. I would hate to do all the 2.6.26 work
just to find that noone is using ns-3-nsc. So, point taken.

> would be really nice if you could try to spend some time on any of these
> issues before proceeding further with more kernel code or, if you really
> want to keep working on kernel code, that you set a date after which,
> whether the kernel code is done or not, you will work on these build
> issues.

Hrm, 2.6.26 should be released soon, and Sam has pushed a new version of
the globaliser (which inverts the meaning of the global list; now its
essentially a 'do not globalise these symbols' list.)
So, i'd like to get 2.6.26 ready to work with the new globaliser first
before looking at the installer stuff (and i'd like to get it work
before monday...)

Regards, Florian