On Wed, 2008-08-27 at 13:35 +1000, Dave Airlie wrote:
> On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <rnoland@...> wrote:
> > On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
> >> Okay I've put some thoughts up at:
> >> http://dri.freedesktop.org/wiki/DRMProcess
> >> and I've pasted it in below this for discussion.
> >> some other points:
> >> a) People are pushing for a process change, we will have something
> >> change, however this isn't a who shouts loudest competition, so more
> >> than likely you'll end up compromising, deal with the fact that
> >> nirvana for you may be hell for others.
> >> b) BSD developers do exist now, giving out that they didn't exist in
> >> the past or aren't adding features is pointless. Would you seriously
> >> start developing features before
> >> getting the code caught up?. So live with the fact that we should help
> >> the BSD guys *if* its practical. So we shouldn't do anything major
> >> that alienates their further development.
> >> (personally I care little for BSD, the license or the OSes, however
> >> I'm attempting to be some way fair).
> > We all have our religions. ;) This is the most fair of any of the
> > proposals I've seen or heard. I am certainly willing to compromise, but
> > even this proposal converts the project from what has historically been
> > a collaborative effort (yes, I know)
> tbh it wasn't really a collaborative effort ever, apart from anholt,
> the BSD sharing stems from the days of the r100/r200 Weather channel
> stuff, they wanted to run it all on FreeBSD at the time if memory
> > tolerates renting a subdirectory in the repo to BSD. I'm honestly about
> > ready to throw in the towel. While I have been slowly raising awareness
> > in FreeBSD circles with my frequent pleas for help, I just don't have
> > enough voices to influence the outcome. I have been getting some
> > attention from far more qualified developers than myself lately, but no
> > commitments for substantial work have yet been made. I already know
> > better than to commit infrastructure changes that impact linux, even if
> > they fix obvious bugs. The linux side of the house is not held to the
> The thing is you can't expect equality, its just not possible, there
> are about 10-15 Linux developers,
> and 1 Free and 1 Open BSD developer working on DRM stuff at any one
> time, so you cannot expect the Linux developers
> to know what the BSD requirements are.
I don't expect equality, all I've ever asked for is a little
consideration. 99% of the driver code is shared, at least for drivers
that have ever worked on BSD. We share none, or almost none of the
drm_* code. But for most all of the drivers, the only thing that
currently isn't shared is xxx_drv.c, and that primarily only holds the
probe and attach bits. I don't expect the linux developers to know the
BSD kernel, what I would ask, is that if your committing something to
shared code, please don't use linux specific code when a reasonable
alternative exists. If we rearrange the tree, such that it matches a
linux kernel tree, with all the real files in that structure the entire
concept of shared code will vanish. I anticipate that it will pretty
rapidly degenerate to the point where much of the code is unuseable, at
least for drivers that are actually getting worked on. I'm fine with
fixing the occasional issue, but if it becomes gratuitous, it's just
painful. As long as the shared-code directory exists, you at least have
to git add shared-core/blah.c.
I hope to have more help as time goes on, but right now, it comes back
to a point you made on irc yesterday. linux has far more available
resources than bsd for the time being and taxing what little resources I
have even further, isn't helpful.
> If you do checkin a major
> feature that is BSD only, I'd be quite happy for it
> to break the Linux build until I got around to fixing it. The thing is
> we end up with a tree where you symlink from a different place.
> If we can setup some tinderboxes, I'd be happy to hold up patches on
> minor BSD breakages, however things like GEM etc I can't see
> the point of holding up until BSD catches up. At the moment there is
> no way for a Linux developer to know they have broken the BSD
I hope that I can get to that point someday, as I can rally more
developers to help out. I've only been in the picture here for about a
year and a half now and I wish that I could say that this is my day job,
but it isn't... I'm just trying to do damage control as best I can, with
the occasional clean-up and feature matching. I don't expect for a
feature like GEM to be held up while I develop all of the backend code,
I'd just like the opportunity to try and keep the build from being
broken for extended periods. How many commits have I logged, where the
commit message is "fix build on FreeBSD". Granted, most of the time
they aren't a big deal and a day or two is usually more than adequate
for me to be able to do damage control.
I do however think that it reasonable to expect a linux developer to
know that they are using a linux specific feature when they do it. Just
like I know that I can't use bus_dmamap in shared code. C'mon you know
generally what is and isn't portable.
I know that I'm the minority, but how would you feel if the tables were
turned and I wanted to move everything into a BSD tree and use all BSD
syntax and style.
> > same standards obviously. Jesse and I, have a reasonably good track
> > record of collaborating early enough that we have been able to commit
> > working code at very near the same time. I am having a really difficult
> > time seeing what benefit I get from continuing to work in drm.git with
> > this proposed model. While all commits to master going through the
> > mailing list, I don't anticipate that I have any veto power or even
> > delay powers until I can at least prevent imports from breaking BSD.
> > Then once I do get it squared away, I'm still left having to send those
> > to the ML and wait for approval to push the fixes. I can just save
> > myself that part of the hassle and work privately. If I'm going to have
> > to hand edit and merge every change, I don't see how it is really any
> > harder to do that in my own repo, where I'm only subject to FreeBSD
> > rules. That way, if I need to make a change to infrastructure to fix
> > issues, all I have to worry about is maintaining ABI/API compatability.
> > We all want nice pretty pristine code in our kernels and if I can't
> > easily import the shared code it just isn't worth it. I can get testing
> > on our -CURRENT branch, at least for things that aren't inherently
> > sketchy. I'm probably more likely to attract other developers attention
> > if I'm working in our tree anyway.
> You could also have a bsd-master branch that you regularly pull from the master,
> and send the fixes back to the list, You can point your testers at that tree.
> but I'm not seeing a major difference between shared-core symlinks and
> drivers/gpu/drm/ symlinks,
> even removing a lot of the macros won't make life any harder, they
> will just have different names. So at
> no point have I mentioned you won't be able to re-use the shared files.
I realize that and I think you have always been pretty reasonable about
not intentionally brain-damaging shared code. I don't like the macro
renaming primarily from the perspective that it makes it very difficult
to identify what is a macro vs a native command, as well as the fact
that at least in some cases, we have features that are compatible, but
require different arguments. Whichever one of us doesn't need the extra
arguments just throws them away. So, I don't like the macro renaming,
but it isn't a deal breaker, at least not as long as we can continue to
be halfway reasonable about it.
The biggest problem with this really is that there will be no concept of
shared code anymore... It will just be a free-for-all and I will have to
try and pick up the pieces. The excuse I will get is "Oh, didn't
realize that was shared code, sorry".
> However I am sure that we will see more of a push towards using Linux
> constructs in dri drivers, things like
> idr, list.h, locking constructs are too much of a pain to reinvent for
> every driver..
Honestly, I don't think our locking constructs are that different
anymore... We both use mutex all over the place and often times it's
just a difference of mutex_lock() vs mtx_lock(). idr, is a bit more
problematic. Many cases are fine and we can deal with it with a macro,
but some cases using a linux specific feature when a perfectly
reasonable portable solution will suffice is just not polite. I guess
in the end it is mostly up to each specific vendor/driver developer
whether they choose to be friendly to / value BSD users. If they don't
want to put out the effort to write reasonably portable code, then maybe
I have time to make it work, or maybe not.
Infrastucture bits are rarely the issue, like I said we share don't
share any of drm_*. It's the drivers that I'm concerned about.
> It may be that sharing the code is a dumb model, and you are better
> off working on a patch level, just porting each patch to your own
> tree, I'm not sure, shared-core may in fact cause more problems than
> it solves.
Perhaps... Doing things in a semi-portable fashion keeps developers
from having to write multiple drivers for each OS that they care to
support. Sure, it might take slightly more forthought, but you get more
users, which at least for a hardware vendor, I would think is a good
Robert Noland <rnoland@...>