Which goals?

[Thomas Doerfler]

Hi,

so after my introduction here is one thing that is still a unclear for
me. What are the goals of our common activities. I have read the
various postings here and could extract at least some. I will try to
list them:

- getting a common API between kernel and device driver

- getting drivers, that are portable between different Rosetta-
compatible OSes

- getting USB support

What is yet unclear to me is:

- will the new API be defined in a way that we have to code the
drivers from scratch? Or will we stay as close as possible to existing
(e.g. BSDish) APIs?

My most important requirements for the APIs discussed here are:

- getting a proper, portable API

- supporting a really broad range of machines, starting from a 50MHz/
512K ROM/128K RAM microcontroller up to the next generation SMP multi-
GByte machines.

- getting a broad driver base, shared with as many OSes as possible

I think, before we go into the details, we really should agree into a
set of common, compatible goals, so this is my trigger to start this
discussion.

wkr,

Thomas.

[Bogdan]

Hi again.

I'm sorry for the top-down response but apparently this is how Yahoo! handles stuff. My prior message was about UDI - I still think rather than having a dozen portable driver interfaces we should focus all efforts on one. That would work out best for everyone.

Cheers,
Bogdan

[Thomas Doerfler]

Bogdan,

I have taken the time to look at UDI and from my limited view it looks
quite nice. One thing I found in one of the mails(?) is that drivers
might be shipped in binary form. This is something I can't imaging to
fit in our situation, because the build process for RTEMS is
completely different to at least some of the other OSes we are talking
about (RTEMS is statically linked with its application). But I am sure
this is no show stopper.

But again I want to bring the focus back to my inital question. Before
we discuss a solution (e.g. choose an existing API, create a new
one...), I would really like to see what we want to reach with this
solution. I have thrown in part of my ideas at the beginning of this
thread, so how about any other comments?

wkr,
Thomas.

[Bogdan]

As I've said before, UDI drivers can be shipped in binary form (the specification defines a special tool for extracting drivers from packages). However, given the fact that UDI was designed to be cross-platform, it is also source code compatible. If for some reason it doesn't fit your needs, you can just build drivers using your build process.

I'm not sure what the goals of this project are, from my understanding it's creating a portable driver interface. If this is the case, I'd like to see that UDI is put to good use since it does exactly that.

Cheers,
Bogdan

----- Original Message ----
From: Thomas Doerfler <Thomas....@embedded-brains.de>
To: Rosetta <roset...@googlegroups.com>

[Chris Johns]

Bogdan wrote:
> As I've said before, UDI drivers can be shipped in binary form (the specification defines a special tool for extracting drivers from packages). However, given the fact that UDI was designed to be cross-platform, it is also source code compatible. If for some reason it doesn't fit your needs, you can just build drivers using your build process.
>
> I'm not sure what the goals of this project are, from my understanding it's creating a portable driver interface. If this is the case, I'd like to see that UDI is put to good use since it does exactly that.
>

A question that Thomas asked that I do not think has been answered is about
drivers. Does this mean we need to rewrite existing drivers for UDI ?

The goal of this project is to explore ways to better support sharing of BSD
drivers. All those who initially joined use BSD source in some way and make
different modifications that complicate the merging of updates. We are only
after a way to share drivers at the source code level. We want to start small
with a simple interface such as a network driver and move from there. As a
user of BSD I feel it is up to the BSD developers to select and settle on an
interface and projects like RTEMS will adapt. My understanding is the BSD
developers would like user land driver support. This is what they gain.

Regards
Chris

[Bogdan]

Existing drivers will unfortunately need to be rewritten. However if we have 100 interfaces we will have far less drivers available - UDI is a sound concept and someone always needs to make the first step. There are not many UDI drivers around (anymore) but we can change that. Until we have enough, there's nothing to stop *BSD from using legacy and UDI drivers at the same time.

One nice thing about UDI is that it can be implemented in user or kernel space, for UNIX or non-UNIX, and for any kernel architecture. At the same time it's safe, fast, scalable and flexible. Another cool thing is that there's already 2 FreeBSD UDI environments available in the reference implementation (1 for kernel space and 1 for user space). They're probably dusty and could be done better since that's just a reference implemtnation but it's still an awesome place to start.

Cheers,
Bogdan

