A Modest Proposal (was [Beowulf] openMosix ending)

[Chris Samuel]

On Wed, 18 Jul 2007, Robert G. Brown wrote:

> No, you misunderstand.

No, I just have a different point of view. :-)

> At this point in time, one major job of an operating system is to hide the
> details of the hardware from the programmer.

Correct - you should not need to know whether the path to a file you are 
opening is on PATA, SATA, iSCSI, NFS or a RAM drive.   However, the kernel 
should know that because it want/need to do things differently depending on 
the underlying characteristics of that device (e.g. wear levelling 
filesystems on flash storage devices or disabling write caches on drives).

> When I open a socket connection or configure TCP-IP, I do so with tools that
> do not need to know WHICH ethernet card my system has or its speed or
> whether it has onboard buffers or who made it.  All I do is configure and
> open the socket for the "generic" network device. 

Correct - but neither do you really want the network device to provide a 
general TCP/IP service to the kernel and prevent you from (say) implementing 
new TCP congestion control algorithms or being prevented from fixing the 
inevitable bugs in their implementation.

See Van Jacobsens excellent presentation from Linux.Conf.Au 2006 on how 
modifying the Linux TCP stack resulted in a stack that was only limited by 
the memory bandwidth of the RAM of the system, not CPU, for instance [1].

[...]
> This is actually remarkably silly -- there is no reason I can think of that
> that a hardware device driver should not present a uniform interface to the
> kernel, and of course many now do -- USB devices, ATAPI, SCSI -- all of
> these are high level interfaces and use generic kernel drivers (which don't
> always work,  sigh, but in PRINCIPLE there exists a STANDARD and most e.g.
> CD-ROM manufacturers comply with the standard because if they don't people
> won't buy their devices and besides, they are more expensive for THEM to
> support.

The kernel developers are forever having to work around broken firmware and 
implementation of standards, for instance the current pain with USB_SUSPEND 
where many devices break badly and the USB subsystem people are now having to 
make an ever growing list of devices to add to their "quirks" list to stop 
them suspending to keep them functioning properly.

We have one person on our local Linux list who uses a Braille USB device - 
which doesn't support USB suspend properly.   Fortunately the maintainer of 
the Braille TTY software he uses has now added a work around to automatically 
disable autosuspend via a /sys method that appeared in 2.6.21, but if he were 
using Ubuntu Feisty (2.6.20 based) he'd be stuffed!

There are some cases where I'm OK with functionality being subsumed into 
firmware, such as Intel's recent decision to move the regulatory compliance 
part of their wireless drivers into firmware.

Ideally that wouldn't be necessary, but sadly we don't live in an ideal world.

cheers,
Chris

[1] - VJ made a nice comment that he would fail any student of his who used a 
doubly-linked list because of the locking penalties you take.. :-)

-- 
Christopher Samuel - (03) 9925 4751 - Systems Manager
 The Victorian Partnership for Advanced Computing
 P.O. Box 201, Carlton South, VIC 3053, Australia
VPAC is a not-for-profit Registered Research Agency
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20070718/0db8df76/attachment.sig>