[haiku-appserver] Re: investigating some bugs - Rudolf have a look at this please

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 31 Mar 2005 15:53:25 +0200 CEST

"Rudolf" <drivers.be-hold@xxxxxxxxxxxx> wrote:
> > - but maybe we're also misunderstanding each other; usually a 
> > component has only one active caretaker.
> I guess that's what it boils down to: you have to try to split up 
> stuff 
> into pieces so that people can work on different pieces in the same 
> time. If people want to work on the same piece, you have to find a 
> way 
> to split that in two pieces. IF that can't be done, then one should 
> have 'control'. Just my point of view. :-)

Yes, that's how it should be done. It's hard to work on a moving 
target; but still, the one in control should be able to accept patches 
that affect his playground.

> > too. And that would be the usual open source approach; other people 
> > don't change your code, they just send you patches to look over and 
> > eventually commit.
> That's something I can work with, and indeed: I'd welcome such stuff. 
> It even came up once or twice in the past ;-)
> There's one limitation however: I need to be able to keep up. (no 
> prob 
> yet)

Yes, I hope that I someday will have problems like this in the kernel, 
too :-)

> > BTW I will need to touch them in a few weeks, but I'll give you a 
> > note before. The reason is that I am (slowly) in the process of 
> > completing the new hardware/driver recognition stuff, and this 
> > causes a new driver interface to be established.
> OK. Please explain before though. BTW do we also have to set that 

I will, definitely. There will be at least one newsletter about this, 
as well as a good piece of documentation (when I get to it and the API 
is more stable :-))

> seperate 'allow cloning' flag for creating areas and such?
> As long as that doesn't interfere with R5 / Zeta, that would be OK to 
> add as well I think.

I am not sure if it interferes with R5/Zeta, but for now we need this 
flag on Haiku (maybe we later want to dump that flag again, but I think 
we should keep it). We can try if it'll work there, but we can always 
make it a compile time solution as well.

> > Of course, I will do it in a way that still allows your drivers to 
> > be 
> > used on R5. It will also only affect the kernel driver, not the 
> > accelerant. 
> Thank god :) The main concerns for me are:
> ->driver should keep working on R5/Zeta
> ->driver's speed should not be influenced in a negative manner
> ->interface driver/accelerant should remain as it is
> ->interface system/accelerant should remain as it is.
> (All R1 of course)
> Agreed??

Yes :-)
Mostly the device recognition part is affected, anyway.

> >As part of that, though, I will also need to remove the 
> > .driver part of your driver names. I also thought about renaming 
> > your 
> > drivers to identify them easier (ie. neomagic instead of nm, nvidea 
> > instead of nv, matrox instead of mga). This change could be 
> > restricted to the Haiku build as well, though.
> Renaming the drivers is OK. It's of no concern to me: just make sure 
> they can easily be identified indeed ;-)
> Please keep the packages working as well (modify if needed)...

Okay, I will.

> No need to restrict that to Haiku Build I think BTW (?)

Well, the question is if you want to update your installation scripts 
to remove the old drivers ;-)


Other related posts: