code.google.com?

[scott mc]

For a wiki and a repo maybe we can setup a project on google code:
http://code.google.com
I've not used it yet, but seems like it would be a place to start.

-scottmc

[Matthew Dillon]

Interesting.  They have a project hosting page that looks suitable.  The only repositories supported are svn and mercurial but if that's the only issue it's a minor one.

I've created a project called 'rosetta-os', http://code.google.com/p/rosetta-os/
It looks like it uses gmail master accounts so I'll try adding everyone to it.

-Matt

[Dillon]

I was able to add everyone listing a @gmail.com address but it
wouldn't let me add people with non-gmail.com addresses (since I guess
it needs the gmail login for account management).

These couldn't be added: beng, anant, bkorb, baallan, dyoung, christos
(@ various suffixes)

The easiest thing to do is to just email me your @gmail.com address,
or change your subscription to the google group to use your @gmail.com
address and I can then snarf if from the members list.

p.s. We don't have to use the google repo but google has a nice wiki
and it looks like a bug reporting system too and we might as well use
those. I personally prefer git over svn or hg because each project
can manage its own local repo. We could then have one master server
for rollups. It's probably worth a discussion just to see what source
control system various people prefer.

-Matt

[Anant Narayanan]

Hi,

On Wed, Oct 28, 2009 at 9:24 PM, Dillon <mattdi...@gmail.com> wrote:

I was able to add everyone listing a @gmail.com address but it
wouldn't let me add people with non-gmail.com addresses (since I guess
it needs the gmail login for account management).

That shouldn't be the case, support for non-gmail Google Accounts was added sometime ago: http://code.google.com/p/support/issues/detail?id=213

p.s.  We don't have to use the google repo but google has a nice wiki
and it looks like a bug reporting system too and we might as well use
those.  I personally prefer git over svn or hg because each project
can manage its own local repo.  We could then have one master server
for rollups.  It's probably worth a discussion just to see what source
control system various people prefer.

For Plan 9, we'd prefer mercurial. There is a git port but I'm not sure it's completely usable yet, but it might work too. svn is definitely not an option.

Regards,

Anant

[scott mc]

> For Plan 9, we'd prefer mercurial. There is a git port but I'm not sure it's
> completely usable yet, but it might work too. svn is definitely not an
> option.
> Regards,
> Anant
>

For Haiku, svn, git or mercurial would all be ok.

-scottmc

[Arun Thomas]

MINIX 3 doesn't have a preference. Git, Mercurial, or SVN would be
fine. We use SVN currently, but we plan to move over to git.

Arun

[Dillon]

For the record, DragonFly uses git. We switched from CVS and haven't
looked back since.

I've started creating a little infrastructure on the Wiki for an API
document. Everyone should feel free to edit it as well as to create
other base pages. Don't worry too much about commit messages on edit-
saves for now. Right now I'm just trying to get all the myrid issues
written down so they don't get lost.

On the API, our goal is as we discussed at the GSOC summit. We want a
way to write or port drivers which can be incorporated into any of the
OS projects without further modification and held in a single common
repository. Once ported all the projects can share w/ the
maintainance, port additional drivers from their respective legacy
interfaces to the new standard, and so on and so forth. Generally
speaking the concept is to provide an API with a great deal of
flexibility but which also is inherently collapsible into a simpler
implementation if a particular OS doesn't need that flexibility. E.g.
SMP->UP, multi-thread->single-threaded. multi-lock->simple
serialization at the interface boundary. Etc.

In particular it is becoming clear to me that one thing we do not
particularly need to do (at least not initially) is build higher level
APIs here. For example, we do not have to define CAM-like functions
to attach drives to 'da0', 'da1', and so forth. The API would allow
the driver to notify the OS of attachments and detachments but then it
would be up to the OS to deal with it from there. Each OS project
would build the Rosetta layer that connects the higher level functions
that already exist to the notification mechanics provided by Rosetta.
The driver itself would be oblivious.

