A Modest Proposal (was [Beowulf] openMosix ending)
csamuel at vpac.org
Tue Jul 17 19:21:44 PDT 2007
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 .
> 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
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.
 - 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: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.scyld.com/pipermail/beowulf/attachments/20070718/0db8df76/attachment.bin
More information about the Beowulf