Welcome

[Werner Almesberger]

Gerald A wrote:
> The debug here isn't application debugging, but rather low level debug which
> will be useful for boot debug, kernel and driver debug, and interactions
> that tweak the kernel into a crash/oblivion.

Yup. I just wanted to make it clear that the serial console also has
uses if the person using it is "merely" a bug reporter, not only in
the hands of the developer fixing the bug.

> Now, the bigger question: Where to go from here? We've chatted about
> fantasies and realities of how the overall process flows, but how can
> community members be a party to this process?

Good question :-) On the hardware side alone, there are still a number
of open questions, such as:

- do we want to contemplate a new/modified hardware design ?
  (The alternative being relying on so-called anti-vendor ports of
  devices already available in the market.)

- if there shall be a new hardware design, would it be something done
  from scratch or based on an existing design ?

- if we want to proceed with an existing design, with which one ?

- then, what degree of openness is desirable, what is achievable ?
  A few possible levels for the process itself:

  - completely open with as low a barrier of entry as possible

  - a closed group does the execution, working in a publicly readable
    repository. The rest can watch and review. (The "reader" vs.
    "writer" distinction could come from access to tools, see below.)

  - a closed group does the execution, eventually releasing "inside"
    details. (That's basically how Openmoko worked so far.)

  There's also the question of what it takes to be able to participate,
  particularly considering that commercial CAD and EDA systems can be
  expensive:

  - proprietary tools needed to read/write

  - proprietary tools needed for writing, read access possible through
    Free tools or via exports made available by writers

  - Free tools used for read and write

There are plenty of other things to consider, such as marketing goals,
financing, production, QA, distribution, etc.

Returning to the technical side, we don't have to wait for all of those
decisions to be taken. If we consider an as-open-as-possible process,
then there are obstacles that can be worked on even without having the
full set of objectives mapped out.

E.g., Openmoko relied on proprietary tools for EDA and CAD. Replacing
them with Free Software would be desirable within the framework of
trying to open the process.

Would there be interest in starting such an activity ?

- Werner