Linked by Nth_Man on Mon 1st Jul 2013 15:37 UTC
Linux "This release adds support for bcache, which allows to use SSD devices to cache data from other block devices; a Btrfs format improvement that makes the tree dedicated to store extent information 30-35% smaller; support for XFS metadata checksums and self-describing metadata, timer free multitasking for applications running alone in a CPU, SysV IPC and rwlock scalability improvements, the TCP Tail loss probe algorithm that reduces tail latency of short transactions, KVM virtualization support in the MIPS architecture, many new drivers and small improvements."
Thread beginning with comment 566336
To view parent comment, click here.
To read all comments associated with this story, please click here.
lemur2
Member since:
2007-02-17

There is no guarantee that their driver will be fully featured or continue to be so once they release ownership of the code base.


If they don't write the driver, but merely give specifications to the Linux Driver Project (under an NDA if they wish), then they don't ever "release ownership of the code base", because it isn't their codebase. The code belongs to its authors, who in this case would be the Linux Driver Project. In the case of the Radeon graphics driver for Linux, some of the code is AMD/ATI code but some of it is Xorg code. Xorg maintain the codebase.

The Linux Driver Project would of course be as keen as mustard to write as "fully featured" code as is possible according to the specifications they receive. Manufacturers who want their devices to have a decent "fully featured" Linux driver, with no effort on their part, will of course be as keen as mustard to give the Linux driver developers all the specification details they need. As far as "continue to be so" goes, once the code is written it is written. As long as the device specifications don't change it would be insanity to remove functionality from the already-written driver.

None of what you say addresses these concerns. The reasons for having a Stable API/ABI are far more complicated (and some of these are human factors) than you are willing to admit or realise.


I concur about a stable API, that unarguably is a good thing. With a stable API, one has no need to keep amending the source code.

Freedom software has no need for a stable ABI, however. With freedom software, one continuously re-compiles it and re-releases it with every new version of any code it links with anyway.

Edited 2013-07-05 10:20 UTC

Reply Parent Score: 2

lucas_maximus Member since:
2009-08-18

Freedom software has no need for a stable ABI, however. With freedom software, one continuously re-compiles it and re-releases it with every new version of any code it links with anyway.


Which is a fucking stupid way of managing dependencies. If you think this is a good idea you are quite frankly a moron.

Every tiny change in a software project can cause a bug, and constantly changing little things is a good way to cause breakage. This is software engineering basics and it obvious you don't understand it.

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

Which is a f--king stupid way of managing dependencies.


Excuse me? It is the way that all software development works. Take a look at a makefile.

Every tiny change in a software project can cause a bug, and constantly changing little things is a good way to cause breakage. This is software engineering basics and it obvious you don't understand it.


You clearly don't understand the difference between an API and an ABI. The Linux kernel typically maintains stable APIs but not ABIs. This means that the source code of drivers need not change, but binary entry points do, so the binaries of the drivers does need to change.

If you update the kernel, the source code of drivers typically does not change (because as I said the API is normally stable). Hence this is not a mechanism to introduce breakage. A driver module which has been compiled against the incorrect version of Linux kernel headers simply won't load.

Edited 2013-07-05 12:29 UTC

Reply Parent Score: 2