P.S.: I have no idea what RTEMS is.

[Chris Johns]

Bogdan wrote:
> Existing drivers will unfortunately need to be rewritten. However if we have 100 interfaces we will have far less drivers available - UDI is a sound concept and someone always needs to make the first step. There are not many UDI drivers around (anymore) but we can change that. Until we have enough, there's nothing to stop *BSD from using legacy and UDI drivers at the same time.

I suppose this all comes down to the BSD people.

>
> One nice thing about UDI is that it can be implemented in user or kernel space, for UNIX or non-UNIX, and for any kernel architecture. At the same time it's safe, fast, scalable and flexible. Another cool thing is that there's already 2 FreeBSD UDI environments available in the reference implementation (1 for kernel space and 1 for user space). They're probably dusty and could be done better since that's just a reference implemtnation but it's still an awesome place to start.
>

That is nice. I feel I need to take a closer look at UDI and see how it fits
into RTEMS then report back.

> P.S.: I have no idea what RTEMS is.

http://www.rtems.org/

A real time embedded operating system that has a 10year old FreeBSD stack in
need of an update. We have a stable and mature user base with some users on
long life cycle projects. We aim at being based on standards. Currently we
have our own network driver interface and an RTEMS user recently added a layer
that allows current BSD drivers to port with minimal source changes. It is
this work that we see as exciting and how this whole discussion and group came
about. We need small changes in the code upstream to allow us to get to
transparent source between the systems.

Regards
Chris

[Anthony Sorace]

Sorry for the delay in addressing anything here; I just got back to
work today. I
mainly wanted to address one point that keeps coming up. Chris Johns
said it
most recently, but it was said by several in our session at the summit:

// All those who initially joined use BSD source in some way...

That isn't actually true. Plan 9, the OS I'm representing here and did
at the
summit, makes no use of BSD driver or networking code; it was all
written
from scratch. This perspective changes the discussion for us somewhat,
in a
few ways.

First, our case is clearly not harmonizing a divergent-but-essentially-
BSD
interface. Focusing on a BSD-ish interface may well still be useful
from a
practical standpoint, given the number of drivers out there, but it
isn't going
to make the job easier for folks like us; we've got an equal amount of
scaffolding to build whether we're targeting BSD, UDI, or something new.

Second, the model of the rest of the system is also more different
from those
more influenced by BSD design. It sounds like we're farther afield
than most
in this group, but I think the same sort of concerns for generality
hold for, say,
Haiku and Minix, among others.

Put another way: !Linux != ~BSD

I agree we should take a good hard look at UDI. It's been years since I
looked at it, but it was aiming at, at the least, a very substantial
subset of
the problem we've set before ourselves. I, too, have to do more
reading and
report my results.

Anthony

[Chris Johns]

Anthony Sorace wrote:
> Sorry for the delay in addressing anything here; I just got back to work
> today. I
> mainly wanted to address one point that keeps coming up. Chris Johns
> said it
> most recently, but it was said by several in our session at the summit:
>
> // All those who initially joined use BSD source in some way...
>
> That isn't actually true. Plan 9, the OS I'm representing here and did
> at the
> summit, makes no use of BSD driver or networking code; it was all written
> from scratch. This perspective changes the discussion for us somewhat, in a
> few ways.

I am sorry for this. I did not know that.

>
> First, our case is clearly not harmonizing a divergent-but-essentially-BSD
> interface. Focusing on a BSD-ish interface may well still be useful from a
> practical standpoint, given the number of drivers out there, but it
> isn't going
> to make the job easier for folks like us; we've got an equal amount of
> scaffolding to build whether we're targeting BSD, UDI, or something new.
>

Agreed. We do have a BSD stack but this is old and needs to be replaced. This
is no small amount of work either.

> Second, the model of the rest of the system is also more different from
> those
> more influenced by BSD design. It sounds like we're farther afield than
> most
> in this group, but I think the same sort of concerns for generality hold
> for, say,
> Haiku and Minix, among others.
>
> Put another way: !Linux != ~BSD
>
> I agree we should take a good hard look at UDI. It's been years since I
> looked at it, but it was aiming at, at the least, a very substantial
> subset of
> the problem we've set before ourselves. I, too, have to do more reading and
> report my results.

I do as well.

Regards
Chris