Re: Re: pci-skeleton duplex check

<<Interfaces should NEVER change in patch level versions.
Just *DO NOT DO IT*.
>>I do agree on this.


This is a common complaint about linux kernel developers. And this always gives an insecure feeling  :-) for the device driver or kernel module programmers. 
This was one of the issues in my earlier company/work and they have gone for another OS.


Warm Regards


Arun
"Michael Richardson" wrote:



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Donald" == Donald Becker writes:
Donald> The drivers in the kernel are now heavily modified and have significantly
Donald> diverged from my version. Sure, you are fine with having someone else
Donald> do the difficult and unrewarding debugging and maintainence work, while
Donald> you work on just the latest cool hardware, change the interfaces and are
Donald> concerned only with the current kernel version.

I agree strongly with Donald.

Interfaces should NEVER change in patch level versions.
Just *DO NOT DO IT*.

Go wild in odd-numbered.. get the interfaces right there.
But leave them alone afterward.

This is a fundamental tenant of being professional. Otherwise, the kernel
people are the biggest reason I've ever seen for using *BSD.
Microsoft is not the real enemy. Gratuitous change is.

] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [




Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com

 Buy the best in Movies at http://www.videos.indiatimes.com

Change the way you talk. Indiatimes presents Valufon, Your PC to Phone service with clear voice at rates far less than the normal ISD rates. Go to http://www.valufon.indiatimes.com. Choose your plan. BUY NOW.

Hi,

A good scheme for numbering kernels or software components in general is
as follows

For stable releases. (x.even.y=major.minor.patch)

increment patch for any bug fixes.
increment minor for any enhancements or new interfaces.
increment major for interface changes or interface deletions.(dangerous
or poor design)

We should increment major even if interface remains same but behaviour
has changed.(again may be poor design)

For development releases we can't follow the above scheme, because the
interfaces are in a flux and we may end up
in version 589.201.700 from 2.4.20. So, we decide to increment patch
number for all changes and deletions.

Hope it helps!

Regards

Aravind


-- 
http://fastmail.fm - IMAP accessible web-mail