Re: [forum] Some perspective from the cheap seats...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Mike A. Harris" <mharris@www.linux.org.uk> wrote:

> >Which brings me to the point about committer access. IMHO the XFree86 BOD 
> >and Core Team have nightmares about driver bugs due to this exact reason. 
> >Someone needs to police changes made to device driver code to ensure 
> >things are *working*, when they are comitted to the XFree86 code tree. 
> >Keeping the list closed helps to maintain a reasonable amount of quality, 
> >but it means things move *very* slowly. 
> 
> Restricting access to CVS doesn't guarantee the drivers are
> working or that any of them have even been tested with any test
> suite.  The "cyrix" driver was quite broken for a couple of 
> releases for example.

Actually my comment above probably didn't read the way I intended. What I 
was trying to say is that the current mechanism employed by the XFree86 
core team is one way to try and minimise the impact of driver bugs. But 
as you point out, this assumes that the committers have some way to 
verify that the code actually does work. About all they can really do is 
verify that it compiles, since I doubt the committers would have access 
to the breadth of hardware necessary to do real conformance testing when 
they commit patches (and hence the reason I said people probably have 
nightmares about stuff breaking and are reluctant to include patches!).

> >If XFree86 does open up access to more committers (regardless of
> >whether it is fully open or just signing up 10-20 more active
> >committers), something needs to be done to ensure that people
> >committing the code changes can verify things are correct.
> 
> I hope you're not implying that the core team does that right now
> for every checkin, as I rather doubt that that is the case.

No, I was not implying that as I seriously doubt committers have access 
to the hardware necessary to do this ;-)

> >More importantly those tools should be available to the
> >developers actually working on the drivers, so they can ensure
> >their work is correct before sending it to the committer.
> 
> That is a rather difficult proposition actually.  Neither the 
> core team, nor any other developer out there is likely to have 
> _all_ of the hardware that a given driver supports.  I doubt that 
> any developer would be willing to make a driver change, and then 
> test the driver in all resolutions and color depths on every 
> piece of hardware that the driver supports even if they _did_ 
> have all of that hardware.  It is just too time consuming and 
> non-practical, in particular considering it is generally 
> volunteer effort.

Yep. You hit the nail on the head with that one. We have solved that 
particular problem very cleanly with our SciTech SNAP Graphics product, 
but I have beaten that horse to death before on the XFree86 list and 
Linux kernel list, and I don't plan to beat it again ;-)

> What needs to be done, is for driver developers and contributors
> to test their modifications on as much hardware as possible, and
> for frequent "test drivers" to be made publically available so
> that the swarms of users out there can test them on a much wider
> variety of hardware.  Without "release early, release often" beta
> testing, what we get is 12 month releases with many after the fact
> bugs reported by users, many of which wait another 12 months
> before an official fix is incorporated into a stable release. 

Yes, that I would agree with. Unless you have formalised testing and 
release prodedures in place for binary driver modules, the above is about 
the best you can do to ensure correct drivers (and it has worked 
reasonably well for the Linux kernel).

> IMHO, if the drivers are separated from the core server releases,
> the drivers can be updated much more frequently, both with in
> between beta tests of which each driver can be developed on it's
> own time schedule, and the final drivers will get more testing and
> usage on shorter time schedules also, al while the core server
> development progresses on it's own cycle. 

Yes. The driver DDK and source code should be completely separate, build 
separately and be testable separately. That would allow developers to 
work on the drivers independantly of core XFree86 releases, and drivers 
could be released on a different schedule to core XFree86 releases. Then 
it would not matter if there is 6 to 12 months between 4.3 and 4.4, so 
long as frequent driver updates are available during that period of time.

Of course this presents a *huge* number of logistical problems that need 
to be solved, such as who tests the drivers with each version of XFree86, 
who maintains the 'master list' of drivers that distros can distribute 
etc etc. But those problems are solveable.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



[Index of Archives]     [X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite Questions]     [MIPS Linux]     [ARM Linux]     [ARM Linux Kernel]     [Samba]     [Linux RAID]

  Powered by Linux