On Tue, May 17, 2016 at 08:09:27AM -0700, K. Macy wrote: > > What I don't really like is the old approach of trying to abstract away > > differences between Linux and *BSD in drmP.h with some screaming macros. > > Given the imbalance of manpower between Linux and *BSD I think the best > > (and probably only really) approach is to have linux compat types and > > wrapper functions for everything. Which seems to be the new plan. > > Correct. > > > If there's stuff needed above&beyond that I think we need to look at in on > > a case-by-case basis and figure out what makes sense. For me the crucial > > bit isn't so much whether we need to make changes in upstream linux or > > not, but whether there's a benefit for usptream too. If bug reports and > > bugfixes flow back to linux, then I'm all for it. If it's a one-way street > > then frankly I don't care ;-) > > I apologize for a being a bit slow to parse your statements. What is > upstream and what is downstream? If upstream is Linux and downstream > Linux users then I actually do have some areas I'd like engage on like > figuring out if userptr as it stands couldn't provide a better failure > mode. However, I'd like to think that upstream is Intel and downstream > is Intel customers and that the predominant focus on Linux is an > artifact of cost / benefit. If the latter is the case then any changes > that don't interfere with your primary focus but still support your > broader customer base should be considered desirable. > > Either way, now that we're in sync with upstream I do hope that we can > contribute to general driver discussions to the extent that our > limited resources permit. I meant downstream/upstream wrt *BSD ports, i.e. upstream = the i915 linux driver downstream = your port in *BSD If you think of the Intel/customer relation, everything we do here in the community is pretty much just best effort, done by developers and maintainers because it's the right thing to do. I think intel as a company doesn't care one bit about *BSD from a business perspective at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
