Re: Re: pci-skeleton duplex check

Re: Re: pci-skeleton duplex check

[arun4linux]

<<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.


[[HTML alternate version deleted]]

Re: Re: pci-skeleton duplex check

[arun4linux]

<<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.

Re: Re: pci-skeleton duplex check

[Russell King]

On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> Interfaces should NEVER change in patch level versions.
> Just *DO NOT DO IT*.
> I do agree on this.

Rubbish.

Think about what you've just said.  Patch level version changes are
things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.

You are saying that we shouldn't change any interfaces between (eg)
2.5.43 and 2.5.44, but we should change every interface we want to
change between 2.4.15 and 2.5.0.

This is obviously completely bogus.  2.5 is a _development_ tree.
Everyone should expect anything, including interfaces to change
between each development patch level.

> This is a common complaint about linux kernel developers. And this always
> gives an insecure feeling  :-) for the device driver or kernel module
> programmers. 

If interfaces are changed without extremely good reason between two
_stable_ patch level versions, that would be a bug.

> This was one of the issues in my earlier company/work and they have
> gone for another OS.

Was the problem against a stable kernel version?  Did you report the
problem when you found it?  Was there a response?

Unless you have done at least the above, I, for one, have very little
sympathy.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Re: pci-skeleton duplex check

[Mr. James W. Laferriere]

On Sat, 14 Dec 2002, Russell King wrote:
...
> Rubbish.
>
> Think about what you've just said.  Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
	Put very simply yes .  x.odd-number.y IS for DEVELOPEMENT ,
	x.even-number.y IS for Stability .
	If people can not understand that I feel sorry for them .
		JimL
-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Re: pci-skeleton duplex check

[Steffen Persvold]

On Sat, 14 Dec 2002, Russell King wrote:

> On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> > Interfaces should NEVER change in patch level versions.
> > Just *DO NOT DO IT*.
> > I do agree on this.
> 
> Rubbish.
> 
> Think about what you've just said.  Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
> 
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
> 
> This is obviously completely bogus.  2.5 is a _development_ tree.
> Everyone should expect anything, including interfaces to change
> between each development patch level.
> 
> > This is a common complaint about linux kernel developers. And this always
> > gives an insecure feeling  :-) for the device driver or kernel module
> > programmers. 
> 
> If interfaces are changed without extremely good reason between two
> _stable_ patch level versions, that would be a bug.
>

There have been a few during 2.4... The alloc_kiovec stuff for instance 
and zap_page_range. 2.2 was much more stable.

Interface changes in development series is (or atleast should be to 
everyone using linux) a known "feature".

Regards,
-- 
  Steffen Persvold   |       Scali AS      
 mailto:sp@scali.com |  http://www.scali.com
Tel: (+47) 2262 8950 |   Olaf Helsets vei 6
Fax: (+47) 2262 8951 |   N0621 Oslo, NORWAY

Re: Re: pci-skeleton duplex check

[Aravind Ceyardass]

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