} Subject: Raw-device-war (was Re: Sharing SCSI disks)
> On Tue, 25 Mar 1997, David S. Miller wrote:
> > Since when does pinhead Torvalds completely control what features
> > Linux provides for "everyone" on the planet? He never has and he
> > never will.
>
> Since this raw-device-war is going personal and is going to last
> till someone is dead, I have a proposal.
I would suspect that David was engaging in some tongue-in-cheek
humor. I would doubt that he and our imperious leader are at odds.
At least I hope not.
> Raw-device support could be done as a kernel module and only
> necessary hooks should be made to the kernel itself. Since
> there is a danger that people who don't _really_ need those
> raw devices will try to use them to speed up their applications,
> it should be made difficult to use raw-device and it should
> not be default or automatic behaviour of the kernel.
>
> We don't want MS-DOS syndrome where every application has
> access to raw-devices and do their own hardware drivers.
> Whole idea of Linux is that hardware and raw devices are
> centralized under kernel control to provide certain common
> services to these devices that are buffered and optimized
> to the last byte. (however GGI follows idea presented but
> it is not added to the kernel, that's why we have too diverce
> support for graphics)
> Hooks for the raw-device support should however be under kernel option
> and should default to not to support raw-devices. I think it is not
> wise to add straight raw-device support to kernel, because it is a
> message to application programmers to start using their own buffer-
> routines to optimize their application performance.
I just wanted to comment that this is probably the most intelligent
position that I have heard on this debate. In the 'for what its
worth' department I would encourage this to be the quasi-official
position for dealing with this issue.
As I have watched the raw-device debate I have become somewhat
concerned about the Linux movement adopting a utopian attitude toward
certain issues. My commentary is of course tempered by my somewhat
long history of working and advocating Linux for commercial
environments.
I believe that at no other time has the door of opportunity swung as
wide as it currently is for the commercial use and adoption of Linux.
To continue the momentum we must advocate positions that indicate to
the consumerms, ie business types, that we understand market pressures
and commercial reality. Part of this understanding will revolve
around making practical decisions in our development efforts.
The future of corporate computing (IMHO) will be firmly centered
around corporate and enterprise databases. I am continually
vociferous about the important role that Linux can play in this
environment. To play this role it is absolutely essential that Linux
be one of the adopted platforms of database developers.
I am not sure of any single event that could do more to instantiate
the commercial relevance of Linux than an Oracle or Sybase port.
While Linux is rapidly gaining acceptance a port of a major enterprise
database would be important in establishing to corporate types that
our operating system has relevance in the corporate arena.
It would seem from the discussions that have been entertained that the
database developers firmly believe that a raw-device layer is
essential in terms of data integrity and database speed. Since I am
far from an expert in this field I would have to believe that their
opinions are based on extensive history and experience in this field.
I have yet to see a rebuttal from anyone which documents that an OS
based buffer/vm cache solution is superior. Until this occurs we will
have to conclude that a raw-device layer is an essential component of
a strategy to seduce DB developers to Linux.
Worldwide experience with Linux should indicate, however, that the
better mousetrap can always be built. The challenge would appear to
be on the table for the Linux buffer/vm cache experts to demonstrate
that a superior kernel based either exists or can be created.
If this was an easy task one would logically assume that other
well-funded operating system vendors would have succeeded given both
the headstart and monetary resources which they enjoy.
The problem with a kernel based solution would seem to be (IMHO) based
on the wide diversity of demands placed on the VM layer. I am not
well grounded in this area but from watching the conversations it
would seem that things like the madvise system call arise from the
difficulties of developing cacheing systems and algorithms which can
dynamically meet the needs of a wide variety of access types, patterns
and demands. I would bet money in an instant on our kernel developers
but work of this complexity will undoubtedly take time both for
development and testing. This of course doesn't even factor into
consideration changing the firmly entrenched opinions of DB
developers.. :-)
In the meantime most corporations and solftware developers are
fighting with the challenges of developing and meeting schedules on
'INTERNET time'. I am not sure that we as a Linux community have the
leisure of waiting for the 'perfect' solution to develop. I am
confident that if the likes of Linus and Stephen Tweedie do develop
spectacularly heuristic algorithms for vm and buffer management the
solution will sell itself. In the meantime we need to 'get getting'.
The solution of developing a kernel loadable module would seem to be
the optimum strategy at this time. I would firmly advocate that it
not even be included in the kernel sources but made available to those
developers who have a pressing need for such capability. Pressing
need is of course subject to definitional arguements but I am sure
that will all play out.
Hopefully these comments provide some helpful perspective and
insight. Actually they come from some of my material for the Linux
Expo. See everyone there.
> -=- malafoss@cc.hut.fi -=- searching the marvels of universe -=-
Have a pleasant weekend.
Greg
}-- End of excerpt from linux-kernel@vger.rutgers.edu
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102
Phone: 701-281-1686 INTERNET: greg@wind.enjellic.com
------------------------------------------------------------------------------
"So you force loaded a 1.2.13 module into 2.1.21 and it broke. Gee what
a surprise. I bet loading DOS .COM files as modules doesn't work either."
-- Alan Cox