DDE - interesting or horrible?

[staalmannen]

The L4 guys [1] (and later the HURD guys [2, 3]) have apparently been
able to re-use some linux drivers through a library-based approach.
Would a similar approach be interesting as a temporary way to get a
wider range of drivers fast-and-dirty ported to a Plan9 kernel?

[1] http://wiki.tudos.org/DDE/DDEKit
[2] http://www.gnu.org/software/hurd/user/zhengda.html
[3] http://www.archhurd.org/

[Uriel]

No.

[Thomas Pedersen]

Is it that bad? Certainly we can do better than rewriting the same
drivers every time a new OS comes out, no?

[Kurt H Maier]

On Mon, Aug 8, 2011 at 8:17 PM, Thomas Pedersen <twped...@gmail.com> wrote:
> Is it that bad? Certainly we can do better than rewriting the same
> drivers every time a new OS comes out, no?

Considering that the drivers are the interface between the kernel and
the hardware, no, we can't. New kernel, new drivers. That way you're
not stuck with the bad decisions of your predecessors, and are free to
make entirely new bad decisions.
--
# Kurt H Maier

[hiro]

Simpler to answer with a question: What is the kernel?

[Iruatã Souza]

On Mon, Aug 8, 2011 at 10:01 PM, hiro <23h...@googlemail.com> wrote:
> Simpler to answer with a question: What is the kernel?
>

Please, do not make this the new 9fans.

[Julius Schmidt]

> Is it that bad? Certainly we can do better than rewriting the same
> drivers every time a new OS comes out, no?

http://aiju.de/up/plan9duck.png

[Thomas Pedersen]

mkay, how is wireless driver support in plan9 anyway? Does it even
have an 802.11 stack?
>

[Jacob Todd]

Yes. See plan9.ini(8).

[Jens Staal]

The DDE does also not only implement an interface to Linux
drivers/subsystems. In addition to DDE/Linux2.6, there is a DDE/FBSD
(FreeBSD), if that would be more appealing.

As was mentioned in another reply regarding drivers: it is hard to
write them without the hardware - so perhaps a "quick and dirty"
interface layer to existing ones could be a stepping stone (like
NDISwrapper was for wifi on linux before).

On the other hand, I do not want to start a lengthy discussion about
these things. I was just curios to hear what people might think about
it. (and perhaps a "Plan9 with DDE drivers" would be easier to
implement using LP49 anyway...).

2011/8/9 Jacob Todd <jaket...@gmail.com>:

[Steve Simon]

> http://aiju.de/up/plan9duck.png

Sadly this doesn't render properly on plan9,
well the labs distro at least, perhaps its fixed on 9front.

-Steve

[cinap_...@gmx.de]

works fine here. maybe its the 24 bit alpha bug? 9front
has the patches. how does it fail?

--
cinap

[Ethan Grammatikidis]

Renders fine here too, labs & 9front. My copy of the labs distro runs
in 9vx. 9front was tried on the hardware (1024x768x32 VESA) and via
cpu(1) from the labs 9vx. Neither system is quite up to date, with the
labs install being a few months old.

[yy]

2011/8/10 Ethan Grammatikidis <eek...@fastmail.fm>:

The bug depends on the libmemdraw used by the drawing device. As long
as you use 9vx to display, you are using 9vx's libmemdraw. Which tree
you are using does not matter.

The patch was applied in 9vx, but not in the labs' Plan 9. It was
submitted by Erik, but it was rejected because the plan was to use
p9p's libmemdraw, but that has not happened. See:
http://plan9.bell-labs.com/sources/patch/sorry/memdraw32bit/notes

--
- yiyus || JGL .

[Ethan Grammatikidis]

On Wed, 10 Aug 2011 19:25:02 +0200
yy <yiyu...@gmail.com> wrote:

> The patch was applied in 9vx, but not in the labs' Plan 9. It was
> submitted by Erik, but it was rejected because the plan was to use
> p9p's libmemdraw, but that has not happened. See:
> http://plan9.bell-labs.com/sources/patch/sorry/memdraw32bit/notes

A timely reminder of why I chose to support 9front! haha... So, what
are we going to do about it? I'm busy this week or I'd at least try to
apply the patch.

[yy]

2011/8/11 Ethan Grammatikidis <eek...@fastmail.fm>:

afaik, 9front is fine, this has already been fixed.