|
[openbeosnetteam]
||
[Date Prev]
[01-2002 Date Index]
[Date Next]
||
[Thread Prev]
[01-2002 Thread Index]
[Thread Next]
[openbeosnetteam] Re: Wishlist (Re: Starting point)
- From: Ksyu & Dima <k2d2@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 16 Jan 2002 17:24:56 -0400
David Reid wrote:
> OK, can the doc be reposted?
There you go... (pls. see attached .txt file). It
took me a while to remember perl :-D.
Dmitri
-- Attached file included as plaintext by Listar --
-- File: archived.txt
******* New Message ********
Subject: [openbeosnetteam] BeOS network informations and "What Next" thing ;-)
Date: Fri, 14 Sep 2001 10:27:48 +0200
Hi every body,
Just a few words from me tonight (yes in Belgium it is 9:30 PM, soon in my
bed... Yessss :-p)
I was looking around for some in-depth information about the net_server and
associated components.
At first, I came accross the source code for the "nat" application whic can
be found here : http://www.rickb.com/software/be.html
The NAT application was an application which is doing a lot of stuff related
to networking. In fact it can catch packet from ethernet drivers and
transmit them after modifications. Moreover, there is also a little
configuration application.
I'm actually reading the code to understand a bit better what we can do with
the information contained in it but I can already tell you that it tells us
how we can interface with drivers. That is an important thing because if we
can do that, we can start building our own network stack. For instance, the
dhcp_client thing I told you about in a previous mail could be (IMHO) very
quickly implemented.
I'd like to start with a first layer software which could connect to all
network drivers, keeping a list of available device and type of device
(ethernet, broadcast type, and PPP, non-broadcast layer 2 thing).
While searching to understand the code, I saw in the code some objects I
couldn't found in the BeBook (it was BNetPacket).
Searching Google for this word brought me to transcript of a Be Developer
Conference "Writing Network Drivers" wich could be found here :
http://www-classic.be.com/developers/may_dev_conf/transcripts/networkdrivers
/
This document explains how to 1) write an ethernet driver, 2) write an
non-ethernet IP driver 3) add our own other-than-IP protocol.
It is a very interesting document IMHO (maybe you already know this document
?). Another interesting thing is that there are some slides related to the
transmission and the reception of packets involving the net_server and
showing how are the interactions done internally.
Another transcript relevant to networking is titled "Approaching Natworking"
which is more network applications oriented but still carry a lot of
valuable information. This transcript can be found here :
http://www-classic.be.com/developers/may_dev_conf/transcripts/approachingnet
working/
Other transcripts can be found here :
http://www-classic.be.com/developers/may_dev_conf/transcripts/
Another interresting source code/application I found was an attempt to code
a USB Alcatel ADSL modem driver. This driver have functions related to ATM,
adressing (vpi/vci), ATM's Segmentation And Reassembly (SAR) and AAL5
functions, PPP over ATM, CRC16 and CRC32 stuff as well as USB stuff.
The driver is located at this page:
http://philippe.houdoin.free.fr/phil/beos/stusb/
More information about a PPPoE and PPtP driver can be found here :
http://perso.wanadoo.fr/gilbert.fernandes/adsl_beos.html (sorry, just in
french but try babelfish/altavista for translation ;-) )
Now I'd like to hear from you all about BONE.
I know some of you have BONE and already developed on it (ZS ?). Could any
body explain me what exactly BONE is and in which way it may change the way
we we will design/implement networkin stuff for OpenBeOS ?
Ok, from now on, what do we do ?
I think we have to continue our design but in parallel, we could try to
implement some pieces to proof our replacement concept.
Why not create first a software module which could connect the drivers and
deviated all the incoming traffic to him, while allowing to send packets to
each of the drivers. As a second step we could try to implement an ARP
utility or a DHCP_Client replacement.
At the same time we begin to implement network stuff bottom->top I think a
part of the team should go on with the net_server itself. What we need to
be able to start a parallel work is to define the interface between the
net_server and the "stack". That should be the primary goal of our design I
think.
Ok folks, please comment this and tell me all what you think so we can start
coding ;-p
Regards,
Emmanuel
******* New Message ********
Date: Thu, 13 Sep 2001 22:03:26 -0300
Subject: [openbeosnetteam] Project information
Hi everybody,
I joined the team couple of days ago read information available in the
mailing list archive as well as information on kernelnewbies.org site...
But I would love to get more details on where the project is standing
right now and what was discussed until now (there is not much
information in the mailing list archive).
How could I get my hands on this info?
Thanx,
Dmitri
******* New Message ********
Subject: [openbeosnetteam] Network team details
Date: Fri, 14 Sep 2001 11:36:20 +1000
Hi Michael. The cc of this letter includes all the people working
on the networking kit.
Take care
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Fw: NetServer design (open-beos)
Date: Fri, 14 Sep 2001 20:05:01 +0200
This is a forward of a previous mail from Zenja Solaja for archiving
purposes.
Emmanuel
----- Original Message -----
From: "Zenja Solaja" <solaja@xxxxxxxxxx>
To: <emmanuel.jacobs@xxxxxxxxxxxx>; "Jean Schwerer" <j-schwerer@xxxxxxx>;
"Peter Morensen" <apm@xxxxxxxxxxxxx>
Sent: Friday, September 07, 2001 1:16 AM
Subject: NetServer design (open-beos)
> Hi all. Hopefully, we're actively reading, researching and preparing for
> the NetServer rewrite. I'm still waiting for my "Design and
Implementation
> of FreeBSD4.4" book to arrive which should be the bible on designing a
> network process. Anyway, we dont want to spend forever reading, so I
think
> we should start debating over an architecture. Hopefully, by Oct 1st we'd
> have settled on an architecture and start coding.
>
> To get things rolling, I've prepared a simple black-box type use case
> diagram which should be a starting point of our design (see attached jpeg,
> if you wish I'll forward the Gobe Productive document used to create this
> jpeg). From the diagram you can see the initial actors. We'll start from
> here and start adding to the diagram.
>
> From the black-box simplistic point of view, what service does the
netserver
> do?
>
> - once initialised, it is usually blocked waiting for an event to awaken
it.
> - a user process can awaken the server with a CONNECTION_REQUEST message
> - a user process can send a TRANSMIT message to the server
> - a user process can inform the server that it wants to RECEIVE messages
> - a user process can send a DISCONNECT message to the server
> - the kernel/driver can awaken the server with a incoming data message
> (READ)
> - the netserver sends the kernel/driver a message (a stream) (WRITE)
>
>
> Internally, what does the netserver do?
>
> - it buffers data streams received from user processes
> - it shuffles the data stream and appends data (in accordance to TCP/IP
> specs)
> - it forwards the new data stream to a device driver
>
> - it buffers data streams received from the device driver
> - it determines who is the receipient of the data (user process, netserver
> process)
> - it strips and reshuffles the data (according to TCP/IP specs)
> - it forwards the stripped data to a user process or a netserver process.
>
>
> What are the initial requirements?
>
> - the netserver should be able to serve an arbitrary number of user
> processes
> - the netserver should be able to link
to a set number of network cards
> - the netserver should have selectable shuffling algorithms (eg. IPv4,
IPv6,
> TCP, AppleTalk etc)
>
> Thats basically it. Lets see if I've missed anything and start modifying
the
> use-case diagrams.
>
> <<NetServer.jpg>>
>
>
>
>
>
>
> ----------------------
> CONFIDENTIALITY NOTICE
> ----------------------
> This email is intended only to be read or used by the addressee.
> The information contained in this e-mail message may be confidential
> information. If you are not the intended recipient, any use, interference
> with, distribution, disclosure or copying of this material is unauthorised
> and prohibited. Confidentiality attached to this communication is not
waived
> or lost by reason of the mistaken delivery to you.
>
> If you have received this message in error, please delete it and notify us
> by return e-mail or telephone Aristocrat Technologies Australia Pty
Limited
> on +61 2 9413 6300.
>
>
-- Binary/unsupported file stripped by Listar --
-- Type: image/jpeg
-- File: NetServer.jpg
******* New Message ********
Subject: [openbeosnetteam] Re: Project information
Date: Fri, 14 Sep 2001 20:08:52 +0200
This list was created a few days ago, I'm talking about the network team
list.
The whole project is very young and the main threads are on the main project
mailinglist : openbeos@xxxxxxxxxxxxx
For wat is related to the network stuff, here are some important points
about our goals: As first step we'll try to build replacement pieces of code
which will work with existing drivers and BeOS R5 providing the same user
APIs than the one currently in the BeBook.
It means we will have to do our own Net_Server, dhcp-client, and preference
app for network settings (add-on). All wat is done internally between those
parts is not that important, this will be our own business. We need user
applications source code compatibility and, where possible, binary
compatibility.
ZS, started a few days ago a design thread, I've just forwarded the mail to
this mailing list for archiving purposes and so you can read it all ;-)
Any other questions ?
Regards,
Emmanuel
----- Original Message -----
From: "Ksyu & Dima" <k2d2@xxxxxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Friday, September 14, 2001 3:03 AM
Subject: [openbeosnetteam] Project information
>
> Hi everybody,
>
> I joined the team couple of days ago read information available in the
> mailing list archive as well as information on kernelnewbies.org site...
> But I would love to get more details on where the project is standing
> right now and what was discussed until now (there is not much
> information in the mailing list archive).
>
> How could I get my hands on this info?
>
> Thanx,
> Dmitri
>
>
******* New Message ********
Subject: [openbeosnetteam] Re: Project information
Date: Fri, 14 Sep 2001 16:11:43 +1000
Hi everyone. Like everyone else, I've been glued to the TV/net during the
last few days, so we can expect more activity after the weekend. Stay tuned
for my submission of a more detailed design proposal during the next week,
we can start hammering and moulding then. Until then, I suggest you read
the BeBook kernel kit, where it talks about add-ons (which is what drivers
are) and modules (an API inside kernel space to service the add-ons). It is
critical that existing network card drivers be binary compatible with our
module and net server implementation, since I dont feel like writing 20
different network card drivers.
Glad to here from you, Emmanuel.
> -----Original Message-----
> From: Emmanuel Jacobs [SMTP:emmanuel.jacobs@xxxxxxxxxxxx]
> Sent: Saturday, September 15, 2001 5:09 AM
> To: openbeosnetteam@xxxxxxxxxxxxx
> Subject: [openbeosnetteam] Re: Project information
>
>
> This list was created a few days ago, I'm talking about the network team
> list.
> The whole project is very young and the main threads are on the main
> project
> mailinglist : openbeos@xxxxxxxxxxxxx
> For wat is related to the network stuff, here are some important points
> about our goals: As first step we'll try to build replacement pieces of
> code
> which will work with existing drivers and BeOS R5 providing the same user
> APIs than the one currently in the BeBook.
> It means we will have to do our own Net_Server, dhcp-client, and
> preference
> app for network settings (add-on). All wat is done internally between
> those
> parts is not that important, this will be our own business. We need user
> applications source code compatibility and, where possible, binary
> compatibility.
>
> ZS, started a few days ago a design thread, I've just forwarded the mail
> to
> this mailing list for archiving purposes and so you can read it all ;-)
>
> Any other questions ?
>
> Regards,
>
> Emmanuel
>
> ----- Original Message -----
> From: "Ksyu & Dima" <k2d2@xxxxxxxxxxxxxxx>
> To: <openbeosnetteam@xxxxxxxxxxxxx>
> Sent: Friday, September 14, 2001 3:03 AM
> Subject: [openbeosnetteam] Project information
>
>
> >
> > Hi everybody,
> >
> > I joined the team couple of days ago read information available in the
> > mailing list archive as well as information on kernelnewbies.org site...
> > But I would love to get more details on where the project is standing
> > right now and what was discussed until now (there is not much
> > information in the mailing list archive).
> >
> > How could I get my hands on this info?
> >
> > Thanx,
> > Dmitri
> >
> >
>
>
>
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Off for one week
Date: Sat, 22 Sep 2001 08:45:00 +0200
Hi guys,
Just to tell you I'll be off this list for one week (until friday).
I have to go in Italy for my work... Sad news isn't it ? ;-)
I had two hard weeks at work so I hadn't so much time for OpenBeOS lately
but as soons as I'm back I'll continue with the process of building some
texts for the Network Specs.
Can you please post some news too so we can all know about each others ?
Regards,
Emmanuel
PS: Jean, Peter have you already subscribed the OpenBeOsNetTeam list ? If
not, please do so as soon as possible please.
******* New Message ********
Subject: [openbeosnetteam] Rights / users list on freelist.org
Date: Sat, 22 Sep 2001 16:19:58 +0200
Jean, Peter, you are not yet subscribed to the OpenBeOS Net Team so I'll
send you an invitation to do so in a few minutes.
Keep me updated, did you received it ?
No, Jean, I don't think there are some means to do so.
As administrator, I can see the list of people with e-mail addresses but it
seems there is no public option to do so.
But I can flag users as administrator and/or moderator so if you or anybody
want to become one, just tell me ;-)
Regards,
Emmanuel
----- Original Message -----
From: "Jean Schwerer" <j-schwerer@xxxxxxx>
To: "Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx>
Sent: Saturday, September 22, 2001 3:54 PM
Subject: Re: Off for one week
> Emmanuel,
>
> Snip: 8<
>
> Also, about the list, is there a page where it is possible to view the
members list and that
> would be open to the public or at least to me? :-)
>
> Thanks,
>
> Jean
>
******* New Message ********
Subject: [openbeosnetteam] Subscription Test...
Date: Sat, 22 Sep 2001 16:22:43 +0200
Jean Peter do you copy ?
Emmanuel
******* New Message ********
Subject: [openbeosnetteam] Re: Subscription Test...
Date: Sun, 23 Sep 2001 08:30:26 +1000
I copy and your not alone on the list. Feeling down during the last week,
did absolutely nothing. Hope I cheer up soon.
-----Original Message-----
From: openbeosnetteam-bounce@xxxxxxxxxxxxx
[mailto:openbeosnetteam-bounce@xxxxxxxxxxxxx]On Behalf Of Emmanuel
Jacobs
Sent: Sunday, 23 September 2001 12:23 AM
To: openbeosnetteam@xxxxxxxxxxxxx
Cc: Jean Schwerer; Peter Morensen
Subject: [openbeosnetteam] Subscription Test...
Jean Peter do you copy ?
Emmanuel
******* New Message ********
Subject: [openbeosnetteam] Re: Subscription Test...
Date: Sun, 23 Sep 2001 01:47:35 +0200
Hello all,
thanks Emmanuel I copy :-)
Zenja, whatever let you feeling down I hope it is not bad news for you and you
will go
through it and cheer up soon.
Last week was a slow week for the whole team and even the openbeos main mailing
list
calmed down ^_^ I guess it is the calm moment before the storm :-)
Jean
******* New Message ********
Subject: [openbeosnetteam] Re: Subscription Test...
Date: Sun, 23 Sep 2001 07:53:13 +0200
I hope all will turn fine for you.
OpenBeOS Net Team will begin real work soon and I hope that will be
enjoyable ;-)
CU in a few days,
Emmanuel
----- Original Message -----
From: "Zenja Solaja" <zenja@xxxxxxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Sunday, September 23, 2001 12:30 AM
Subject: [openbeosnetteam] Re: Subscription Test...
>
> I copy and your not alone on the list. Feeling down during the last week,
> did absolutely nothing. Hope I cheer up soon.
>
>
>
> -----Original Message-----
> From: openbeosnetteam-bounce@xxxxxxxxxxxxx
> [mailto:openbeosnetteam-bounce@xxxxxxxxxxxxx]On Behalf Of Emmanuel
> Jacobs
> Sent: Sunday, 23 September 2001 12:23 AM
> To: openbeosnetteam@xxxxxxxxxxxxx
> Cc: Jean Schwerer; Peter Morensen
> Subject: [openbeosnetteam]
Subscription Test...
>
>
>
> Jean Peter do you copy ?
>
> Emmanuel
>
>
>
******* New Message ********
Subject: [openbeosnetteam] Status
Date: Fri, 12 Oct 2001 09:42:12 +0200
Ok guys,
Here is the time for a little information exchange ;-)
Below is information about my work within the OBEOS network team.
I collected various softwares related to low level networking stuff (Nat,
PPPoE, netork drivers, ...) in order to have some example codes.
Then I searched for technical documentation about how to build code related
to low level networking stuff (how to write (network) drivers, what are
modules, how does the network preference pannel work , what are network
related APIs ?, etc.)
I'm currently exploring how we could build a piece of code to interface
directly with (actual) network drivers.
I found an old piece of code called E-Drive which was a tool built for
testing ethernet driver (ping and ARPs) whithout the need of using the
NetServer.
I have problem to compile this and, because I'm not a BeOS guru coder, I
think somebody could help me with that :-p
I think someone else could collect information and build example codes on
how to substitute NetServer application APIs with our own.
Something else could be done to solve the problem of building our own
Network Preference Pannel application.
Other problems are remaining at this stage: How does the DHCP thing
interface with the NetServer ? What about the PPP thing ? Etc.
Anybody wants to take some positions ?
Could it be of interrest to contact former beos coders who did network
related stuff to ask them if they would be interrested to join our team or
the OpenBeOS project ?
For information, I can't currently allocate more than 1 hour a day to OBEOS.
Another information, several weeks ago I started
openbeosnetteam@xxxxxxxxxxxxx distribution list for topics directly related
to network team/stuff.
Please feel free (oh yes, please do so;-) to share ideas and comments.
Best Regards,
Emmanuel
******* New Message ********
Subject: [openbeosnetteam] Fw: OpenBeOS - Network Stuff
Date: Sat, 13 Oct 2001 10:49:05 +0200
FYI:
Below is the answer to a mail I sent to Dr. Zoidberg Enterprises.
----- Original Message -----
From: "Bruno G. Albuquerque" <bga@xxxxxxxxxxxxx>
To: "Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx>
Sent: Friday, October 12, 2001 6:17 PM
Subject: Re: OpenBeOS - Network Stuff
> > I'm sending you this mail following the communication done by
> Daniel
> >Reinhold on the open BeOS web site (http://open-beos.sourceforge.net/)
> >stating you were working on a project for replacing original beos
> networking
> >components.
>
> Yep. This will be our next project just after we finish and deliver our
> mail daemon replacement.
>
> > We are currently begining R&D about that too so I'd like to know if
> you
> >are interrested in joining efforts ?
>
> No problem at all. I will forward this message to the other members of
> my team.
>
> -Bruno
>
> --
> Fortune Cookie Says:
>
> One thing the inventors can't seem to get the bugs out of is fresh
> paint.
******* New Message ********
Subject: [openbeosnetteam] Status update
Date: Sat, 13 Oct 2001 23:12:42 +0200
Greetings to all the readers of this list :o)
There are a lot of people we haven't heard from in the past weeks, and...
oops.... I am one of
those people ^_^ Sorry for that, but I still have no clue whether I'll get a
new job soon or if I'll
have to start wondering how to pay the bills.
However, despite the time consumed by this job hunting and despite my silence,
I haven't been
completely inactive.
1/ On the *BeOS* side:
I have organized the GeekDay a couple of weeks ago. It's a gathering of Frenchy
users and
developers. I introduced the OpenBeOS project to people who weren't aware of
it. I also
introduced the BlueOS and Phoenix/BeUnited projects. I gathered opinions /
reactions about the
current situation and potential future of BeOS.
I also completed the first phase of development of a little perl script that
enables me to update
in a faster way my websites. I have made profuzion.org compliant with this
script but am still
working hard on making NPC compliant with it. Talking about NPC, I have
important projects for
it: I wish it to be an useful resource for OBOS as well, and I'll open new
sections on it soon.
Better late than never, but I realised the NPC website had not been updated for
more than one
year already! Updating it in order to show support to OBOS seems important to
me.
2/ On the *OpenBeOS Network Team* side:
During the GeekDay event I could meet Guillaume Maillard, developer of the Eden
application and
Leader of the BlueOS project. Interestingly enough, they have someone from
Gobe, Inc working
closely with them. I also talked with Guillaume about a development that could
possibly be part
of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite, mapped
after
traditional BSD sockets. I *have started* this API rewrite. The reason I didn't
talk about it yet is
that I wanted to wait to have something to show, presenting it at the same time
as a proof of
concept tof our team. Mmmh... As you can see this mail is sent to the Network
list only, I'll
mention it to the main OBOS list when I'm 80% done, not before.
I have thought about some kind of wish-list and development milestones for our
Team. I'll have a
couple of things to submit to you about those two topics in the forthcoming
days (tuesday at
the latest). I just hope there are more people listening here than just Ithamar
and Emmanuel.
We're waiting for other answers! :o)
I think it would be good to include Dr Zoidberg in our thinking about
milestones and wish-list, I
was just waiting for my mail to you about this to be ready to contact them, but
Emmanuel beat
me at contacting them :-)
Well hum... you can start thinking about the wish list anyway :o) It's quite
easy, just tell ALL
things you would like to see in OBOS Network layer. Don't mind if it is
feasable at all or not, just
think of a "perfect world".
For example as far as I am concerned I'd like to see:
Protocol-wise:
- IPv6 support
- ATM and PPPoA support
- Full PPPoE and PPTP support of course, with CHAP authentication ^_^
- Token Ring support (yes, I like Token Ring and think it is a well-designed
protocol, and
remember: I talked of a perfect world :P)
Design-wise:
- I wish every protocol would be handled by a separate add-on, then the
necessary add-on gets
loaded when a given kind of network traffic is recognized by the lower layer.
That way it is
easy to add protocols and to update some protocols' support. The add-on doesn't
get unloaded
from memory unless there is a given timer without network traffic observed (if
the timer is
reached however it will be wise to assume the machine has been disconnected
from the network
and warn the user about it :P)
Feature/API-wise:
- An automatic flooding and malformed packets protection for applications
asking for it. e.g. an
application may call a FilterArrivingPackets() function that would tell the
network API to monitor
certain kind of parameters, some kind of built-in firewall working at a lower
level than user-
launched firewalls.
- An automatic non-transparent firewall/proxy support. e.g. an application
opens a connection
(BNetEndpoint, BNetAddress...) and instead of having to care about
firewall/proxy itself it tells
the BNetEndpoint->UseProxyFirewall("socks5"). Then it doesn't care afterwards
whether it's
talking to a firewall/proxy or not, it justs sends the packets as it would to a
given server, and
the net_server handles the "translation" in firewall/proxy protocol for it.
What's the benefit?
Any application can then handle any kind of non-transparent firewall/proxy
supported by the
net_server without having to implement it. Kind of a "translator" function
applied to the network
if you prefer :o)
- I read on OSNews (in Eugenia's interview of some *BSD people) about the
project of BSD
developers to enable sockets to be passed from a server to another one, which
would enable
QoS by ensuring a connection isn't dropped when a server is taken offline for
maintenance of
after a crash. I definitely want this in OBOS :o)
Application-wise:
- I'd like OpenSSL/OpenSSH and Apache to compile right out of the box
(currently not the case,
it's even lacking proper header files)
- I'd like to have a Perl build for OBOS with socket support
I realize I've been quite long and already offered an insight about the
wish-list topic :o) Well
anyway... hope you made it until here and read a little bit of everything, but
most of all... I hope you'll react to it ^_^
Cheers,
Jean
******* New Message ********
Subject: [openbeosnetteam] Fw: OpenBeOS - Networking
Date: Sun, 14 Oct 2001 11:42:26 +0200
FYI.
This is the answer I received from Axel, the coder of a SIS900 network
adapter driver (http://www.bebits.com/app/2440).
Funny, he told me he is a member of "Dr. Zoidberg Enterprises" too ;-p
Emmanuel
----- Original Message -----
From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
To: "Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx>
Sent: Saturday, October 13, 2001 10:01 PM
Subject: Re: OpenBeOS - Networking
> Hello Emmanuel,
>
> "Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx> wrote:
> >I contact you because we need help with the rewrite of the Networking
Stuff
> >inside the OpenBeOS project.
>
> As you may know, I am part of "Dr. Zoidberg Enterprises" - the next
project
> in our list was a net_server replacement.
> Perhaps we can join our efforts, but you should check with our other
> members - we were recently mentioned on your website :-)
>
> I think Nathan and Peter have already planned some stages of it, so it
would
> really makes sense to work together.
>
> >I saw on BeBits you had contacts with Hank from Be and that he provided
> you
>
>with information about how to code your network driver.
>
> Well, the driver was already working (under BONE, at least) - but he gave
me
> the right idea of the problem I had with the net_server - as it turned
out, it
> was a general problem with my driver, because I assumed, that I will get
an
> IRQ for every frame received - but sometimes they got bundled, and the
> driver didn't see it.
> I don't know (neither did Hank) why the driver worked using BONE, but who
> cares? :-)
>
> >I wonder if you could help me and the OpenBeOS team on that topic ? Can I
> >ask you questions ? Could you provide me with information about how to
> code
> >network drivers ? Can I acces the source code of your driver ?
>
> I can send you the code of my driver, and I can answer questions - but
it's not
> that hard after all.
>
> read() reads a packet from the card
> write() sends a packet to the card
> ioctrl() controls some settings - the opcodes are defined in some private
> headers - there is a Ethernet driver shell on ftp.be.com which includes
all you
> need.
>
> Adios...
> Axel.
>
******* New Message ********
Subject: [openbeosnetteam] Re: Status update
Date: Mon, 15 Oct 2001 18:43:15 +0200
----- Original Message -----
From: "Jean Schwerer" <j-schwerer@xxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Saturday, October 13, 2001 11:12 PM
Subject: [openbeosnetteam] Status update
8< snip!
> 1/ On the *BeOS* side:
> I have organized the GeekDay a couple of weeks ago. It's a gathering of
Frenchy users and
> developers. I introduced the OpenBeOS project to people who weren't aware
of it. I also
> introduced the BlueOS and Phoenix/BeUnited projects. I gathered opinions /
reactions about the
> current situation and potential future of BeOS.
Good job !
Nice picture of the event, is there any picture on which you stand ?
> 2/ On the *OpenBeOS Network Team* side:
> During the GeekDay event I could meet Guillaume Maillard, developer of the
Eden application and
> Leader of the BlueOS project. Interestingly enough, they have someone from
Gobe, Inc working
> closely with them. I also talked with Guillaume about a development that
could possibly be part
> of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite,
mapped after
> traditional BSD sockets. I *have started* this API rewrite.
Could you please mail me privately to give me more information ?
> The reason I didn't talk about it yet is
> that I wanted to wait to have something to show, presenting it at the same
time as a proof of
> concept tof our team. Mmmh... As you can see this mail is sent to the
Network list only, I'll
> mention it to the main OBOS list when I'm 80% done, not before.
That's fine for me.
8< snip!
> Well hum... you can start thinking about the wish list anyway :o) It's
quite easy, just tell ALL
> things you would like to see in OBOS Network layer. Don't mind if it is
feasable at all or not, just
> think of a "perfect world".
Mhhhh, yes, a "perfect world" ;-)
But perhaps it could make sense to prioritize the whish list, giving first
ideas to be implemented or researched first, then the nice-to-haves.
I suggest you copy/paste the part of your mail (which list) in a new
dedicated mail to launch the thread on the main list, what do you think
about it ?
I'll submiot my whiches to the new thread if it is ok for you ;-)
Emmanuel
******* New Message ********
Subject: [openbeosnetteam] Re: Status update
Date: Wed, 17 Oct 2001 17:49:18 +0200
Hello,
>> 1/ On the *BeOS* side:
>> I have organized the GeekDay a couple of weeks ago. It's a gathering of
>Frenchy users and
>> developers. I introduced the OpenBeOS project to people who weren't aware
>of it. I also
>> introduced the BlueOS and Phoenix/BeUnited projects. I gathered opinions /
>reactions about the
>> current situation and potential future of BeOS.
>
>Good job !
>Nice picture of the event, is there any picture on which you stand ?
Load http://www.ubix.org/Images/GeekDay3/IMG_0465.JPG and look for the guy
playing with
a Visor: that's me ^_^
>> 2/ On the *OpenBeOS Network Team* side:
>> During the GeekDay event I could meet Guillaume Maillard, developer of the
>Eden application and
>> Leader of the BlueOS project. Interestingly enough, they have someone from
>Gobe, Inc working
>> closely with them. I also talked with Guillaume about a development that
>could possibly be part
>> of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite,
>mapped after
>> traditional BSD sockets. I *have started* this API rewrite.
>
>Could you please mail me privately to give me more information ?
Done.
>> Well hum... you can start thinking about the wish list anyway :o) It's
>quite easy, just tell ALL
>> things you would like to see in OBOS Network layer. Don't mind if it is
>feasable at all or not, just
>> think of a "perfect world".
>
>Mhhhh, yes, a "perfect world" ;-)
>But perhaps it could make sense to prioritize the whish list, giving first
>ideas to be implemented or researched first, then the nice-to-haves.
Well of course the wish-list will get prioritized, but that will be the second
step. The first step is
to get people throw as many ideas as they can. We're in the "brainstorm" logic
right now.
>I suggest you copy/paste the part of your mail (which list) in a new
>dedicated mail to launch the thread on the main list, what do you think
>about it ?
>I'll submiot my whiches to the new thread if it is ok for you ;-)
Ok. I wanted to post the wish-list yesterday but couldn't. Should do so
tonight. If in 7 hours from
now at the latest nothing from me showed up on the main OBOS list you will be
authorized to
call me names :o)
Jean
******* New Message ********
Date: Wed, 17 Oct 2001 17:15:51 -0300
Subject: [openbeosnetteam] Re: Status update
Hi everybody,
I am being a bit late with this reply but it is better later than never
(or so they say...)
>
>2/ On the *OpenBeOS Network Team* side:
>During the GeekDay event I could meet Guillaume Maillard, developer of the
>Eden application and
>Leader of the BlueOS project. Interestingly enough, they have someone from
>Gobe, Inc working
>closely with them. I also talked with Guillaume about a development that could
>possibly be part
>of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite, mapped
>after
>traditional BSD sockets. I *have started* this API rewrite.
>
Do you need a hand with the rewrite?
>Well hum... you can start thinking about the wish list anyway :o) It's quite
>easy, just tell ALL
>things you would like to see in OBOS Network layer. Don't mind if it is
>feasable at all or not, just
>think of a "perfect world".
>For example as far as I am concerned I'd like to see:
>Protocol-wise:
>- IPv6 support
>- ATM and PPPoA support
>- Full PPPoE and PPTP support of course, with CHAP authentication ^_^
>- Token Ring support (yes, I like Token Ring and think it is a well-designed
>protocol, and
>remember: I talked of a perfect world :P)
>
Here goes my wishlist:
- IPSec support
- IPSec key management: IKE and possibly photuris (btw, do we have any
plans on BSD-compatible sockets API? That would make the task of porting
of a lot of applications much easier)
- RSVP support (a perfect world clause applies ;-))
>
>Design-wise:
>- I wish every protocol would be handled by a separate add-on, then the
>necessary add-on gets
>loaded when a given kind of network traffic is recognized by the lower layer.
>
There are some security issues associated with this approach. One way
around could be for a user to select what protocol(s) he/she wants to use...
> That way it is
>easy to add protocols and to update some protocols' support. The add-on
>doesn't get unloaded
>from memory unless there is a given timer without network traffic observed (if
>the timer is
>reached however it will be wise to assume the machine has been disconnected
>from the network
>and warn the user about it :P)
>
Good idea... (some protocols support keepalives though (tcp comes first
to my mind) and can keep the connection open forever without any actual
data being exchanged)
>
>
>Feature/API-wise:
>- An automatic flooding and malformed packets protection for applications
>asking for it. e.g. an
>application may call a FilterArrivingPackets() function that would tell the
>network API to monitor
>certain kind of parameters, some kind of built-in firewall working at a lower
>level than user-
>launched firewalls.
>
I think flooding protection can be implemented the same way as OpenBSD
guys did it: when the queue of the opened (but not accepted) connections
becomes too big, connections are being randomly dropped from the queue.
The protection from the malformed packets is a bit trickier though: a
user may or may not want to use IP options, for example; on the other
hand malformed fragmented packets should always be dropped.
>
>- An automatic non-transparent firewall/proxy support. e.g. an application
>opens a connection
>(BNetEndpoint, BNetAddress...) and instead of having to care about
>firewall/proxy itself it tells
>the BNetEndpoint->UseProxyFirewall("socks5"). Then it doesn't care afterwards
>whether it's
>talking to a firewall/proxy or not, it justs sends the packets as it would to
>a given server, and
>the net_server handles the "translation" in firewall/proxy protocol for it.
>What's the benefit?
>Any application can then handle any kind of non-transparent firewall/proxy
>supported by the
>net_server without having to implement it. Kind of a "translator" function
>applied to the network
>if you prefer :o)
>
again, sounds like a good idea...
>
>- I read on OSNews (in Eugenia's interview of some *BSD people) about the
>project of BSD
>developers to enable sockets to be passed from a server to another one, which
>would enable
>QoS by ensuring a connection isn't dropped when a server is taken offline for
>maintenance of
>after a crash.
I definitely want this in OBOS :o)
>
>Application-wise:
>- I'd like OpenSSL/OpenSSH and Apache to compile right out of the box
>(currently not the case,
>it's even lacking proper header files)
>
A must have, IMHO ;-)
>
>- I'd like to have a Perl build for OBOS with socket support
>
would be nice to have.
>
>I realize I've been quite long and already offered an insight about the
>wish-list topic :o) Well
>anyway... hope you made it until here and read a little bit of everything, but
>most of all... I hope you'll react to it ^_^
>
>Cheers,
>
>Jean
>
>
Cheers,
Dmitri
>
******* New Message ********
Subject: [openbeosnetteam] Networking Wish List - Summary
Date: Mon, 29 Oct 2001 20:24:01 +0100
Several days ago we queried the people on the main OpenBeOS mailing list for
ideas and wishes about the future implementation of the Networking Stuff
within OpenBeOS.
Please note this is not a design of the OpenBeOS's Network Functionalities
but only a collection of ideas expressed by people.
I suggest now we complete that info with core stuff.
Then we could build some kind of time line of objectives to reach and
distribute the work amoung us.
Ok, let's start designing ;-)
Emmanuel
_______________________________________________
OBOS - Network Team - The Networking Whish List
_______________________________________________
* Document revisions:
[eja-011018] - first version.
* Introduction:
In the process of setting up a design and a time line for the OpenBeOS
Network components rewrite, the Network team tried to collect ideas from
BeOS users through the OpenBeOS mailing list.
This document's purpose is to collect all those.
Emmanuel
___________________________________________________
- The OBOS Networking Whish List -
* Protocol-wise:
- IPv6 support
- ATM and PPPoA support
- Full PPPoE and PPTP support with CHAP authentication
- Token Ring support
- IPSec support
- IPSec key management: IKE and possibly photuris
- RSVP support
* Design-wise:
- Protocols could be handled as separate add-ons, which could be loaded
and unloaded automatically
* Feature/API-wise:
- Some kind of built-in firewall functions in the network code
(flooding and malformed packets protection).
- Some kind of built-in "translators" for non-transparent
firewall/proxy so they could be used easily by applications and
configured once.
- Clustering, High Availability (Beowulf, Possibility to pass sockets
from one machine to another [original idea from OSNews,
Eugenia's interview of some *BSD people] ).
- Integration of network protocols and filesystem would be nice. E.g. you
can cd to "/net/ftp/ftp.be.com/pub/" and arrive at the server without
using a special ftp client. Similar for SMB, HTTP, NFS etc... kind of
like automounting, only no predefined directory entries are needed.
(i.e.: doing an "ls" command on the "/net/ftp" directory does NOT
display "ftp.be.com" unless you have already been at that location.
[it's maybe a FileSystem service, http://ftpfs.sourceforge.net/]
- WON, Windows Network and AppleTalk Network browsing.
- The ability to have several network "profiles"
(home/travel/company).
Application-wise:
- OpenSSL/OpenSSH.
- Apache.
- Perl build for OBOS with socket support
----- Original Message -----
From: "Ksyu & Dima" <k2d2@xxxxxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Wednesday, October 17, 2001 9:15 PM
Subject: [openbeosnetteam] Re: Status update
>
> Hi everybody,
>
> I am being a bit late with this reply but it is better later than never
> (or so they say...)
>
> >
> >2/ On the *OpenBeOS Network Team* side:
> >During the GeekDay event I could meet Guillaume Maillard, developer of
the Eden application and
> >Leader of the BlueOS project. Interestingly enough, they have someone
from Gobe, Inc working
> >closely with them. I also talked with Guillaume about a development that
could possibly be part
> >of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite,
mapped after
> >traditional BSD sockets. I *have started* this API rewrite.
> >
> Do you need a hand with the rewrite?
>
> >Well hum... you can start thinking about the wish list anyway :o) It's
quite easy, just tell ALL
> >things you would like to see in OBOS Network layer. Don't mind if it is
feasable at all or not, just
> >think of a "perfect world".
> >For example as far as I am concerned I'd like to see:
> >Protocol-wise:
> >- IPv6 support
> >- ATM and PPPoA support
> >- Full PPPoE and PPTP support of course, with CHAP authentication ^_^
> >- Token Ring support (yes, I like Token Ring and think it is a
well-designed protocol, and
> >remember: I talked of a perfect world :P)
> >
> Here goes my wishlist:
>
> - IPSec support
> - IPSec key management: IKE and possibly photuris (btw, do we have any
> plans on BSD-compatible sockets API? That would make the task of porting
> of a lot of applications much easier)
> - RSVP support (a perfect world clause applies ;-))
>
> >
> >Design-wise:
> >- I wish every protocol would be handled by a separate add-on, then the
necessary add-on gets
> >loaded when a given kind of network traffic is recognized by the lower
layer.
> >
> There are some security issues associated with this approach. One way
> around could be for a user to select what protocol(s) he/she wants to
use...
>
> > That way it is
> >easy to add protocols and to update some protocols' support. The add-on
doesn't get unloaded
> >from memory unless there is a given timer without network traffic
observed (if the timer is
> >reached however it will be wise to assume the machine has been
disconnected from the network
> >and warn the user about it :P)
> >
> Good idea... (some protocols support keepalives though (tcp comes first
> to my mind) and can keep the connection open forever without any actual
> data being exchanged)
>
> >
> >
> >Feature/API-wise:
> >- An automatic flooding and malformed packets protection for applications
asking for it. e.g. an
> >application may call a FilterArrivingPackets() function that would tell
the network API to monitor
> >certain kind of parameters, some kind of built-in firewall working at a
lower level than user-
> >launched firewalls.
> >
> I think flooding protection can be implemented the same way as OpenBSD
> guys did it: when the queue of the opened (but not accepted) connections
> becomes too big, connections are being randomly dropped from the queue.
> The protection from the malformed packets is a bit trickier though: a
> user may or may not want to use IP options, for example; on the other
> hand malformed fragmented packets should always be dropped.
>
> >
> >- An automatic non-transparent firewall/proxy support. e.g. an
application opens a connection
> >(BNetEndpoint, BNetAddress...) and instead of having to care about
firewall/proxy itself it tells
> >the BNetEndpoint->UseProxyFirewall("socks5"). Then it doesn't care
afterwards whether it's
> >talking to a firewall/proxy or not, it justs sends the packets as it
would to a given server, and
> >the net_server handles the "translation" in firewall/proxy protocol for
it. What's the benefit?
> >Any application can then handle any kind of non-transparent
firewall/proxy supported by the
> >net_server without having to implement it. Kind of a "translator"
function applied to the network
> >if you prefer :o)
> >
> again, sounds like a good idea...
>
> >
> >- I read on OSNews (in Eugenia's interview of some *BSD people) about the
project of BSD
> >developers to enable sockets to be passed from a server to another one,
which would enable
> >QoS by ensuring a connection isn't dropped when a server is taken offline
for maintenance of
> >after a crash. I definitely want this in OBOS :o)
> >
> >Application-wise:
> >- I'd like OpenSSL/OpenSSH and Apache to compile right out of the box
(currently not the case,
> >it's even lacking proper header files)
> >
> A must have, IMHO ;-)
>
> >
> >- I'd like to have a Perl build for OBOS with socket support
> >
> would be nice to have.
>
> >
> >I realize I've been quite long and already offered an insight about the
wish-list topic :o) Well
> >anyway... hope you made it until here and read a little bit of
everything, but most of all... I hope you'll react to it ^_^
> >
> >Cheers,
> >
> >Jean
> >
> >
>
> Cheers,
> Dmitri
>
> >
>
******* New Message ********
Subject: [openbeosnetteam] Re: Networking Wish List - Summary
Date: Thu, 1 Nov 2001 01:39:34 +0100
Hi all,
3 points in this mail.
1/ in a private exchange of emails Emmanuel has written something I found very
well said so I'm
quoting him:
>I'd like the network team to:
>- set up a drawing of the actual networking components in BeOS with
>description of interractions between them and with drivers and system.
>- experiment to replace those components.
>- code a basic ARP / IP / ICMP stack whith basic network preference panel
>replacement and drivers interfacing.
>- to share activities among us.
Now for a couple of quick comments:
- The idea for a drawing is a very good one. Not only will it make things
clearer for ourselves, it
will help new members of the team jump more easily in as well. Is there any
taker for this?
Pleaaase :o)
- Experiment replacing the components: this was all what I wanted to do with
the high-level API
rewrite. It just happens so that I didn't have a single minute to put more code
in it since my
email entitled Status Update :-( On the other hand, I asked Erik Jakowatz on
help for how he
achieved to emulate binary compatibility with the screensaver, and received an
email from him
detailing his proceeding a couple of days ago, so I will probably try to go the
same way than him.
However I would like to put the API rewrite on a priority level 2 only.
- Code a basic stack: I believe the most urgent is to understand the way
drivers work.
I didn't
test the NewOS kernel so I don't know how this one works. Anyone having some
know-how
about this to share? I believe this and the drawing should be priority level 1.
- Sharing activities among us: I should have taken care of this earlier. This
is all my fault if our
team's been so slow to start and share. I feel sorry for this, but I can assure
you despite my
mailbox's growing size (got some 620 unread mails... ouch :-/) I finally came
to raise the Ultra
High Priority Flag on the OBOS Network Team on my lengthy ToDo List. Priority
level 1 as well.
2/ Additionnally, in an email sent october 17, Dmitri wrote the following
(quoting relevant parts
only):
>I am being a bit late with this reply but it is better later than never
>(or so they say...)
Same applies to me.... in 10 times worse. Sorry :(
>Do you need a hand with the rewrite?
Huh, yes and no. On the one hand the classes are pretty well split so it would
be easy to split
the work on the rewrite. On the other hand this is not much of a huge task so I
believe I should
be able to do it :) Additionnally I'd like we start driver interfacing and
share knowledge about this
ASAP (check priorities above :P)
3/ We might be welcoming new members soon. One has contacted me directly and
Michael
forwarded me two others emails of people interested in joining the OpenBeOS
project (although
we might be in competition with other teams to get them :P).
Please please please, any comments or answers to questions above are welcome :-)
Jean
******* New Message ********
Subject: [openbeosnetteam] Random muslings
Date: Thu, 1 Nov 2001 16:35:53 +1100
Hi all. I've bowed my head in shame a few weeks ago, and what can I say,
BeOS is like a drug which (once addicted) is a habit hard to break. Elate
isn't as much fun as I thought it would be, and I'm slowly becoming aware
that there may be a possibility that I'll come crawling back to the lovin'
OpenBeOS arms (if you'll take me back :-)
What does the OpenBeOS networking team need to implement?
1) The Network Kit front end.
This is the API presented to the user. User applications use the interface
by referencing BeAPI header files and Posix header files. The network team
needs to re-implement the following frontend (from the BeBook):
a)- BNetAddress class (convert net addresses to generic internal
type) - easy
b)- BNetBuffer class (allocate buffer and append/delete data) - easy
c)- BNetDebug class (debug info) - piece of cake
d)- BNetEndpoint (object oriented socket - wrapper for socket calls)
- slightly moderate
e)- network sockets - moderate to time consuming (the meat of the
kit).
- socket()
- bind()
- getsockname()
- getpeername()
- recvfrom()
- sendto()
- send()
- recv()
- listen()
- accept()
- connect()
- closesocket()
- shutdown()
- setsockopt()
- select()
f)- BSD network database interface - easy
- gethostbyname()
- gethostbyaddr()
- getservbyname()
- herror()
- inet_addr()
- inet_ntoa()
- gethostname()
- getusername()
- getpassword()
g)- Network settings - easy
- findnetsettings()
- setnetsettings()
Thats all we need to be source compatible.
h) - additions to the API (wish list)
From the OSI layered model point of view, the front end could
corrolate to the Transport and Session layers.
2) The Network Kit back end
This is the actual net_server which interfaces with the kernel/hardware.
>From the OSI perspective, it provides the functionality of the Data-Link and
Network layers. The average developer writing a network application
considers the back end to be a black box. Until I finish reading the
FreeBSD design book, I cannot comment on the structure of the black box.
Marcus Overhaggen from the Media Kit team did an excellent job of
demonstrating how to convert the B header files into a dummy C program with
pluggin functions - empty pluggin functions for now (a single debug printf()
to show status), but functions which will be filled in as the team
progresses. Marcus honestly believes that binary compatibility is possible,
and so far he can get 3rd party apps to link without errors (of course, they
dont run yet). I think that a couple of members of the Networking team (a
couple and no more) can attempt the same with the above front end. This
will show progress to the rest of the OpenBeOS teams, and will allow the
very first files to be checked into CVS. As far as everyone else is
concerned, the black box can be a rip off of the FreeBSD networking
implementation (hey, nothing to be ashamed of, its one of the best in the
industry), and all they really want is source level (100% possible) and even
better, binary compatibility (possible).
Anyway, I'm prepared to take the challenge of preparing the header/pluggin
files. Is that OK with you Jean (glorious team leader)?
Any thoughts, suggestions?
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Date: Fri, 02 Nov 2001 12:14:20 -0400
Subject: [openbeosnetteam] BONE components and interaction
Hi everybody,
I'm not sure if this is what Emmanuel and Jean had in mind, but hopefully this
will of some help to us... ;-)
Most of the information in this diagram can be found at
http://www-classic.be.com/aboutbe/benewsletter/volume_IV/Issue05.html.
The rest is contained in BE's bone.zip (if someone needs the archive I can
e-mail it); I'm not entirely clear on how Data Link module should interface
with framing module and ethernet (or whatever) driver; I made an attempt to
list possible functions which an ethernet driver would have to implement by
looking at the header files in BONE example.
Anyway, it is only a first approach so a lot of thnigs will change; Let me know
if you have any suggestions, corrections, etc...
Enjoy,
Dmitri
_______________
| |
| libsocket.so |
|_______________|
user land |
- - - - - - - - - - - - - - - - -+- - - - - - - - - - - - -
kernel land |
________|________
| |
______________ | net api driver |
| | |_________________|
| bone_util | |
|______________| ________|________
| |
network/transport | protocol module | (e.g.,. udp)
layer |_________________|
|
________|________
| | (contains ARP,
data link layer | datalink module | etc.)
|_________________|
/ \
_____________/___ _\_______________
| loopback | | 802.3 |
| framing module | | framing module |
|_________________| |_________________|
| |
physical layer | |
________|________ ________|________
| | | |
| loopback driver | | ethernet driver |
|_________________| |_________________|
- libsocket.so interfaces with user-land applications using Network Kit/Posix
(BSD sockets) API;
- Net API driver is responsible for creating bone_endpoint_t structure and
handles all communications between the socket and protocol stack.
Interfaces with libsocket.so via ioctls;
- Protocol module interfaces with Net API driver via (as found in bone_proto.h
in bone.zip example):
status_t (*init_protocol)(struct bone_proto_node *you); - called when a new
endpoint is created
status_t (*uninit_protocol)(struct bone_proto_node *you); - called when
deleting an endpoint
status_t (*close)(struct bone_proto_node *you); - called when a user calls
"close" on a socket
status_t (*connect)(struct bone_proto_node *you, struct sockaddr *them);
status_t (*send_data)(struct bone_proto_node *you, bone_data_t *data);
int32 (*send_avail)(struct bone_proto_node *you); - called to determine how
many bytes can be sent without blocking
status_t (*read_data)(struct bone_proto_node *you, struct iovec *into, int
numiov, int32 flags, bigtime_t timeout, struct sockaddr *addr, int len);
int32 (*read_avail)(struct bone_proto_node *you);- called to determine how
many bytes can be read without blocking
status_t (*accept)(struct bone_proto_node *you, struct bone_proto_node *clone);
status_t (*bind)(struct bone_proto_node *you, struct sockaddr *sa);
status_t (*unbind)(struct bone_proto_node *you, struct sockaddr *sa); - I'm not
sure about the purpose of this call
status_t (*listen)(struct bone_proto_node *you, int count);
status_t (*shutdown)(struct bone_proto_node *you, int direction); - closes our
side of the connection
status_t (*control)(struct bone_proto_node *you, int level, int cmd, void *arg,
int arglen); - called on ioctl or setsockopt
status_t (*error)(int32 error_code, bone_data_t *error_data); - interface for
error reporting (ICMP)
status_t (*error_reply)(struct bone_proto_node *you, bone_data_t *caused_error,
uint32 error_code, void *error_data);
- interface for error replies (ICMP)
int32 (*getMTU)(struct bone_proto_node *you, struct sockaddr *sa); - get
route MTU
route_t (*get_route)(struct bone_proto_node *you, struct sockaddr *addr); -
get route
-Protocol module interfaces with Data Link module via:
status_t (*receive_data)(bone_data_t *data);
-Datalink module - manages network interfaces, handles ARP operations:
void (*register_interface)(ifnet_t *ifnet);
status_t (*up)(ifnet_t *ifnet);
void (*down)(ifnet_t *ifnet);
status_t (*setMedia)(ifnet_t *ifnet, uint32 media);
status_t (*setPromiscuous)(ifnet_t *ifnet, int on);
status_t (*getHardwareAddr)(ifnet_t *ifnet, bone_iface_hwaddr_t *addr);
status_t (*send_data)(ifnet_t *ifnet, bone_data_t *data); - send data on the
specified interface
status_t (*send_data_nonblocking)(ifnet_t *ifnet, bone_data_t *data);
-Framing module - ecapsulates into packet into a frame/decapsulates frame into
a packet, performs checksum (FCS) calculations
-I'm not sure if this is all we need...
status_t (*frame_data)(ifnet_t *ifnet, bone_data_t *data);
status_t (*deframe_data)(ifnet_t *ifnet, bone_data_t *data);
void (*compute_fcs)(bone_data_t *data); - calculates FCS (frame check sequence)
-Physical layer [Ethernet] driver
status_t (*up)(void);
void (*down)(void);
status_t (*setMedia)(uint32 media);
status_t (*send_data)(bone_data_t *data);
status_t (*send_data_nonblocking)(bone_data_t *data);
status_t (*receive_data)(bone_data_t **data);
status_t (*setMTU)(uint32 mtu);
status_t (*setPromiscuous)(int on);
status_t (*getHardwareAddr)(bone_iface_hwaddr_t *addr);
******* New Message ********
Subject: [openbeosnetteam] Re: Random muslings
Date: Mon, 5 Nov 2001 01:13:18 +0100
Hi all,
>Hi all. I've bowed my head in shame a few weeks ago, and what can I say,
>BeOS is like a drug which (once addicted) is a habit hard to break. Elate
>isn't as much fun as I thought it would be, and I'm slowly becoming aware
>that there may be a possibility that I'll come crawling back to the lovin'
>OpenBeOS arms (if you'll take me back :-)
hehe. Nice to see you back :-)
>What does the OpenBeOS networking team need to implement?
>
>1) The Network Kit front end.
>This is the API presented to the user. User applications use the interface
>by referencing BeAPI header files and Posix header files. The network team
>needs to re-implement the following frontend (from the BeBook):
> a)- BNetAddress class (convert net addresses to generic internal
>type) - easy
> b)- BNetBuffer class (allocate buffer and append/delete data) - easy
> c)- BNetDebug class (debug info) - piece of cake
> d)- BNetEndpoint (object oriented socket - wrapper for socket calls)
>- slightly moderate
All this is quite easy. It can be built using Nettle's source code, which can
be found on bebits.
Basically all it needs is adding BArchivable methods (plus a couple
constructors and methods) to
each class. I have begun work on this but I must admit I've been waaaaay tooooo
slooowwww
on this ^_^ I only worked on BNetAddress so far :-(
> e)- network sockets - moderate to time consuming (the meat of the
>kit).
> - socket()
> - bind()
> - getsockname()
> - getpeername()
> - recvfrom()
> - sendto()
> - send()
> - recv()
> - listen()
> - accept()
> - connect()
> - closesocket()
> - shutdown()
> - setsockopt()
> - select()
> f)- BSD network database interface - easy
> - gethostbyname()
> - gethostbyaddr()
> - getservbyname()
> - herror()
> - inet_addr()
> - inet_ntoa()
> - gethostname()
> - getusername()
> - getpassword()
> g)- Network settings - easy
> - findnetsettings()
> - setnetsettings()
>
> Thats all we need to be source compatible.
> h) - additions to the API (wish list)
>
> From the OSI layered model point of view, the front end could
>corrolate to the Transport and Session layers.
>
>2) The Network Kit back end
>This is the actual net_server which interfaces with the kernel/hardware.
>From the OSI perspective, it provides the functionality of the Data-Link and
>Network layers. The average developer writing a network application
>considers the back end to be a black box. Until I finish reading the
>FreeBSD design book, I cannot comment on the structure of the black box.
>
>Marcus Overhaggen from the Media Kit team did an excellent job of
>demonstrating how to convert the B header files into a dummy C program with
>pluggin functions - empty pluggin functions for now (a single debug printf()
>to show status), but functions which will be filled in as the team
>progresses. Marcus honestly believes that binary compatibility is possible,
>and so far he can get 3rd party apps to link without errors (of course, they
>dont run yet). I think that a couple of members of the Networking team (a
>couple and no more) can attempt the same with the above front end. This
>will show progress to the rest of the OpenBeOS teams, and will allow the
>very first files to be checked into CVS.
I personnally like Erik Jakowatz's approach :o) I hadn't understood clearly
what Erik had done
until he sent me an email last week explaining how he did achieve a wrapper
library. His approach
enables binary compatibility even while working on the library.
Basically Erik makes a wrapper library (let's call it "WLib") that will export
the same symbols as
the original library (let's call it BAPILib). He then moves BAPILib to another
location (so that the
system won't want to call it but will call WLib instead) and opens it from WLib.
>From there, here is what we can do:
When WLib is called, it calls BAPILib to achieve the result if the call has not
been rewritten yet.
It can even output some debug info before and after calling BAPILib.
If the call has already been rewritten, well then WLib does the job itself
without calling BAPILib
:o)
That way at a given instant you always keep full binary compatibility and
replace calls one after
the other, until the whole library is done.
Although Erik didn't use the tool Marcus suggested (stubgen), nothing prevents
us from using it
as well (hehe ^_^), as stubgen only creates empty cpp files from Be headers.
This can be used
as the first step for the wrapper.
So it all turns down to:
- Using nm a first time to give a quick look to which symbols are exported by a
library.
- Identify which BeOS header files correspond to those symbols
- Run stubgen on those header files
- Run nm again to identify which symbols are missing and add them
- From the resulting cpp file, call the original library
- Move the original library out of the way, test and debug the wrapper to make
sure it works
- When the wrapper is made to work, implement the calls
You will find the mail explaining the binary compatibility process there (as
Erik explained it):
http://www.profuzion.org/en/openbeos_net_team/binary_comp.html
I also put the Wish List online (as Emmanuel put together what had been said):
http://www.profuzion.org/en/openbeos_net_team/wish_list.html
And the layout (as Dmitri drawed it):
http://www.profuzion.org/en/openbeos_net_team/netlayer_layout.html
Comments on any of the above are very welcome!
>As far as everyone else is
>concerned, the black box can be a rip off of the FreeBSD networking
>implementation (hey, nothing to be ashamed of, its one of the best in the
>industry),
... and it's already used nearly everywhere ;o)
>and all they really want is source level (100% possible) and even
>better, binary compatibility (possible).
>
>Anyway, I'm prepared to take the challenge of preparing the header/pluggin
>files. Is that OK with you Jean (glorious team leader)?
Sure :^)
Please make sure you check Erik's work an tell us what you think about it
first, I think it's really
worth it. You'll find everuthing about it at the URL above.
Jean
******* New Message ********
Subject: [openbeosnetteam] Wrapper library
Date: Mon, 5 Nov 2001 15:20:31 +1100
Jean Schwerer wrote:
> Sure :^)
> Please make sure you check Erik's work an tell us what you think about it
> first, I think it's really
> worth it. You'll find everuthing about it at the URL above.
>
>
[Zenja Solaja] I've looked at the links you've provided, a very
informative read. Eric has taken the approach of replacing one component at
a time while always having a complete module (the other untouched
components) until eventually all components are replaced. This ensures
compatibility and functionality where this approach is possible, and for
some kits (ie. the Support Kit) this is the way to go since each component
is separate from the others, hence you can replace them peice-meal (ie.
BString and BList).
Unfortunately, with some kits (like the media kit and the
net_server) we've got the problem of dependency with unknown internal
functions and an unknown state machine which constitutes the server. We
know the public interface, but not what states and messages it sends to the
server. Erics approach can help with some components which are
non-dependant on the server internals, but the brunt of the server needs a
complete replacement, hence the global pluggin support suggested by Marcus
seems like a more appropriate path for us to take.
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Re: Wrapper library
Date: Thu,
8 Nov 2001 22:41:39 +0100
Hello,
> [Zenja Solaja] I've looked at the links you've provided, a very
>informative read. Eric has taken the approach of replacing one component at
>a time while always having a complete module (the other untouched
>components) until eventually all components are replaced. This ensures
>compatibility and functionality where this approach is possible, and for
>some kits (ie. the Support Kit) this is the way to go since each component
>is separate from the others, hence you can replace them peice-meal (ie.
>BString and BList).
>
> Unfortunately, with some kits (like the media kit and the
>net_server) we've got the problem of dependency with unknown internal
>functions and an unknown state machine which constitutes the server. We
>know the public interface, but not what states and messages it sends to the
>server. Erics approach can help with some components which are
>non-dependant on the server internals, but the brunt of the server needs a
>complete replacement, hence the global pluggin support suggested by Marcus
>seems like a more appropriate path for us to take.
Good and valid point, granted :^)
So now we all rely on you for building the empty cpp files... ;-)
Jean
******* New Message ********
Subject: [openbeosnetteam] Some admin stuff
Date: Fri, 9 Nov 2001 00:27:07 +0100
Hello,
Michael Phipps asked for a couple of things. While he says he only sent the
email to the team
leads I guess you're all interested by some part of the email so quotation
follows:
[begin quote]
I would like to try to update source control once per month from now on. What
that means is
that the best code we can lay our hands on that builds (later, this will be
works) should go into
source control around the end of the month. Many people are becoming
discouraged because we
have nothing in source control. We *do* have code. No one can see it. I, too,
would prefer to keep
everything local until I am 100% satisfied with it. But losing people over it
is not worth it.
[end quote]
We haven't gotten to "milestone" a list of events and give our milestones
timestamps yet. So it
should be a good time to start doing so :o)
Milestone # - Priority (1-5, 1 = highest) - Ending Date - Description - Person
in charge - Difficulty
1 - 1 - ASAP - Turning B header files into a dummy C program with empty pluggin
functions (aka
building empty cpp files :P) - Zenja - ?
2 - 2 - ASAP - Testing a lib build *and loading* based on the previous "dummy C
program" -
Zenja? - ?
3 - 1 - ASAP, needed for next monthly source control update - Reimplementing
the Be Network
API (sourcewise) based on sockets - Jean (aka myself) - Easy :oP (I guess and
hope so...)
4 - 2 - End of november - Comparing the layout (http://www.profuzion.org/en/
openbeos_net_team/netlayer_layout.html) Dmitri drawed based on bone.txt (I know
where you
get your inspiration from :P) against the R5 NON BONE net_server libs model. -
??? (any
taker?)??? - Medium difficulty ?
5 - 1 - Test driver interfacing: build a sample program that sends dummy data
to the network
card and stupidly prints to stdout incoming network traffic received by the
card. To be tested
using another machine running some sniffing program - ??? (any taker?)??? - ???
Any thoughts about that? Any taker for the two last milestones? Any other
*urgent*
milestone to add (we'll add non-urgent milestones to the list later on)? Any
comments on the
current milestones?
Can you please all make sure you have a sourceforge account and let me know
your sourceforge
identity? Thanks. I have your email addresses but sourceforge ids would be cool
for me to have
too :o) If you don't have a sourceforge account, you really should consider
creating one ^_^
Last but not least, the "old guys" on this list have to welcome a couple of
newcomers:
- Erik Reid, from...?, well I don't know where from ^_^
- Francesco Salvestrini (Francesco, I noticed you subscribed to the Mailing
List with a different
email address than the one Michael gave me, which one do you prefer me to
use?), from Italia?
- Robson Braga Araujo, from Brazil?
Jean
******* New Message ********
Subject: [openbeosnetteam] Re: Some admin stuff
Date: Fri, 9 Nov 2001 10:39:03 +1100
> Milestone # - Priority (1-5, 1 = highest) - Ending Date - Description -
> Person in charge - Difficulty
> 1 - 1 - ASAP - Turning B header files into a dummy C program with empty
> pluggin functions (aka
> building empty cpp files :P) - Zenja - ?
> 2 - 2 - ASAP - Testing a lib build *and loading* based on the previous
> "dummy C program" -
> Zenja? - ?
[Zenja Solaja] OK. I'll be busy this weekend ;-) Lets start
rollin' rollin' rollin'...(Rawhide from Blues Brothers)
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Re: Some admin stuff
Date: Fri, 9 Nov 2001 07:46:22 +0100
I have some lack of time and must answer some previous maisl but I'd like to
tell you I'm already working on driver interfacing :-p
Good news no ?
You can assign me this one, I love sniffin' :-)
M@.net
----- Original Message -----
From: "Jean Schwerer" <j-schwerer@xxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Friday, November 09, 2001 12:27 AM
Subject: [openbeosnetteam] Some admin stuff
>
> Hello,
>
> Michael Phipps asked for a couple of things. While he says he only sent
the email to the team
> leads I guess you're all interested by some part of the email so quotation
follows:
>
> [begin quote]
> I would like to try to update source control once per month from now on.
What that means is
> that the best code we can lay our hands on that builds (later, this will
be works) should go into
> source control around the end of the month. Many people are becoming
discouraged because we
> have nothing in source control. We *do* have code. No one can see it. I,
too, would prefer to keep
> everything local until I am 100% satisfied with it. But losing people over
it is not worth it.
> [end quote]
>
> We haven't gotten to "milestone" a list of events and give our milestones
timestamps yet. So it
> should be a good time to start doing so :o)
> Milestone # - Priority (1-5, 1 = highest) - Ending Date - Description -
Person in charge - Difficulty
> 1 - 1 - ASAP - Turning B header files into a dummy C program with empty
pluggin functions (aka
> building empty cpp files :P) - Zenja - ?
> 2 - 2 - ASAP - Testing a lib build *and loading* based on the previous
"dummy C program" -
> Zenja? - ?
> 3 - 1 - ASAP, needed for next monthly source control update -
Reimplementing the Be Network
> API (sourcewise) based on sockets - Jean (aka myself) - Easy :oP (I guess
and hope so...)
> 4 - 2 - End of november - Comparing the layout
(http://www.profuzion.org/en/
> openbeos_net_team/netlayer_layout.html) Dmitri drawed based on bone.txt (I
know where you
> get your inspiration from :P) against the R5 NON BONE net_server libs
model. - ??? (any
> taker?)??? - Medium difficulty ?
> 5 - 1 - Test driver interfacing: build a sample program that sends dummy
data to the network
> card and stupidly prints to stdout incoming network traffic received by
the card. To be tested
> using another machine running some sniffing program - ??? (any
taker?)??? - ???
>
> Any thoughts about that? Any taker for the two last milestones? Any other
*urgent*
> milestone to add (we'll add non-urgent milestones to the list later on)?
Any comments on the
> current milestones?
>
> Can you please all make sure you have a sourceforge account and let me
know your sourceforge
> identity? Thanks. I have your email addresses but sourceforge ids would be
cool for me to have
> too :o) If you don't have a sourceforge account, you really should
consider creating one ^_^
>
> Last but not least, the "old guys" on this list have to welcome a couple
of newcomers:
> - Erik Reid, from...?, well I don't know where from ^_^
> - Francesco Salvestrini (Francesco, I noticed you subscribed to the
Mailing List with a different
> email address than the one Michael gave me, which one do you prefer me to
use?), from Italia?
> - Robson Braga Araujo, from Brazil?
>
> Jean
>
******* New Message ********
Subject: [openbeosnetteam] Re: Some admin stuff
Date: Mon, 26 Nov 2001 23:50:33 -0700
Quoth "Jean Schwerer":
>
>We haven't gotten to "milestone" a list of events and give our milestones
>timestamps ye
>t. So it
>should be a good time to start doing so :o)
>Milestone # - Priority (1-5, 1 = highest) - Ending Date - Description - Person
>in charg
>e - Difficulty
>1 - 1 - ASAP - Turning B header files into a dummy C program with empty
>pluggin functio
>ns (aka
>building empty cpp files :P) - Zenja - ?
>2 - 2 - ASAP - Testing a lib build *and loading* based on the previous "dummy
>C program
>" -
>Zenja? - ?
>3 - 1 - ASAP, needed for next monthly source control update - Reimplementing
>the Be Net
>work
>API (sourcewise) based on sockets - Jean (aka myself) - Easy :oP (I guess and
>hope so..
>.)
>4 - 2 - End of november - Comparing the layout (http://www.profuzion.org/en/
>openbeos_net_team/netlayer_layout.html) Dmitri drawed based on bone.txt (I
>know where y
>ou
>get your inspiration from :P) against the R5 NON BONE net_server libs model.
>- ??? (an
>y
>taker?)??? - Medium difficulty ?
>5 - 1 - Test
driver interfacing: build a sample program that sends dummy data to the ne
>twork
>card and stupidly prints to stdout incoming network traffic received by the
>card. To be
> tested
>using another machine running some sniffing program - ??? (any taker?)??? - ???
Haven't seen much action on the list lately, just wondering where we're at?
Do we have a base structure to use? Do we have some alternate cvs(or other)
playground
for us to use until the build meister gets everything organized? (Anybody know
where
the build meister is at with regards to people being able to commit stuff?)
>Last but not least, the "old guys" on this list have to welcome a couple of
>newcomers:
>- Erik Reid, from...?, well I don't know where from ^_^
Calgary, Alberta, Canada. :)
(sourceforge id is freyr, I think)
******* New Message ********
Subject: [openbeosnetteam] Re: Some admin stuff
Date: Tue, 27 Nov 2001 22:56:05 +0100
----- Original Message -----
From: "Erik Reid" <reide@xxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Tuesday, November 27, 2001 7:50 AM
Subject: [openbeosnetteam] Re: Some admin stuff
8< snip !
>
> Haven't seen much action on the list lately, just wondering where we're
at?
>
Ok, for my part I have time concerns for the moment but I was (and still am)
in the process to study how to interface network drivers.
Based on a old sample code from Be I was trying to directly interface a
driver to send and receive frames.
Next step should be to try to design and implement a basic TCP/IP stack
(ARP, ICMP, IP, UDP, TCP)
In parralel with that another research group could try to understand how the
network preference pannel is working and how does it interract with network
stuff (objective: build our own replacement pref pannel)
Another thing I'd like to understand is how does the DHCPclient interface
with the network system... If anybody can help with that, I'd be glad.
Anyway has I told before, I have problems to get enough free time for
OpenBeOS to be as effective as I'd like to be...
But I can help and give all the source code and information I collected in
the area of this project :-)
> Do we have a base structure to use? Do we have some alternate cvs(or
other) playground
> for us to use until the build meister gets everything organized? (Anybody
know where
> the build meister is at with regards to people being able to commit
stuff?)
As far as I'm concerned I don't have any workable network code yet and I'm
not aware of any cvs repository for network code other than the main project
CVS.
What about others ? I don't know...
Please, everybody on the list, could you give us a feedback / status ?
Best regards,
Emmanuel
8< snip
******* New Message ********
Subject: [openbeosnetteam] What's going on [Was: Some admin stuff]
Date: Wed, 28 Nov 2001 00:53:41 +0100
Hi all,
[Erik]
>Haven't seen much action on the list lately, just wondering where we're at?
Couldn't find the time to finish BeOS API stuff but I am still dedicated to my
deadline (end of
this week), although I know I probably won't make it ^_^ I've been running out
of time because
of job searching for nearly three months now but good news is I finally will
start on a new job in
one week. So expect me to become more active then ^_^
It looks like I'm waiting too long before sending reminders to inactive
contributors so I believe I
should send a weekly reminder to those persons from now on ^_^
[Emmanuel]
>Ok, for my part I have time concerns for the moment but I was (and still am)
>in the process to study how to interface network drivers.
>Based on a old sample code from Be I was trying to directly interface a
>driver to send and receive frames
[...]
>But I can help and give all the source code and information I collected in
>the area of this project :-)
Would love to know what information you collected so far because as soon as I
have finished
the BeOS API stuff I'd love to jump in on this part.
[Erik]
>Do we have a base structure to use? Do we have some alternate cvs(or other)
>playground
>for us to use until the build meister gets everything organized? (Anybody know
>where
>the build meister is at with regards to people being able to commit stuff?)
As far as I'm concerned my code is not ready yet. As soon as there's something
usable you'll be
my first alpha-testers ^_^. There shouldn't be much to test except for those of
you who have
BONE, as the libnetapi works with R5 but not with BONE (listening sockets don't
work).
[Emmanuel]
>I'm not aware of any cvs repository for network code other than the main
>project CVS.
Just the same for me ^_^
[Erik]
>>Last but not least, the "old guys" on this list have to welcome a couple of
>>newcomers:
>>- Erik Reid, from...?, well I don't know where from ^_^
>
>Calgary, Alberta, Canada. :)
>
>(sourceforge id is freyr, I think)
ok :o)
Well, I'm glad to see Erik post to this list (at long last). Please don't
forget the list is open to
suggestions and I'd like to hear from all the "newcomers". Didn't get a single
answer from the
"newcomers" to this thread. Writing emails steals a lot of time away from
coding, but those who
are not coding yet have no excuse for not answering :o)
Francesco, Robson, can we finally get some news from you?
Zenja, can you please give us an update as far as the "dummy C program files"
are concerned?
Jean
******* New Message ********
Subject: [openbeosnetteam] Re: What's going on [Was: Some admin stuff]
Date: Wed, 28 Nov 2001 13:31:59 +1100
> Zenja, can you please give us an update as far as the "dummy C program
> files" are concerned?
>
[Zenja Solaja] Damn, Civ3 came out ;-) Its ruining my social life.
To make matters worse, I finally decided that the time is finally right and
purchased my first DVD player (Marantz DV4200) which should arive any day
now . . .
Double damn!!!!
Maybe next week ;-)
>
>
>
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Re: What's going on [Was: Some admin stuff]
Date: Tue, 27 Nov 2001 19:40:33 -0700
Quoth Zenja Solaja:
>
>
>> Zenja, can you please give us an update as far as the "dummy C program
>> files" are concerned?
>>
> [Zenja Solaja] Damn, Civ3 came out ;-) Its ruining my social life.
>To make matters worse, I finally decided that the time is finally right and
>purchased my first DVD player (Marantz DV4200) which should arive any day
>now . . .
>
> Double damn!!!!
>
> Maybe next week ;-)
If it's just a skeleton that you're looking at building, I don't mind doing
that,
if you don't foresee it being done in the next week or two..
******* New Message ********
Subject: [openbeosnetteam] Re: What's going on [Was: Some admin stuff]
Date: Wed, 28 Nov 2001 13:51:38 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain
Content-Transfer-Encoding: 8bit
X-archive-position: 39
X-listar-version: Listar v1.0.0
Sender: openbeosnetteam-bounce@xxxxxxxxxxxxx
Errors-To: openbeosnetteam-bounce@xxxxxxxxxxxxx
X-original-sender: solaja@xxxxxxxxxx
Precedence: normal
Reply-To: openbeosnetteam@xxxxxxxxxxxxx
X-list: openbeosnetteam
Feel free . . . its a one day (no brainer) job.
> -----Original Message-----
> From: Erik Reid [SMTP:reide@xxxxxxxxxxx]
> Sent: Wednesday, November 28, 2001 1:41 PM
> To: openbeosnetteam@xxxxxxxxxxxxx
> Subject: [openbeosnetteam] Re: What's going on [Was: Some admin
> stuff]
>
> Quoth Zenja Solaja:
> >
> >
> >> Zenja, can you please give us an update as far as the "dummy C program
> >> files" are concerned?
> >>
> > [Zenja Solaja] Damn, Civ3 came out ;-) Its ruining my social life.
> >To make matters worse, I finally decided that the time is finally right
> and
> >purchased my first DVD player (Marantz DV4200) which should arive any day
> >now . . .
> >
> > Double damn!!!!
> >
> > Maybe next week ;-)
>
> If it's just a skeleton that you're looking at building, I don't mind
> doing that,
> if you don't foresee it being done in the next week or two..
>
>
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] Re: What's going on [Was: Some admin stuff]
Date: Wed, 28 Nov 2001 21:29:54 +0100
LoL :-)
Are we the same ?
Double - LoL !!
Best Regards,
Emmanuel
----- Original Message -----
From: "Zenja Solaja" <solaja@xxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Wednesday, November 28, 2001 3:31 AM
Subject: [openbeosnetteam] Re: What's going on [Was: Some admin stuff]
>
>
> > Zenja, can you please give us an update as far as the "dummy C program
> > files" are concerned?
> >
> [Zenja Solaja] Damn, Civ3 came out ;-) Its
ruining my social life.
> To make matters worse, I finally decided that the time is finally right
and
> purchased my first DVD player (Marantz DV4200) which should arive any day
> now . . .
>
> Double damn!!!!
>
> Maybe next week ;-)
>
> >
> >
> >
> ----------------------
> CONFIDENTIALITY NOTICE
> ----------------------
> This email is intended only to be read or used by the addressee.
> The information contained in this e-mail message may be confidential
> information. If you are not the intended recipient, any use, interference
> with, distribution, disclosure or copying of this material is unauthorised
> and prohibited. Confidentiality attached to this communication is not
waived
> or lost by reason of the mistaken delivery to you.
>
> If you have received this message in error, please delete it and notify us
> by return e-mail or telephone Aristocrat Technologies Australia Pty
Limited
> on +61 2 9413 6300.
******* New Message ********
Subject: [openbeosnetteam] beos drivers..
Date: Tue, 04 Dec 2001 00:41:54 -0700
I realize this isn't the best place for this, but I'm not sure what is, and it's
sort of relevant, I guess.. :)
I've got an SMC Etherpower, and I'm trying to get it working in regular beos.
not supported by the normal install, no drivers as far as I know, so I'm trying
to write one.
Apparently my motherboard has ACPI stuff, and I can't get the IRQ out of the
pci_info struct. Not sure what to do.
Any help?
(I have started on the netkit skeleton, but only got an hour or so into it
before getting distracted by this not-having-network issue)
After talking to mphipps on irc for a bit, he also suggested that we should
be free to work in the cvs repository, despite not having 'proper' build stuff.
******* New Message ********
Subject: [openbeosnetteam] 12/12/2001 Status
Date: Thu, 13 Dec 2001 00:55:56 +0100
Hi all,
as far as I'm concerned I'll make it clear I didn't touch a single line of code
for the past 15 days.
Just didn't have the time. However I finally could free some time in tomorrow's
timetable so I
should be able to code a little bit tomorrow.
Wednesday is handier for me to send status reports so I will send weekly
reports (and ask for
your reports) on wednesdays from now on.
[Erik Reid, "beos drivers.."]
Unfortunately I have no idea how to help about your driver problem.
>(I have started on the netkit skeleton, but only got an hour or so into it
>before getting distracted by this not-having-network issue)
Did you get back to working on the skeleton since your mail or did you focus on
the driver thing
(or whatever else)?
[Zenja Solaja, "What's going on"]
>Damn, Civ3 came out ;-)
Damn, I only have Civ2. I'm 200% sure I should NOT try Civ3 otherwise I might
become
counterproductive for at least two months in a row ^_^.
Please, please, resist the temptation ^_^ We need you!!!
[Myself, "What's going on"]
>Francesco, Robson, can we finally get some news from you?
Still no news and no answer. Are you willing to contribute anything (code or
ideas) before
Christmas?
[Myself again, quoting Emmanuel in "What's going on"]
>Ok, for my part I have time concerns for the moment but I was (and still am)
>in the process to study how to interface network drivers.
[...]
>But I can help and give all the source code and information I collected in
>the area of this project :-)
As I already wrote then, I would love to know what information you collected so
far. Can you
please either send me that information by email or even better could we set up
an irc / icq /
jabber / whatever else meeting so you can explain me what information you got
so far? Thanks!
Other than that, were you able to get any free time for OpenBeOS in the past 2
weeks?
Please give me some news all of you!
Jean
******* New Message ********
Subject: [openbeosnetteam] Re: 12/12/2001 Status
Date: Wed, 12 Dec 2001 21:57:04 -0700
Quoth "Jean Schwerer":
>
>Hi all,
>
>as far as I'm concerned I'll make it clear I didn't touch a single line of
>code for the
>past 15 days.
>Just didn't have the time. However I finally could free some time in
>tomorrow's timetabl
>e so I
>should be able to code a little bit tomorrow.
>Wednesday is handier for me to send status reports so I will send weekly
>reports (and as
>k for
>your reports) on wednesdays from now on.
Are you working on the network stack itself?
Where are you with what you've got?
>Did you get back to working on the skeleton since your mail or did you focus
>on the driv
>er thing
>(or whatever else)?
I've now managed to get another machine with which I can do development, and
should
be able to actually use a network device under beos :)
I should be able to get back onto the skeleton by Sunday at the latest.
Hopefully
by next Tuesday/Wednesday I'll have a net_server that loads, and a library that
compiles. :)
Would it be a good idea to have an OBOS Netkit web page set up, with milestones,
current progress, current members, etc? (I note there is a page at
http://open-beos.sourceforge.net/tms/net.html , who has write access to that,
or time to update it?)
******* New Message ********
|
|