I'm starting from the direction of the simpler chipset drivers (NetIF,
Disk). USB is a bit more complex. I think probably a fully working
API covering (non WIFI) NetIF and Disk devices would cover about 85%
of something as complex as the USB driver. So my hope is that as the
API gets fleshed out the USB work will reveal what that additional 15%
needs to be. I still get the feeling that FreeBSD's USB port still
has a ways to go to really cover the bases, it is very new. We
wouldn't want to try to actually port it to a Rosetta API until it is
more solidly entrenched.

Protocol stacks (tcp, udp, etc) add another level of difficulty
entirely. I am confident that I can flesh out an API which works for
NetIF and Disk quickly. I am not confident at all that I can flesh
out an API that we can move the protocol stacks into. I do have many
ideas in that area w/ regards to how to standardize packet formats,
layer access, and feature flags. Significant retooling would be
needed by everyone to create an API capable of dealing with protocol
stacks and integrate it into the respective OSes.

One thing that might be of interest w/ regards to protocol stacks is
the netgraph code in FreeBSD. People either love it or hate it from
an efficiency standpoint, but it can't be said that it isn't clean.
Would it be possible to move the entire socket() layer and tcp, udp,
and icmp protocol stacks into something like netgraph? It might just
be. Just something to think about.

-Matt

[Chris Johns]

Dillon wrote:
> For the record, DragonFly uses git. We switched from CVS and haven't
> looked back since.

RTEMS is using CVS. Anything but svn is ok with me.

> In particular it is becoming clear to me that one thing we do not
> particularly need to do (at least not initially) is build higher level
> APIs here. For example, we do not have to define CAM-like functions
> to attach drives to 'da0', 'da1', and so forth. The API would allow
> the driver to notify the OS of attachments and detachments but then it
> would be up to the OS to deal with it from there. Each OS project
> would build the Rosetta layer that connects the higher level functions
> that already exist to the notification mechanics provided by Rosetta.
> The driver itself would be oblivious.

This suites RTEMS. Embedded systems tend to range between systems that are
specifically locked down to a certain configuration to systems that
automatically handle devices. We do not have a single solution that works for
all users.

> I'm starting from the direction of the simpler chipset drivers (NetIF,
> Disk). USB is a bit more complex. I think probably a fully working
> API covering (non WIFI) NetIF and Disk devices would cover about 85%
> of something as complex as the USB driver. So my hope is that as the
> API gets fleshed out the USB work will reveal what that additional 15%
> needs to be.

Ok.

> I still get the feeling that FreeBSD's USB port still
> has a ways to go to really cover the bases, it is very new. We
> wouldn't want to try to actually port it to a Rosetta API until it is
> more solidly entrenched.

Interesting.

> Protocol stacks (tcp, udp, etc) add another level of difficulty
> entirely. I am confident that I can flesh out an API which works for
> NetIF and Disk quickly. I am not confident at all that I can flesh
> out an API that we can move the protocol stacks into. I do have many
> ideas in that area w/ regards to how to standardize packet formats,
> layer access, and feature flags. Significant retooling would be
> needed by everyone to create an API capable of dealing with protocol
> stacks and integrate it into the respective OSes.

This is ok. We have a need for drivers and USB so if we can handle these and
have a working environment our initial goal will have been reached.

> One thing that might be of interest w/ regards to protocol stacks is
> the netgraph code in FreeBSD. People either love it or hate it from
> an efficiency standpoint, but it can't be said that it isn't clean.

Interesting piece of code. I had not seen it before. Given it was initially
for bit sync protocols flexibility would have been more important than
performance.

> Would it be possible to move the entire socket() layer and tcp, udp,
> and icmp protocol stacks into something like netgraph? It might just
> be. Just something to think about.

Sounds like a GSoC project for next year ? ;)

Regards
Chris