[openbeosnetteam] Moving stuff to /current: (last?) corrected moves list)

Hi all,
Sorry for being offline all the week-end.

Marcus wrote:
>> Or do we need to have one sub-directory for libnet.so, one for 
>> our future libnetapi.so implementation, etc ? 
>
> I don't think thst this is a good idea. You would force C programs
> to be linked with  a C++ library.

I can see why you may want to keep both net API in separate library 
file like they're in R5, but I can't see what's a "C++" library.
I mean, ELF image format and ELF loader don't care at all. 
Linker, only, do. 
For an mixed C/C++ library on BeOS, look at libGL.so where both 
the C OpenGL API and the BGLView and BGLScreen C++ classes lives 
in same library file.

However:
To keep focus on the "R5 compatibility" target of OBOS R1, 
I agree with Marcus, it's not time to change or not this, let's 
keep it separated for R1. We'll see in the future if it make sense to 
merge them or not.

So, I vote for separate them between  ../kits/net/libnet and
./kits/net/netapi subdirectories, as ../kits/net/net and 
./kits/net/netapi sounds really too much confusing to me.

Ingo wrote:
> BTW, I would propose to introduce a directory for the `etc' files. I
> have no idea where would be the best place for it though.

What about /current/etc?

/current/etc/net/hosts
/current/etc/net/resolv.conf
/current/etc/net/services

Or maybe under /current/src/etc, as, even if they are not *compile*, 
they
will be *installed* in the 
/current/distro/x86.R1 tree by some jam rule.

Or, last but not least, a "etc" subdirectory wherever we need it.
For example:

/current/src/kits/net/libnet/etc/hosts

And the /current/src/kits/net/libnet/Jamfiles call a rule to install 
the
etc/* content where it belong in the 
distro tree?

I like this last solution, because the etc-kind files stay near the 
source
code reading/writing them, which 
make clearer which etc files are used by which part of the code. It 
help
reduce 
the "oh, yes, these files are needed by some code, but can't remember 
which
and where!" factor, I guess.

Ingo reply this to Marcus:
>> Currently, BeOS does not have /add-ons/kernel/network,
>> but I guess this is the right location, since the network core
>> is a module, so it doesn't belong into drivers.
>
> There is already /current/src/add-ons/kernel/net, so unless it has a
> completely different meaning, this one could be used. BTW, it does
> contain some stuff...

Well, "network" or "net", that the question. In fact, this directory 
was misnamed in /current:
For get_module() successfully loads kernel modules, they needs that at 
least one path component 
of a their "module name" match the real directory tree. Without this, 
the kernel module loader will
not find them.
Currently, our network kernel modules are named "network/....", so it 
would
implied a /current/src/add-ons/kernel/network/* tree, as the source 
tree should 
map as close as possible the final binary distro.

However, we can also rename all our modules to use a "net" prefix 
instead and reuse this 
already there directory. But, classicly, BeOS use explicit directory 
name for kernel modules trees 
(bus_managers, file_systems), so "network" seem better when I suggest 
this prefix.
BONE use the same prefix / directory name itself, BTW.
Hopefully, all BONE modules files are prefixed by "bone_", so no 
confusion could be possible here, 
beside the fact that there're in /boot/beos/system/add-ons/kernel/
network directory where we'll 
put our in /boot/home/config/add-ons/kernel/network until we reach a 
final, stable stack version.

> "private" are the headers that are only used by different modules, 
> drivers or support applications of the net kit, but not to be 
> used by any normal BeOS application. Everything not part of the 
> public BeOS api goes there.
> "os" is for the headers that describe classes from libnetapi.so
> "posix" should be for everything else that is posix api like sockets
> (assumed that posix really describes the socket api. if sockets are
> not posix (but BSD), we may put it elsewhere)

My poor english strike me one more time!
:-)

I'm not confused by what's the purpose of 
/current/headers/{os|private|posix}/ directories.
I'm confused on which include files in OUR /net_kit tree should be
considered as "posix", "os" 
(aka, public but [open]beos specific) or "private".

But, thanks to your explanation, I thinks I've figured where belong our 
include files.
See bellow.

And, to answer the question, yes the BSD sockets API *are* 
in POSIX 1003.1g, so all *.h related to the public sockets API should 
be 
under /current/headers/posix/ directory.

Oh, and I agree, no one of our makefiles should moved, 
all new Jamfiles created instead.

-------------

So, corrected after your suggestions:

a) /net_kit/docs/

  * -> /current/dpcs/develop/net/*

b) /net_kit/source/apps/

  arp/*   -> /current/src/apps/bin/arp/*
  ifconfig/* -> /current/src/apps/bin/ifconfig/*
  ping/* -> /current/src/apps/bin/ping/*
  route/* -> /current/src/apps/bin/route/*
  traceroute/* -> /current/src/apps/bin/traceroute/*
  ppp/* -> /current/src/apps/bin/pppconfig/*
  * -> /current/src/tests/kits/net/*

  And we remove these misplaced directories:

  /current/src/apps/arp
  /current/src/apps/ifconfig
  /current/src/apps/ping
  /current/src/apps/route
  /current/src/apps/traceroute

c) /net_kit/source/driver/

  net_stack_driver.c ->
    /current/src/add-ons/kernel/drivers/net/stack/net_stack_driver.c
  net_userstack_driver.c ->
    /current/src/add-ons/kernel/drivers/net/stack/
net_userstack_driver.c
  net_stack_driver.h -> /current/headers/private/net/net_stack_driver.h

d) /net_kit/source/libnet/

  *.c -> /current/src/kits/net/libnet
  Future BNet*.cpp -> /current/src/kits/net/libnetapi.

  Config files -> /current/src/etc/net/ ?

e) /net_kit/source/server/ (misnamed directory now)

  userland_ipc.c -> /current/src/servers/net/userland_ipc.c
  userland_server.c -> /current/src/servers/net/userland_server.c
  net_server/* -> /current/src/add-ons/kernel/network/core/*

  arp/* -> /current/src/add-ons/kernel/network/protocols/arp/*
  icmp/icmp_module.h ->   /current/headers/private/net/icmp_module.h
  icmp/* -> /current/src/add-ons/kernel/network/protocols/icmp/*
  ipv4/ipv4_module.h ->   /current/headers/private/net/ipv4_module.h
  ipv4/* -> /current/src/add-ons/kernel/network/protocols/ipv4/*
  raw/raw_module.h ->   /current/headers/private/net/raw_module.h
  raw/* -> /current/src/add-ons/kernel/network/protocols/raw/*
  route/* -> /current/src/add-ons/kernel/network/protocols/route/*
  tcp/* -> /current/src/add-ons/kernel/network/protocols/tcp/*
  udp/* -> /current/src/add-ons/kernel/network/protocols/udp/*
  ethernet/* ->  /current/src/add-ons/kernel/network/interfaces/
ethernet/*
  loop/* -> /current/src/add-ons/kernel/network/interfaces/loopback/*
  ppp/* -> /current/src/add-ons/kernel/network/protocols/ppp/*
  ppp/serial_ppp/* -> /current/src/add-ons/kernel/network/interfaces/
serial_ppp/*

  test/* ->  /current/src/tests/kits/net/*

  (Notice here that I suggest we rename "loop" into "loopback", which I 
consider more 
  concise and userfriendly, where "loop" can mean so many things)

  And we remove these:
  net_srv.c
  bin/*
  serial_ppp/*
  /current/src/add-ons/kernel/net

f) /net_kit/source/server/include/

  arpa/* -> /current/headers/posix/arpa/*
  net/* -> /current/headers/posix/net/*
  netinet/* -> /current/headers/posix/netinet/*
  sys/* -> /current/headers/posix/sys/*
  resolv.h -> /current/headers/posix/resolv.h
  netdb.h -> /current/headers/posix/netdb.h
  
  And all the other to private/net, as they're internals to the stack 
code ATM
  * -> /current/headers/private/net/*

  And we remove theses:
  /current/headers/posix/lock.h
  /current/headers/posix/net_timer.h
  /current/headers/posix/nhash.h
  /current/headers/posix/pools.h

So, what all do you think, now?
Do we have a "Go!"?
Even a partial, tell me which one so that I could start the move.

-Philippe







--
Fortune Cookie Says:

The reason computer chips are so small is computers don't eat much.

Other related posts: