[ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[richardj_moore]

We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI)
see the IBM Linux Technology Centre's web page DProbes link:
http://oss.software.ibm.com/developerworks/opensource/linux

Some folks expressed an interest in this type of facility recently in
discussions concerning making call-backs from the kernel to kernel modules.

Here's the abstract for this facility. With this intend to modularise our
RAS offerings, in particular DProbes, so that they can be applied
dynamically without having to be carried as excess baggage.

Abstract:
Generalised Kernel Hooks Interface (GKHI) is a generalised facility for
placing hooks or exits in arbitrary kernel locations. It enables many
kernel enhancements, which are  otherwise self-contained, to become
loadable kernel modules and retain a substantial degree of independence
from the kernel source. This affords advantages for maintenance and
co-existence with other kernel enhancements. The hook interface allows
multiple kernel modules to register their exits for a given hook, in order
to receive control at that hook location. Multiple hooks may be defined
within the kernel and a singe kernel module may register exits to use
multiple hooks.  When hook exits register they may specify co-existence
criteria. Hooks may be placed in kernel modules as well as the kernel
itself with the proviso that the modules with hooks are loaded before the
gkhi hook interfacing module. A hook exit receives control as if called
from the code in which the hook is located. Parameters may be passed to a
hook exit and may be modified by an exit. For more information down-load
the tarball.

Note: GHKI is in late beta test - we currently do not support SMP, that
will occur soon. We also plan to support dynamic hook definition as little
later on so that kernel modules may dynamically register hooks for other
kernel modules to use.


Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).

http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Michael Rothwell]

Sounds great; unfortunately, the core group has spoken out against a
modular kernel.

Perhaps IBM should get together with SGI, HP and other interested
parties and start an Advanced Linux Kernel Project. Then they can run
off and make their scalable, modular, enterprise kernel and the Linus
Version can always merge back in features from it.

-M

richardj_moore@uk.ibm.com wrote:
> 
> We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI)
> see the IBM Linux Technology Centre's web page DProbes link:
> http://oss.software.ibm.com/developerworks/opensource/linux
> 
> Some folks expressed an interest in this type of facility recently in
> discussions concerning making call-backs from the kernel to kernel modules.
> 
> Here's the abstract for this facility. With this intend to modularise our
> RAS offerings, in particular DProbes, so that they can be applied
> dynamically without having to be carried as excess baggage.
> 
> Abstract:
> Generalised Kernel Hooks Interface (GKHI) is a generalised facility for
> placing hooks or exits in arbitrary kernel locations. It enables many
> kernel enhancements, which are  otherwise self-contained, to become
> loadable kernel modules and retain a substantial degree of independence
> from the kernel source. This affords advantages for maintenance and
> co-existence with other kernel enhancements. The hook interface allows
> multiple kernel modules to register their exits for a given hook, in order
> to receive control at that hook location. Multiple hooks may be defined
> within the kernel and a singe kernel module may register exits to use
> multiple hooks.  When hook exits register they may specify co-existence
> criteria. Hooks may be placed in kernel modules as well as the kernel
> itself with the proviso that the modules with hooks are loaded before the
> gkhi hook interfacing module. A hook exit receives control as if called
> from the code in which the hook is located. Parameters may be passed to a
> hook exit and may be modified by an exit. For more information down-load
> the tarball.
> 
> Note: GHKI is in late beta test - we currently do not support SMP, that
> will occur soon. We also plan to support dynamic hook definition as little
> later on so that kernel modules may dynamically register hooks for other
> kernel modules to use.
> 
> Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).
> 
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Christoph Rohland]

Hi Michael,

On Wed, 08 Nov 2000, Michael Rothwell wrote:
> Sounds great; unfortunately, the core group has spoken out against a
> modular kernel.
> 
> Perhaps IBM should get together with SGI, HP and other interested
> parties and start an Advanced Linux Kernel Project. Then they can
> run off and make their scalable, modular, enterprise kernel and the
> Linus Version can always merge back in features from it.

*Are you crazy?* =:-0 

Proposing proprietary kernel extensions to establish an enterprise
kernel? No thanks!

Greetings
		Christoph

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Larry McVoy]

On Thu, Nov 09, 2000 at 08:44:11AM +0100, Christoph Rohland wrote:
> Hi Michael,
> 
> On Wed, 08 Nov 2000, Michael Rothwell wrote:
> > Sounds great; unfortunately, the core group has spoken out against a
> > modular kernel.
> > 
> > Perhaps IBM should get together with SGI, HP and other interested
> > parties and start an Advanced Linux Kernel Project. Then they can
> > run off and make their scalable, modular, enterprise kernel and the
> > Linus Version can always merge back in features from it.
> 
> *Are you crazy?* =:-0 
> 
> Proposing proprietary kernel extensions to establish an enterprise
> kernel? No thanks!

Actually, I think this idea is a good one.  I'm a big opponent of all the
big iron feature bloat getting into the kernel, and if SGI et al want to
go off and do their own thing, that's fine with me.  As long as Linus 
continues in his current role, I doubt much of anything that the big iron
boys do will really make it back into the generic kernel.  Linus is really
smart about that stuff, are least it seems so to me; he seems to be well
aware that 99.9999% of the hardware in the world isn't big iron and never
will be, so something approximating 99% of the effort should be going towards
the common platforms, not the uncommon ones.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Andre Hedrick]

Second or Third here!!!

TRG plans to create and publish a native RING 0 kernel and packages.
This may end up as a bolt on ./arch or something.
Not everyone in the world needs a SUPERCHARGED, FUEL-INJECTED, ALCOHOL,
FIRE-BREATHING kernel, but some do!

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development


On Wed, 8 Nov 2000, Larry McVoy wrote:

> On Thu, Nov 09, 2000 at 08:44:11AM +0100, Christoph Rohland wrote:
> > Hi Michael,
> > 
> > On Wed, 08 Nov 2000, Michael Rothwell wrote:
> > > Sounds great; unfortunately, the core group has spoken out against a
> > > modular kernel.
> > > 
> > > Perhaps IBM should get together with SGI, HP and other interested
> > > parties and start an Advanced Linux Kernel Project. Then they can
> > > run off and make their scalable, modular, enterprise kernel and the
> > > Linus Version can always merge back in features from it.
> > 
> > *Are you crazy?* =:-0 
> > 
> > Proposing proprietary kernel extensions to establish an enterprise
> > kernel? No thanks!
> 
> Actually, I think this idea is a good one.  I'm a big opponent of all the
> big iron feature bloat getting into the kernel, and if SGI et al want to
> go off and do their own thing, that's fine with me.  As long as Linus 
> continues in his current role, I doubt much of anything that the big iron
> boys do will really make it back into the generic kernel.  Linus is really
> smart about that stuff, are least it seems so to me; he seems to be well
> aware that 99.9999% of the hardware in the world isn't big iron and never
> will be, so something approximating 99% of the effort should be going towards
> the common platforms, not the uncommon ones.
> -- 
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Christoph Rohland]

Hi Larry,

On Wed, 8 Nov 2000, Larry McVoy wrote:
> On Thu, Nov 09, 2000 at 08:44:11AM +0100, Christoph Rohland wrote:
>> *Are you crazy?* =:-0 
>> 
>> Proposing proprietary kernel extensions to establish an enterprise
>> kernel? No thanks!
> 
> Actually, I think this idea is a good one.  I'm a big opponent of
> all the big iron feature bloat getting into the kernel, and if SGI
> et al want to go off and do their own thing, that's fine with me.
> As long as Linus continues in his current role, I doubt much of
> anything that the big iron boys do will really make it back into the
> generic kernel.  Linus is really smart about that stuff, are least
> it seems so to me; he seems to be well aware that 99.9999% of the
> hardware in the world isn't big iron and never will be, so something
> approximating 99% of the effort should be going towards the common
> platforms, not the uncommon ones.

If we would not allow binary only modules I would not have such a big
problem with that...

I understand that the one size fits all approach has some limitations
if you want to run on PDAs up to big iron. But a framework to overload
core kernel functions with modules smells a lot of binary only, closed
source, vendor specific Linux on high end machines. 

And then I don't see the value of Linux anymore.

Greetings
		Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Michael Rothwell]

Christoph Rohland wrote:
> If we would not allow binary only modules I would not have such a big
> problem with that...

I'm not sure how you would do that.
 
> I understand that the one size fits all approach has some limitations
> if you want to run on PDAs up to big iron. But a framework to overload
> core kernel functions with modules smells a lot of binary only, closed
> source, vendor specific Linux on high end machines.

Since Linux is GPL, how would you stop this?
 
> And then I don't see the value of Linux anymore.

Same as before -- freedom and low cost. The primary advantae of Linux
over other OSes is the GPL. 

I think and Advanced Linux Kernel PRoject would be a good idea for a
number of reasons. It would give "Enterprise" users their own special
kernel, just like the microcontroller and real-time guys have. It would
also provide a parallel development track for Linux that could provide
real competition and value to the Linus-version kernel. The "Enterprise"
machines that IBM, HP and SGI would target aren't all S/390s; there
would be significant overlap of their low end with Linus' high end, I
think. Like 8+-way SMP servers.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Lars Marowsky-Bree]

On 2000-11-09T07:20:27,
   Michael Rothwell <rothwell@holly-springs.nc.us> said:

> > I understand that the one size fits all approach has some limitations
> > if you want to run on PDAs up to big iron. But a framework to overload
> > core kernel functions with modules smells a lot of binary only, closed
> > source, vendor specific Linux on high end machines.
> 
> Since Linux is GPL, how would you stop this?

Christoph / SAP is in a rather good position to stop that being supported by
vendors...

> Same as before -- freedom and low cost. The primary advantae of Linux
> over other OSes is the GPL. 

And that is why that has to govern the kernel and its modules as far as
possible.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>
    Development HA

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Alexander Viro]

On Thu, 9 Nov 2000, Michael Rothwell wrote:

> Same as before -- freedom and low cost. The primary advantae of Linux
> over other OSes is the GPL. 

Now, that's more than slightly insulting...

The problem with the hooks et.al. is very simple - they promote every
bloody implementation detail to exposed API. Sorry, but... See Figure 1.
It won't fly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Tigran Aivazian]

On Wed, 8 Nov 2000, Larry McVoy wrote:
> As long as Linus continues in his current role, I doubt much of
> anything that the big iron boys do will really make it back into the
> generic kernel.

That is great, thank you. At least I know now someone on this planet who
agrees with me! Everyone (regardless of whether he has seen commercial
UNIX source or not, but it pains most to hear from those who have) seems
to be sceptical when I say exactly the above. They think "how could that
possibly be -- the "big iron Unixen" had such a large investment of real
money to make them full of "enterprise-features", surely there must be
something useful for Linux to learn from". To which I reply -- "most
(probably 99-100%) Linux kernel hackers have access to the source code of
most (probably 40%-90% depending on their lack) flavours of commercial
UNIX and would be quite happy to "steal" code from it (as long as they,
like myself agree with RMS philosophy/morals) but the reality is -- there
is _nothing_ to steal from it". Commercial UNIXen are just useless -- we
_have_ to rewrite everything from scratch, not because we can't steal (or
think it immoral) but because there is nothing interesting to steal left.
The free stuff is actually better and technically superior to that which
is not free.

To contradict to myself (just a tiny bit!) I think it would still be
useful for the public in general (by "public in general" I meant those
clueless individuals who write the laws men have to obey) to recognize the
above fact and let the hackers be no longer shy about it, i.e. be able to
freely discuss any information they have (or had) access to, so that, in
the unlikely case that there is something useful to "steal" from it, they
can take it freely and put it into Linux.

Regards,
Tigran

PS. The very fact I can say the above and still (hope to) have a job
afterwards is a sign of much progress towards the better end :)

PPS. Better is the end of a thing than the beginning thereof: and the
patient in spirit is better than the proud in spirit. (Eccl 7:8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Michael Rothwell]

Alexander Viro wrote:
> 
> On Thu, 9 Nov 2000, Michael Rothwell wrote:
> 
> > Same as before -- freedom and low cost. The primary advantae of Linux
> > over other OSes is the GPL.
> 
> Now, that's more than slightly insulting...

Well, it wasn't meant to be. I imagine RMS would make the same type of
statement -- Linux is libre, therefore superior. There's a number of
OSes that have advantages of Linux in some area; Solaris can use more
processors; QNX is real-time, smaller and still posix; Windows has
better application support (i.e., more of them); MacOS has better color
and font management. But, Linux is free. Let's say for a moment that
Linux was exactly the same as Solaris, technically. Linux would be
superior because it is licensed under the GPL, and is free; whereas
Solaris would not be.

> The problem with the hooks et.al. is very simple - they promote every
> bloody implementation detail to exposed API. Sorry, but... See Figure 1.
> It won't fly.

Figure 1?

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Alexander Viro]

On Thu, 9 Nov 2000, Michael Rothwell wrote:

> Alexander Viro wrote:
> > 
> > On Thu, 9 Nov 2000, Michael Rothwell wrote:
> > 
> > > Same as before -- freedom and low cost. The primary advantae of Linux
> > > over other OSes is the GPL.
> > 
> > Now, that's more than slightly insulting...
> 
> Well, it wasn't meant to be. I imagine RMS would make the same type of
> statement -- Linux is libre, therefore superior. There's a number of

<shrug> RMS had repeatedly demonstrated what he's worth as a designer
and programmer. Way below zero. You may like or dislike his ideology,
but when it comes to technical stuff... Not funny.

> OSes that have advantages of Linux in some area; Solaris can use more
> processors; QNX is real-time, smaller and still posix; Windows has
> better application support (i.e., more of them); MacOS has better color
> and font management. But, Linux is free. Let's say for a moment that
> Linux was exactly the same as Solaris, technically. Linux would be

You mean, bloated tasteless parody on UNIX? Thanks, but no thanks.

> superior because it is licensed under the GPL, and is free; whereas
> Solaris would not be.

Small solace it would be.

> > The problem with the hooks et.al. is very simple - they promote every
> > bloody implementation detail to exposed API. Sorry, but... See Figure 1.
> > It won't fly.
> 
> Figure 1?

Use search engine. On google "See Figure 1" brings the thing in the first
5 hits.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Michael Rothwell]

Alexander Viro wrote:

> > Figure 1?
> 
> Use search engine. On google "See Figure 1" brings the thing in the first
> 5 hits.

http://www.google.com/search?q=See+Figure+1&btnG=Google+Search
->
http://spiffy.cso.uiuc.edu/~kline/Stuff/see-figure-1.html
->
http://spiffy.cso.uiuc.edu/~kline/Stuff/f-you.gif

...

http://www.google.com/search?q=See+Figure+1&btnG=Google+Search
->
http://www.physics.ohio-state.edu/~bcd/humor/figure1.html

... How utterly typical of you, Viro. 

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Marco Colombo]

On Thu, 9 Nov 2000, Michael Rothwell wrote:

> Alexander Viro wrote:
> > 
> > On Thu, 9 Nov 2000, Michael Rothwell wrote:
> > 
> > > Same as before -- freedom and low cost. The primary advantae of Linux
> > > over other OSes is the GPL.
> > 
> > Now, that's more than slightly insulting...
> 
> Well, it wasn't meant to be. I imagine RMS would make the same type of
> statement -- Linux is libre, therefore superior. There's a number of
> OSes that have advantages of Linux in some area; Solaris can use more
> processors; QNX is real-time, smaller and still posix; Windows has
> better application support (i.e., more of them); MacOS has better color
> and font management. But, Linux is free. Let's say for a moment that
> Linux was exactly the same as Solaris, technically. Linux would be
> superior because it is licensed under the GPL, and is free; whereas
> Solaris would not be.

<lurker off>
Sorry, I couldn't resist.

1) "Solaris running on more processors"? Think of Beowulf clusters.
   Strangely enough, people running them choose Linux as the kernel.
2) "QNX is real-time", true. Linux is not. Please don't compare apples with
   oranges.
3) "Windows has more apps"? True. Is it a kernel property of any kind? No.
4) "MacOS has better color and font management" this is funny as it speaks
   for itself. I'd also add "MacOS is usually housed in a better-looking
   case". Luckily enough, under Linux color and font management is NOT a
   kernel job. No more than the external design of the case, I mean.

And I really hope Linux will *never* be exactly the same as Solaris,
technically.
</lurker on>

> > The problem with the hooks et.al. is very simple - they promote every
> > bloody implementation detail to exposed API. Sorry, but... See Figure 1.
> > It won't fly.
> 
> Figure 1?

>From "The design and implementation of the Perfect OS 1.0", yet to be
published. The good thing about this book is that there will never be
a second edition. Of course the only release of Perfect OS will be 1.0!
B-) B-) B-) B-)

> 
> -M
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Theodore Y. Ts'o]

   Date: 	Wed, 08 Nov 2000 16:35:33 -0500
   From: Michael Rothwell <rothwell@holly-springs.nc.us>

   Sounds great; unfortunately, the core group has spoken out against a
   modular kernel.

This is true; that's because a modular kernel means that interfaces have
to be frozen in time, usually forever.  This makes a lot of improvements
impossible, and over time there is more and more crud added to simply
act as "impedance matching" between incompatible/legacy interfaces.

However, that doesn't mean that the GKHI is *automatically* bad.  It all
depends on how you use it.  Just as with kernel modules, where it's
darned useful for distributions so they don't have to build custom
kernels for each installation (but source is included for all modules),
the GKHI could be used in a similar way. 

The issue will be with what hooks are allowed to be exported via
the GKHI; this defines the interfaces.  Also, it's important to note
which interfaces are and aren't guaranteed to be stable.  If the
interfaces aren't guaranteed to be stable, then incompatibilities and
keeping up with the latest version are a problem for the provider of the
binary module, not of the Linux Kernel Development Community.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Ingo Molnar]

On Wed, 8 Nov 2000, Larry McVoy wrote:

> smart about that stuff, are least it seems so to me; he seems to be
> well aware that 99.9999% of the hardware in the world isn't big iron
> and never will be, so something approximating 99% of the effort should
> be going towards the common platforms, not the uncommon ones.

yep, this is true. Still Linux appears to perform remarkably well on
so-called 'big iron'.

IMO it's a big misconception that 'big iron is different'. Yes, patches
and bad design can make source trees very different. But IMO big iron is
not more different from a normal PIII workstation than a PDA is different.
We doing a bad job if we cannot support them all - or at least we must
always be able to keep clean interfaces so keeping a forked sub-project
for a less known or less understood feature is easy and straightforward.
In fact i believe a PDA is much harder to do right than high-end systems.
Making something faster, given endless resources, is almost always easy.
But maximizing performance on a fundamentally and intentionally limited
platform is much less trivial and takes alot of clout.

in the 2.4 kernel we have all the features that is needed for 'enterprise
scalability', in fact i believe we have some scalability features (eg. big
reader spinlocks) that are not available on other systems.

	Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Mike Coleman]

Alexander Viro <viro@math.psu.edu> writes:
> <shrug> RMS had repeatedly demonstrated what he's worth as a designer
> and programmer. Way below zero. You may like or dislike his ideology,
> but when it comes to technical stuff... Not funny.

Huh?

<annoying valspeak tone>

*Hello*?  GNU gcc?  GNU emacs?  Way below zero?  *Hello*?!?

</annoying valspeak tone>


-- 
[O]ne of the features of the Internet [...] is that small groups of people can
greatly disturb large organizations.  --Charles C. Mann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Alexander Viro]

On 9 Nov 2000, Mike Coleman wrote:

> Alexander Viro <viro@math.psu.edu> writes:
> > <shrug> RMS had repeatedly demonstrated what he's worth as a designer
> > and programmer. Way below zero. You may like or dislike his ideology,
> > but when it comes to technical stuff... Not funny.
> 
> Huh?
> 
> <annoying valspeak tone>
> 
> *Hello*?  GNU gcc?  GNU emacs?  Way below zero?  *Hello*?!?
> 
> </annoying valspeak tone>

Yes. GNU emacs. Bloated and ugly like hell. gcc. Codebase is anything but
pretty. Your point being? And no, it's not trolling. RMS really got no
taste - read his postings on _technical_ GNU lists and see yourself.

Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.

$DEITY witness, we've got enough ugly code, but compared to the average
level of GNU codebase kernel looks wonderful. Sorry. I think that I've
spent enough time dealing with both to be able to compare.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Christoph Rohland]

Hi Ingo,

On Thu, 9 Nov 2000, Ingo Molnar wrote:
> 
> On Wed, 8 Nov 2000, Larry McVoy wrote:
> 
>> smart about that stuff, are least it seems so to me; he seems to be
>> well aware that 99.9999% of the hardware in the world isn't big
>> iron and never will be, so something approximating 99% of the
>> effort should be going towards the common platforms, not the
>> uncommon ones.
> 
> yep, this is true. Still Linux appears to perform remarkably well on
> so-called 'big iron'.

Thanks Ingo, I agree to this and also agree that we should try to be
able to run (mostly) everything from the same code base and I think
that's Linux does a great job on this.

Having a seperated code base for 0.0001% of mission critical servers
will lead to very bad availability or very high development cost at
least. In the worst (and not so unprobable) case it will lead to a lot
of games with licenses and 'intellectual property'. This would mean
that Linux fails to deliver on its promises IMHO.

Greetings
		Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Christoph Rohland]

Hi Michael,

On Thu, 09 Nov 2000, Michael Rothwell wrote:
> Christoph Rohland wrote:
>> And then I don't see the value of Linux anymore.
> 
> Same as before -- freedom and low cost. The primary advantae of
> Linux over other OSes is the GPL.

And you would loose exactly these two points for high end servers.

Greetings
		Christoph

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Martin Dalecki]

Alexander Viro wrote:
> 
> On 9 Nov 2000, Mike Coleman wrote:
> 
> > Alexander Viro <viro@math.psu.edu> writes:
> > > <shrug> RMS had repeatedly demonstrated what he's worth as a designer
> > > and programmer. Way below zero. You may like or dislike his ideology,
> > > but when it comes to technical stuff... Not funny.
> >
> > Huh?
> >
> > <annoying valspeak tone>
> >
> > *Hello*?  GNU gcc?  GNU emacs?  Way below zero?  *Hello*?!?
> >
> > </annoying valspeak tone>
> 
> Yes. GNU emacs. Bloated and ugly like hell. gcc. Codebase is anything but
> pretty. Your point being? And no, it's not trolling. RMS really got no
> taste - read his postings on _technical_ GNU lists and see yourself.

Actually emacs is complete crap int terms of both ergonomy and coding.
But the current gcc code base doesn't contain much from RMS anylonger. 
The "beauty" of lisp coded in C it is...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Matti Aarnio]

  I have been wondering what all of the furor has been about...

	Initially I thought that it is "a way to load in a module which
	defines its own syscalls, etc.." and/or "we want to sell binary
	images which can activate some hooks" but having just read the
	GKHI README, that thing is far away from its intentions.
	(Well, it doesn't preclude those, but neither it mentions them
	 as objectives.  And giving a license stating use of GNU GPL
	 also doesn't quite fit "proprietary binary hook" image..)

On Wed, Nov 08, 2000 at 04:35:33PM -0500, Michael Rothwell wrote:
> Sounds great; unfortunately, the core group has spoken out against a
> modular kernel.

	Really ?

$ /sbin/lsmod 
Module                  Size  Used by
parport_pc             23184   1 (autoclean)
lp                      5072   0 (autoclean) (unused)
parport                30048   1 (autoclean) [parport_pc lp]
8021q                  10032   2
3c59x                  24304   2 (autoclean)
ipv6                  152816  -1 (autoclean)
autofs                 11536   1 (autoclean)
usb-uhci               23408   0 (autoclean) (unused)
usbcore                49504   1 (autoclean) [usb-uhci]
es1371                 29920   0
ac97_codec              7824   0 [es1371]
soundcore               4336   4 [es1371]

> -M
> 
> richardj_moore@uk.ibm.com wrote:
> > 
> > We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI)
> > see the IBM Linux Technology Centre's web page DProbes link:
> > http://oss.software.ibm.com/developerworks/opensource/linux

... (reordered, cut away..)

> > Here's the abstract for this facility. With this intend to modularise our
> > RAS offerings, in particular DProbes, so that they can be applied
> > dynamically without having to be carried as excess baggage.

	Richard,

	Please educate me, what does "our RAS offerings" mean here ?
	(I didn't find "RAS" at your signature-URL site, but I didn't
	 poke around very much..)

	I do know that when IBM suits speak with phrases like that,
	they are selling me something which costs $$$.

	Which definitely gives proprietary, binary only, hook image...
	But GKHI, and DProbes are neither. Thus I am confused, but can
	understand the furor...

> > Some folks expressed an interest in this type of facility recently in
> > discussions concerning making call-backs from the kernel to kernel modules.

	Indeed,  one such mechanism could be a way to register IOCTL
	call chains, which now (for sockets) are quite ugly.
	Lots and lots of subsystems do ioctl()s via /proc/ objects
	just because other methods are way too messy.

	[ ioctl's go via the protocol family of the control socket to
	  family-specific subset, but then the "fun" begins for things
	  which aren't quite of any specific protocol family -- see
	  DLCI support hooks at  ipv4,  and bridge ioctls at both ipv4
	  and at packet.

	  Grep the kernel source for "_hook", and you see a lot of
	  things..  Mostly varying mouses, and bridging, it seems.
	  Netfilter calls its managed coherent interface "hook", but
	  it is way better. ]

	Also the bridging system is less than desirable looking with
	its pervasive hooks, but that can be solved by making layer2
	devices fully stackable.  (Something for 2.5)



> > Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).
> > http://oss.software.ibm.com/developerworks/opensource/linux
> > Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> > IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

[Michael Rothwell]

Matti Aarnio wrote:
> On Wed, Nov 08, 2000 at 04:35:33PM -0500, Michael Rothwell wrote:
> > Sounds great; unfortunately, the core group has spoken out against a
> > modular kernel.
> 
>         Really ?
> 
> $ /sbin/lsmod
> Module                  Size  Used by
> [...]
> soundcore               4336   4 [es1371]


Really. That the kernal has loadable modules does not mean that it is
modular.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Advanced Linux Kernel/Enterprise Linux Kernel

[Josue Emmanuel Amaro]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

This subject came up in the Generalized Kernel Hooks Interface thread, since it
is an area of interest to me I wanted to continue that conversation.

While I do not think it would be productive to enter a discussion whether there
is a need to fork the kernel to add features that would be beneficial to
mission/business critical applications, I am curious as to what are the features
that people consider important to have.  By mission critical I mean systems that
if not functional bring a business to a halt, while by business critical I mean
systems that affect a division of a business.

Another problem is how people define Enterprise Systems.  Many base it on the
definitions that go back to S390 systems, others in the context of the 24/7
nature of the internet.  That would also be a healthy discussion to have.

At Oracle we are primarily interested on I/O subsystem features and memory
management.  (For anyone that knows anything about Oracle this should not come
as a surprise, although I am pretty sure that any database vendor/developer
would be interested on those features as well.)

Regards,

--
=======================================================================
  Josue Emmanuel Amaro                         Josue.Amaro@oracle.com
  Linux Products Manager
  Intel and Linux Technologies Group
=======================================================================


[-- Attachment #2: Card for Josue Emmanuel Amaro --]
[-- Type: text/x-vcard, Size: 390 bytes --]

begin:vcard 
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:Josue.Amaro@oracle.com
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States
fn:Josue Emmanuel Amaro
end:vcard

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Lars Marowsky-Bree]

On 2000-11-13T13:56:16,
   Josue Emmanuel Amaro <Josue.Amaro@oracle.com> said:

Good morning Josue,

I hope your certification matrix hasn't driven you mad yet ;-)

> While I do not think it would be productive to enter a discussion whether
> there is a need to fork the kernel to add features that would be beneficial
> to mission/business critical applications, I am curious as to what are the
> features that people consider important to have.

This is in fact the valuable subpart of the discussion.

Working for SuSE on High Availability, especially in the "enterprise" segment:
Here, referring to systems running databases (mostly Oracle, surprise),
ERP-Systems, but also providing services (NFS, Samba, firewalls) in such an
environment.

I personally need features which allow me to keep on running, shut down as
gracefully as possible if an error occurs, and if an error occured, diagnose
it out in the field.

This means: ECC memory, hotpluggable everything, proper error handling and
reporting in the kernel. Yes, christmas and easter do occur on the same day in
the real world, unfortunately.

This can best be summarised as "robustness".

If an error occured, I need to be able to fully diagnose it without having to
reproduce it - no, I do not wish to reproduce the error by crashing my
critical server on purpose, nor is "The error appears to have gone away, we
have no clue what it was" an acceptable answer. (kdb, LKCD, Oopsing to the
network etc: And they must be part of the default kernel as far as possible,
so they stay in sync and get widespread testing)

But also scalability: 2TB is a problem for me in some cases, 32bit just don't
cut it all the time - but I need to circumvent the storage problem even on a
32bit system. And adding disks to the system while running is desireable.

Cluster awareness, again mostly referring to storage: Yes, there is more than
one system accessing my SCSI bus, my FCAL RAID, and the error handling should
be architected in a way that they do not start reset wars.

The LVM should safeguard against multiple nodes changing the metadata. (Ok,
this can be solved in userspace too) LVM must be transactional, so a crash on
a node doesn't corrupt the data.

Basically, the talks in Miami (The Second Annual Linux Storage Management
Workshop) gave a great overview of everything I need.

And: I need all of this as Open Source. Period. No binary kernel modules do me
any good and I will pointedly ignore them.

Oh, and by the way - if any hot kernel hacker, not yet working on this full
time feels inspired to make this happen, contact me. Or any other Linux
company, as long as the job gets done. We'll be glad to make you a fulltime
kernel slave^Whacker! ;-)

> Another problem is how people define Enterprise Systems.  Many base it on the
> definitions that go back to S390 systems, others in the context of the 24/7
> nature of the internet.  That would also be a healthy discussion to have.
           _
24/7 * 99.99% mission/business critical services with "medium to high" load.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>
    Development HA

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Jesse Pollard]

Josue Emmanuel Amaro <Josue.Amaro@oracle.com>:
> This subject came up in the Generalized Kernel Hooks Interface thread, since it
> is an area of interest to me I wanted to continue that conversation.
> 
> While I do not think it would be productive to enter a discussion whether there
> is a need to fork the kernel to add features that would be beneficial to
> mission/business critical applications, I am curious as to what are the features
> that people consider important to have.  By mission critical I mean systems that
> if not functional bring a business to a halt, while by business critical I mean
> systems that affect a division of a business.
>
> Another problem is how people define Enterprise Systems.  Many base it on the
> definitions that go back to S390 systems, others in the context of the 24/7
> nature of the internet.  That would also be a healthy discussion to have.
> 
> At Oracle we are primarily interested on I/O subsystem features and memory
> management.  (For anyone that knows anything about Oracle this should not come
> as a surprise, although I am pretty sure that any database vendor/developer
> would be interested on those features as well.)

I reformatted/phrased your questions above to allow for separate answers:

Q1. How do you define Enterprise Systems? Many base it on the definitions that
    go back to S390 systems, others in the context of the 24/7 nature of the
    internet.

1. The system should be available 24 hours a day, 7 days a week, 52 weeks a
   year :-), with time off for scheduled down time for maintenance and
   upgrades.

2. It should be possible to take down a node of a cluster without affecting
   the effectiveness of the other nodes. There is an expeced higher load on
   the remaining nodes during the time the node is missing.
3. It should be possible to add nodes to a cluster without affecting the
   effectiveness of the other nodes.

4. Unauthorized access to, modification to, or damage to the effectiveness of
   the system should be possible (the ideal...). All security related events
   should be audited and logged.

Q2. I am curious as to what are the features that people consider important to
    have.  By mission critical I mean systems that if not functional bring a
    business to a halt, while by business critical I mean systems that affect
    a division of a business.

1. Secure - Multi-level security (with compartmentalization) is needed to
   be able to detect unauthorized attempts to modify the system. There should
   be no all powerfull user. System updates should require three different
   authorizations (security, administrator, and auditor) to take effect when
   the system is on-line. All bets are off, of course, if the system is taken
   offline for such modifications - at that point, the administrator would
   be able to make any changes. The security administrator should validate
   the system in some manner. The system should not be able to be brought
   online without being validated.

   IPSec to provide controled encryption between hosts. Inclusion of CIPSO
   style extensions to allow for labeled network support. Virtical integration
   to include user identification tags as well. I would like to be able to
   identify the remote user, with confidence in that identity established
   by the confidence in the host, which is in turn established by IPSec.

   I (meaning me) would like the ability to audit every system call. (yes,
   this is horrendous, if everything is logged, but I want to be able to
   choose how much is logged at the source of the data, rather than at
   the destination. That would reduce the total data flood to what is
   manageable or desired.

   I realize that this is extreme - but in some environments this degree of
   control is necessary. It should be possible to downgrade this level of
   control to the point that is required for other environments.

2. Allow for full accounting of user resources - memory, cpu, disk, IO.

3. It should not be possible for a user to exceed the resource quotas
   established for the user. This control should be flexible enough to allow
   for exceeding some quotas if additional resources are available, but
   unused. (I'm considering memory resources and CPU time here. The user
   should be able to exceed memory quota, but with the understanding that
   the users processes will be trimmed down to the users quota limit if
   needed for other users.

4. Batch jobs, using a more common definition of batch than that used by
   the "batch" utility - job queues, with batch controled limits, job
   checkpointing/restart, resource allocation controls... Batch jobs
   should be able to migrate to other nodes/systems (as long as all other
   required resources are available ... This is HARD to do :-).

5. Allow for multiple scheduling types, preferably concurrently, but changable
   at runtime. Some real time, mostly batch and interactive.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[David Weinehall]

On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote:
[snip]
> 4. Unauthorized access to, modification to, or damage to the
>    effectiveness of the system should be possible (the ideal...).
>    All security related events should be audited and logged.

Uhmmm, there should be some kind of negation above, shouldn't it?!

[snip]


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Mike Dresser]

Michael Rothwell wrote:

> Just some thoughts from 35 years ago. Please add your $0.02.

What's that $0.02 worth after 35 years of inflation?

=)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Richard B. Johnson]

On Tue, 14 Nov 2000, Michael Rothwell wrote:

> One historically significant "Enterprise" OS is Multics. It had nine
> major goals. Perhaps we should think about how Linux measures up to
> these 1965 goals for "Enterprise Computing."
>

Multics???  No way. It was abandoned as unusable and part of the
kernel code, basically the boot loader, was modified to become
part of Unix.

You have way too many persons on this list who know the history of
Unix to try this BS.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Mark Hahn]

> > Multics???  [..] way too many persons on this list who know the history of
> > Unix to try this BS.
> 
> So, you're saying their nine goals were bullshit? Multics had a lot of
> problems. But it did a lot of ground-breaking. Perhaps you should reply
> to the nine goals, or the general topic of "Enterpriseness," rather than
> merely express your irrelevant hatred for Multics.

Linux is a good Unix.  if adding "enterpriseness" means violating its 
Unixness, then yes, the goals are bullshit.  in particular, the kind
of extensive, kernel-based auditing and accounting some people talk about, 
as well as the complete evisceration of the Unix design for security, 
would make Linux no Unix at all.  that would be very bad, and indeed Multics
is a fine example of the kind of history we should not repeat.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Richard B. Johnson]

On Tue, 14 Nov 2000, Michael Rothwell wrote:

> "Richard B. Johnson" wrote:
> > Multics???  [..] way too many persons on this list who know the history of
> > Unix to try this BS.
> 
> So, you're saying their nine goals were bullshit? Multics had a lot of
> problems. But it did a lot of ground-breaking. Perhaps you should reply
> to the nine goals, or the general topic of "Enterpriseness," rather than
> merely express your irrelevant hatred for Multics.
>

Relating some "nine goals of 'Enterprise Computing'" to Multics is
the bullshit. When Multics was being developed, the singular goal
was to make an operating system that worked on DEC Equipment without
having to use DEC software. The emphasis was on trying to make it
work period.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[David Relson]

At 11:20 AM 11/14/00, Mike Dresser wrote:
>Michael Rothwell wrote:
>
> > Just some thoughts from 35 years ago. Please add your $0.02.
>
>What's that $0.02 worth after 35 years of inflation?
>
>=)

I'd say inflation has been easily 12x since then.  So $0.02 is now worth 
$0.25, i.e. the 2 cents of yesteryear is now 2 bits :-)


--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson@osagesoftware.com       514 W. Keech Ave.
www.osagesoftware.com          Ann Arbor, MI 48103
voice: 734.821.8800            fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[David Relson]

At 11:41 AM 11/14/00, Richard B. Johnson wrote:
>On Tue, 14 Nov 2000, Michael Rothwell wrote:
>
> > "Richard B. Johnson" wrote:
> > > Multics???  [..] way too many persons on this list who know the 
> history of
> > > Unix to try this BS.
> >
> > So, you're saying their nine goals were bullshit? Multics had a lot of
> > problems. But it did a lot of ground-breaking. Perhaps you should reply
> > to the nine goals, or the general topic of "Enterpriseness," rather than
> > merely express your irrelevant hatred for Multics.
> >
>
>Relating some "nine goals of 'Enterprise Computing'" to Multics is
>the bullshit. When Multics was being developed, the singular goal
>was to make an operating system that worked on DEC Equipment without
>having to use DEC software. The emphasis was on trying to make it
>work period.

DEC?  Try GE, specifically the GE-645 (if my memory hasn't lost any bits).

Speaking of Multics, the last Multics system was just recently 
decomissioned.  I think 35 years is a very impressive lifetime for a 
computer system.  Linux, now at age 9, only has 26 years to go.


David

--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson@osagesoftware.com       514 W. Keech Ave.
www.osagesoftware.com          Ann Arbor, MI 48103
voice: 734.821.8800            fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Andrea Arcangeli]

On Tue, Nov 14, 2000 at 12:14:57PM -0500, Michael Rothwell wrote:
> Ext2 + bdflush + kupdated? Not likely.  To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed. This also ties

What safety problems bdflush/kupdated have? (if something they lacks in
performance since they works on a global dirty list while it should be per
queue dirty list to take the I/O pipeline full on all disks)

> [..] And the ability to grow filesystems online, [..]

This is provided in linux for ages by LVM+reiserfs also in 2.2.x.

Any filesystem with inode map and not dependent on disk offsets to find
stuff (exept the superblock of course) can do the grow almost trivially
and online, the shrink is some more complicated instead.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Meissner]

On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote:
> On Tue, 14 Nov 2000, Michael Rothwell wrote:
> 
> > "Richard B. Johnson" wrote:
> > > Multics???  [..] way too many persons on this list who know the history of
> > > Unix to try this BS.
> > 
> > So, you're saying their nine goals were bullshit? Multics had a lot of
> > problems. But it did a lot of ground-breaking. Perhaps you should reply
> > to the nine goals, or the general topic of "Enterpriseness," rather than
> > merely express your irrelevant hatred for Multics.
> >
> 
> Relating some "nine goals of 'Enterprise Computing'" to Multics is
> the bullshit. When Multics was being developed, the singular goal
> was to make an operating system that worked on DEC Equipment without
> having to use DEC software. The emphasis was on trying to make it
> work period.

Ummm, the way I parse the above statement, you are saying that Multics was
developed to work on DEC equipment without having to use DEC software.  Maybe
we are inhabiting parallel universes, but I'm pretty sure that in my universe,
Multics ran first on GE computers, and then on Honeywell computers when
Honeywell bought the division from GE.  Note, DEC did bid for the Multics
contract but was turned down.  Maybe you are thinking of Tenex or UNIX?

The original machine was a GE-645, which was a segmented, virtual memory system
using 36 bit words.  The operating system and system software was written in
PL/1.  Bell Labs had bought a GE-645 and was one of the three development
partners (along with GE and MIT) until they withdrew in April 1969.  You might
want to browse:

	http://www.multicians.org/

for more of the history of Multics.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Rothwell]

One historically significant "Enterprise" OS is Multics. It had nine
major goals. Perhaps we should think about how Linux measures up to
these 1965 goals for "Enterprise Computing."

1) Convenient remote terminal use. 

Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, serial, etc. I
think we have this one.


2) Continuous operation analogous to power & telephone services. 

No way. Multics could have a whole bank of memory fail and keep running.
You could add CPUs, memory and IO devices while it was running without
interrupting users' work. Of course, a lot of this cannot be
accomplished due to the brain-dead hardware designs (especially PC)
prevalent today. However, Linux does not have any support for this type
of facility. I recently saw a patch to let Linux use partially bad
memory. This is a step in the right direction. The ability to scale the
system while on-line is extremely valuable.
    
3) A wide range of system configurations, changeable without system or
user program reorganization. 

See comments in #2. Plus, the recent two-kernel-monte, linux-from-linux
type stuff would be especially excellent if it will allow the kernel to
be upgraded on the fly. If it could save state and have the new kernel
take over, that would rock. On a smaller scale, allowing this for
modules would be good. This would allow the upgrade of nic drivers, etc.
The GKHI would also be invaluable if it would allow the
replacement/augmentation of certain other subsystems on the fly -- such
as the scheduler, VFS, etc.
                               
4) A high reliability internal file system. 

Ext2 + bdflush + kupdated? Not likely.  To quote the Be Filesystems
book, Ext2 throws safety to the wind to achieve speed. This also ties
into Linux' convoluted VM system, and is shot in the foot by NFS. We
would need minimally a journaled filesystem and a clean VM design,
probably with a unified cache (no separate buffer, directory entry and
page caches). The Tux2 Phase Trees look to be a good step in the
direction as well, in terms of FS reliability. The filesystem would have
to do checksums on every block. Some type of mirroring/clustering would
be good. And the ability to grow filesystems online, and replace disks
online, would be key. If your disks are getting old, you may want to
pre-emptively replace them with faster, newer, larger ones with more
MTBF left.

5) Support for selective information sharing. 

Linux has a rather poor security model -- the Unix one. It needs ACLs no
only on filesystem objects, but on other OS features as well; such as
the ability to use network interfaces, packet types, display ACLs,
console ACLs, etc. If there's a function, it probably needs an ACL.

6) Hierarchical structures of information for system administration and
decentralization of user activities. 

See #5. Linux really does not support delgation of authority well.
There's one user who can reconfigure/admin the system: root. Tools like
sudo only make you root for a moment, and don't inherently limit you to
that one activity. ACLs on most if not all system attributes and objects
would go a long way towards decentralized but safe administration.

7) Support for a wide range of applications. 

Well... anything wih source or compiled for the Linux ABI. A
microkernel-type architecture with servers would provide a lot more of
this. See QNX, NT, Mach.

8) Support for multiple programming environments & human interfaces. 

Many languages are supported by Linux. This is good. Linux has two
humnan interfaces: CLI and X Windows guis. I'm not sure what could be
added, except for voice input.

9) The ability to evolve the system with changes in technology and in
user aspirations.

Ties ties into #2 and #3and #5. Otherwise, rewrites of the Linux kernel
and userspace accomplish this. Unfortunately, that requires taking the
system, or minimally its applications, down.

Just some thoughts from 35 years ago. Please add your $0.02.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Rothwell]

Mike Dresser wrote:

> What's that $0.02 worth after 35 years of inflation?

About $6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Rothwell]

"Richard B. Johnson" wrote:
> Multics???  [..] way too many persons on this list who know the history of
> Unix to try this BS.

So, you're saying their nine goals were bullshit? Multics had a lot of
problems. But it did a lot of ground-breaking. Perhaps you should reply
to the nine goals, or the general topic of "Enterpriseness," rather than
merely express your irrelevant hatred for Multics.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Rothwell]

Michael Rothwell wrote:
> 
> Mike Dresser wrote:
> 
> > What's that $0.02 worth after 35 years of inflation?
> 
> About $6

Sorry.. six times a much... not six dollars. Which means $0.02 circa
1965 is 'worth' $0.12 today, given an average annual devaluation of the
currency of 5.2% since 1965.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Andrea Arcangeli]

On Tue, Nov 14, 2000 at 08:59:49AM -0600, Jesse Pollard wrote:
>    I (meaning me) would like the ability to audit every system call. (yes,
>    this is horrendous, if everything is logged, but I want to be able to
>    choose how much is logged at the source of the data, rather than at
>    the destination. That would reduce the total data flood to what is
>    manageable or desired.

Yes, you really need to control the logging at the source of the data. To do
that we need to use to use self modifying tricks as dprobes and GKHI does to
provide "fast unregistered hooks".

o	with dprobes the hooks will be _absolutely_ zero cost if they're
	unregistered but they're very costly (basically enter/exit kernel
	for every hook) when they're registered (so they're ok if
	your auditing doesn't happen all the time).

	dprobe hooks also binds you to a certain binary image (not a generic
	interface stable across different kernel binaries)

o	GKHI provides fast unregistered hooks too, if implemented with
	5 nops as suggested they will cost around 3 cycles when they're
	unregistered, and they will provide good performance also when
	they're registered (no enter/exit kernel as dprobes needs
	to do) and you can control them via userspace without being dependent
	on binary offsets (just like with every other hook we have in kernel
	just now but with the difference that our current hooks aren't self
	modifying so they adds branches also when they're unregistered so
	they're bad for usages like syscall auditing). However bloating every
	syscall with tons of GKHI hooks isn't possible either or it will become
	a performance problem too eventually. It depends what you need exactly.
	I'd say one GKHI hook per syscall shouldn't have measurable impact on
	performance.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Buddha Buck]

At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote:
>"Richard B. Johnson" wrote:
>
> > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > the bullshit.
>
>Funny, I got those off the "Multics FAQ" page.

It may be reasonable to question them as "goals of 'Enterprise Computing'".

I found, on http://www.multicians.org/general.html, a list of those same 
nine goals, introduced by the sentence "As described in the 1965 paper 
Introduction and Overview of the Multics System by Corbató and Vyssotsky, 
there were nine major goals for Multics:"

While those were the goals of Multics, it is not at all clear that Multics 
would classify these days as a platform for "Enterprise Computing".  I'll 
note that the word "enterprise" does not appear in either the general FAQ 
page I cited, nor in the linked article it cites.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Andreas Dilger]

Michael Rothwell writes:
> 4) A high reliability internal file system. 
> 
> Ext2 + bdflush + kupdated? Not likely.  To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed. This also ties
> into Linux' convoluted VM system, and is shot in the foot by NFS. We
> would need minimally a journaled filesystem and a clean VM design,
> probably with a unified cache (no separate buffer, directory entry and
> page caches). The Tux2 Phase Trees look to be a good step in the
> direction as well, in terms of FS reliability.

Ext3 is doing pretty well...

> The filesystem would have
> to do checksums on every block. Some type of mirroring/clustering would
> be good. And the ability to grow filesystems online, and replace disks
> online, would be key. If your disks are getting old, you may want to
> pre-emptively replace them with faster, newer, larger ones with more
> MTBF left.

You can always do this in the hardware - no reason to do it in software.
If you are using RAID 5, and you wanted to take the performance hit you
could always calculate the checksums for each stripe on read to detect
errors.  You may even be able to add a second parity disk to do ECC on
the disk data.

As for online resizing, you can do this with ext2 for a long time with
my ext2online patches/tools.  LVM lets you migrate between disks online.
You need hardware support (available) to do hot-swap disks - SCSI works,
but I don't think the IDE code is ready for hot-swap yet.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Richard B. Johnson]

On Tue, 14 Nov 2000, Michael Meissner wrote:

> On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote:
> > On Tue, 14 Nov 2000, Michael Rothwell wrote:
> > 
> > > "Richard B. Johnson" wrote:
> > > > Multics???  [..] way too many persons on this list who know the history of
> > > > Unix to try this BS.
> > > 
> > > So, you're saying their nine goals were bullshit? Multics had a lot of
> > > problems. But it did a lot of ground-breaking. Perhaps you should reply
> > > to the nine goals, or the general topic of "Enterpriseness," rather than
> > > merely express your irrelevant hatred for Multics.
> > >
> > 
> > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > the bullshit. When Multics was being developed, the singular goal
> > was to make an operating system that worked on DEC Equipment without
> > having to use DEC software. The emphasis was on trying to make it
> > work period.
> 
> Ummm, the way I parse the above statement, you are saying that Multics was
> developed to work on DEC equipment without having to use DEC software.  Maybe
> we are inhabiting parallel universes, but I'm pretty sure that in my universe,
> Multics ran first on GE computers, and then on Honeywell computers when
> Honeywell bought the division from GE.  Note, DEC did bid for the Multics
> contract but was turned down.  Maybe you are thinking of Tenex or UNIX?
> 
> The original machine was a GE-645, which was a segmented, virtual memory system
> using 36 bit words.  The operating system and system software was written in
> PL/1.  Bell Labs had bought a GE-645 and was one of the three development
> partners (along with GE and MIT) until they withdrew in April 1969.  You might
> want to browse:
> 

No parallel universe. When Multics was being developed by AT&T,
it was found to be unusable on the DEC. It was a PDP-8, so the
story is told.  General Electric got the first contract to make
a machine specifically designed for Multics and development
continued.

The original DEC was "given" to W. M. Ritchie and his staff in
"Department 58213". He wanted to use it for games. To do so, required
him to write some sort of OS, which became Unix.

As I said, when Multics was designed, the only criteria as to
get it to work on a DEC. It didn't. To use this development as
an example of "enterprise computing" is absurd and belies its
well documented history. 


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Richard B. Johnson]

On Tue, 14 Nov 2000, Michael Rothwell wrote:

> "Richard B. Johnson" wrote:
> 
> > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > the bullshit. 
> 
> Funny, I got those off the "Multics FAQ" page.
> 
> -M
> 


History is being rewritten. When Multics was being developed by AT&T,
it was found to be unusable on the DEC. It was a PDP-8, so the
story is told.  General Electric got the first contract to make
a machine specifically designed for Multics and development
continued.

The original DEC was "given" to W. M. Ritchie and his staff in
"Department 58213". He wanted to use it for games. To do so, required
him to write some sort of OS, which became Unix.

As I said, when Multics was designed, the only criteria as to
get it to work on a DEC. It didn't. To use this development as
an example of "enterprise computing" is absurd and belies its
well documented history.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

Sorry, wrong answer, but thanks for playing.

When Multics was developed, (early 60s,) DEC equipment wasn't even
interesting to much of an audience.  The original equipment Multics ran on
was build by one of the "seven dwarf" computer companies, (GE) which was
soon to get out of the computer business altogether.

I would suggest Organick's book, if I could recall the title.

Marty

-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
Sent: Tuesday, November 14, 2000 8:42 AM
To: Michael Rothwell
Cc: Linux kernel
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel


On Tue, 14 Nov 2000, Michael Rothwell wrote:

> "Richard B. Johnson" wrote:
> > Multics???  [..] way too many persons on this list who know the history
of
> > Unix to try this BS.
> 
> So, you're saying their nine goals were bullshit? Multics had a lot of
> problems. But it did a lot of ground-breaking. Perhaps you should reply
> to the nine goals, or the general topic of "Enterpriseness," rather than
> merely express your irrelevant hatred for Multics.
>

Relating some "nine goals of 'Enterprise Computing'" to Multics is
the bullshit. When Multics was being developed, the singular goal
was to make an operating system that worked on DEC Equipment without
having to use DEC software. The emphasis was on trying to make it
work period.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

Sorry, wrong answer, but thanks for playing.  Multics was not abandoned as
unusable, and was, in fact, widely used, sometimes in what would now be
called "mission critical" applications, for a long time. While Honeywell
finally stopped supporting Multics sometime in the 90s, I was surprised and
delighted to find that there are still Multics systems running.

There may be many people on this list who know the history of Unix, but from
this thread, I'm thinking that perhaps there is some confusion between the
history and the mythology.

Perhaps we could get AT&T, Lucent, or whomever owns the copyright these
days, to reprint the "Unix" issue of the Bell Systems Journal.

Marty

-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
Sent: Tuesday, November 14, 2000 8:26 AM
To: Michael Rothwell
Cc: Linux kernel
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel


On Tue, 14 Nov 2000, Michael Rothwell wrote:

> One historically significant "Enterprise" OS is Multics. It had nine
> major goals. Perhaps we should think about how Linux measures up to
> these 1965 goals for "Enterprise Computing."
>

Multics???  No way. It was abandoned as unusable and part of the
kernel code, basically the boot loader, was modified to become
part of Unix.

You have way too many persons on this list who know the history of
Unix to try this BS.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

Actually, you have the sequence of events slightly out of order.  AT&T,
specifically Bell Labs, was one of the participants in the program that
would develop Multics. AT&T opted out of the program, for various reasons,
but it continued apace.  The PDP-8 of fame was one that, according to
Thompson, happened to be available and unused.

-----Original Message-----
From: Richard B. Johnson [mailto:root@chaos.analogic.com]
Sent: Tuesday, November 14, 2000 10:01 AM
To: Michael Rothwell
Cc: Linux kernel
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel


On Tue, 14 Nov 2000, Michael Rothwell wrote:

> "Richard B. Johnson" wrote:
> 
> > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > the bullshit. 
> 
> Funny, I got those off the "Multics FAQ" page.
> 
> -M
> 


History is being rewritten. When Multics was being developed by AT&T,
it was found to be unusable on the DEC. It was a PDP-8, so the
story is told.  General Electric got the first contract to make
a machine specifically designed for Multics and development
continued.

The original DEC was "given" to W. M. Ritchie and his staff in
"Department 58213". He wanted to use it for games. To do so, required
him to write some sort of OS, which became Unix.

As I said, when Multics was designed, the only criteria as to
get it to work on a DEC. It didn't. To use this development as
an example of "enterprise computing" is absurd and belies its
well documented history.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Michael Rothwell]

"Richard B. Johnson" wrote:

> Relating some "nine goals of 'Enterprise Computing'" to Multics is
> the bullshit. 

Funny, I got those off the "Multics FAQ" page.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Rik van Riel]

On Tue, 14 Nov 2000, Richard B. Johnson wrote:
> On Tue, 14 Nov 2000, Michael Rothwell wrote:
> 
> > One historically significant "Enterprise" OS is Multics. It had nine
> > major goals. Perhaps we should think about how Linux measures up to
> > these 1965 goals for "Enterprise Computing."
> >
> 
> Multics???  No way. It was abandoned as unusable and part of the
> kernel code, basically the boot loader, was modified to become
> part of Unix.

"take a look at the goals Multics had" != "please reimplement Multics"

Flaming is ok, but you should really read the WHOLE email
before replying, otherwise you might end up with a flame
that isn't relevant at all to the email it supposedly is
a reply to...

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

Dick Johnson wrote:

> The original DEC was "given" to W. M. Ritchie and his staff in
> "Department 58213". He wanted to use it for games. To do so, required
> him to write some sort of OS, which became Unix.

A typo, I assume.  That's D(ennis) Ritchie.

> As I said, when Multics was designed, the only criteria as to
> get it to work on a DEC. It didn't. To use this development as
> an example of "enterprise computing" is absurd and belies its
> well documented history.

How odd then, that Corbato's '65 paper specifically describes it as a
research effort on a GE system, and both Ritchie and Thompson have written
to similar effect and Glasser et al wrote 

In the late spring and early summer of 1964 it became obvious that greater
facility in the computing system was required if time-sharing techniques
were to move from the state of an interesting pilot experiment into that of
a useful prototype for remote access computer systems. Investigation proved
computers that were immediately available could not be adapted readily to
meet the difficult set of requirements time-sharing places on any machine.
However, there was one system that appeared to be extendible into what was
desired. This machine was the General Electric 635.

Multics grew out of research into the design of timesharing systems at MIT,
and is from the same family of systems as ITS.  It had a long and
interesting history and was supported by Honeywell into the 90s.

There were several other interesting OSes developed in that time frame, such
as SDS's CP/V for the Sigma series, but most of them were not described in
the literature and so are long forgotten.

Marty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

I would agree that Multics probably wouldn't qualify as a platform for
enterprise computing these days, but it is interesting to examine the 9
stated goals, and see how they relate to enterprise computing.  They are
applicable goals, although they certainly don't qualify as the only set, and
could well be expanded given what has been learned in the 35 years since.

Marty

-----Original Message-----
From: Buddha Buck [mailto:bmbuck@14850.com]
Sent: Tuesday, November 14, 2000 9:52 AM
To: Michael Rothwell; root@chaos.analogic.com
Cc: Linux kernel
Subject: Re: Advanced Linux Kernel/Enterprise Linux Kernel


At 01:10 PM 11/14/00 -0500, Michael Rothwell wrote:
>"Richard B. Johnson" wrote:
>
> > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > the bullshit.
>
>Funny, I got those off the "Multics FAQ" page.

It may be reasonable to question them as "goals of 'Enterprise Computing'".

I found, on http://www.multicians.org/general.html, a list of those same 
nine goals, introduced by the sentence "As described in the 1965 paper 
Introduction and Overview of the Multics System by Corbató and Vyssotsky, 
there were nine major goals for Multics:"

While those were the goals of Multics, it is not at all clear that Multics 
would classify these days as a platform for "Enterprise Computing".  I'll 
note that the word "enterprise" does not appear in either the general FAQ 
page I cited, nor in the linked article it cites.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[lamont]

if you look at the kstat structure under solaris, there's a lot of info
there that'd be good to be able to pull out of the linux kernel.  that
would slow down the kernel a little, lead to some 'bloat' that linus
abhors and such, but its good to have that information for monitoring and
debugging problems.  it'd also be nice to have hooks built in to monitor
errors in the disk subsystem and ideally warn of impending failures as
much as possible -- that might be better done in userspace.  and pretty
much you want all error messages from different subsystems to be monitored
and appropriate action taken.  ideally all error messages from the kernel
and device drivers should be standardized and HA software can then monitor
them and take appropriate actions when it sees one that indicates
failure.  sun is currently in the process of documenting all the kernel
error messages from what i understand.  those are the kinds of things that
give IT managers and sysadmins warm fuzzy feelings about solaris.

On Mon, 13 Nov 2000, Josue Emmanuel Amaro wrote:
> This subject came up in the Generalized Kernel Hooks Interface thread, since it
> is an area of interest to me I wanted to continue that conversation.
> 
> While I do not think it would be productive to enter a discussion whether there
> is a need to fork the kernel to add features that would be beneficial to
> mission/business critical applications, I am curious as to what are the features
> that people consider important to have.  By mission critical I mean systems that
> if not functional bring a business to a halt, while by business critical I mean
> systems that affect a division of a business.
> 
> Another problem is how people define Enterprise Systems.  Many base it on the
> definitions that go back to S390 systems, others in the context of the 24/7
> nature of the internet.  That would also be a healthy discussion to have.
> 
> At Oracle we are primarily interested on I/O subsystem features and memory
> management.  (For anyone that knows anything about Oracle this should not come
> as a surprise, although I am pretty sure that any database vendor/developer
> would be interested on those features as well.)
> 
> Regards,
> 
> --
> =======================================================================
>   Josue Emmanuel Amaro                         Josue.Amaro@oracle.com
>   Linux Products Manager
>   Intel and Linux Technologies Group
> =======================================================================
> 
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Christoph Hellwig]

In article <3A117311.8DC02909@holly-springs.nc.us> you wrote:
> 2) Continuous operation analogous to power & telephone services. 

> No way. Multics could have a whole bank of memory fail and keep running.
> You could add CPUs, memory and IO devices while it was running without
> interrupting users' work. Of course, a lot of this cannot be
> accomplished due to the brain-dead hardware designs (especially PC)
> prevalent today. However, Linux does not have any support for this type
> of facility. I recently saw a patch to let Linux use partially bad
> memory. This is a step in the right direction. The ability to scale the
> system while on-line is extremely valuable.

Motorola has announced Linux Systems with a Hot-Plug CPU - but this seems
to be more a hardware then a software feature.

> 4) A high reliability internal file system. 

> Ext2 + bdflush + kupdated? Not likely.  To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed.

No.  Shure, you don't have all the nice features of log structured or
journaled filesystem, but ext2 is pretty reliable for a traditional fs.
(I'd like to see if the multics fs was better, do you have a pointer?)

> This also ties
> into Linux' convoluted VM system, and is shot in the foot by NFS. We
> would need minimally a journaled filesystem and a clean VM design,
> probably with a unified cache (no separate buffer, directory entry and
> page caches).

The dcache is not a disk cache.  It caches directory lookups, it is
neither something VM related nor does it inpact reliability.
The buffercache seems pretty dead in the near future - filesystems
are going towards putting metadata in the page cache.
(See Al Viro's ext2 patches)

> The Tux2 Phase Trees look to be a good step in the
> direction as well, in terms of FS reliability.

> The filesystem would have to do checksums on every block.

The filesystem?  This does not belong into the filesystem. An ecc 
personality for md might be a much better idea ...

> Some type of mirroring/clustering would be good.

Mirroring does _not_ belong into the fs layer, it belongs into LVM, software -,
or if you want a really reliable system, hardware raid.

> And the ability to grow filesystems online, and replace disks
> online, would be key. If your disks are getting old, you may want to
> pre-emptively replace them with faster, newer, larger ones with more
> MTBF left.

Why don't you use LVM?

> 5) Support for selective information sharing. 

> Linux has a rather poor security model -- the Unix one. It needs ACLs no
> only on filesystem objects, but on other OS features as well; such as
> the ability to use network interfaces, packet types, display ACLs,
> console ACLs, etc. If there's a function, it probably needs an ACL.

ACLs are not really interesting.  They are like good-old file rights with
some nice new features and much more complicated.  You want MACs and
Capabilities (the latter are implemented in Linux).

> 6) Hierarchical structures of information for system administration and
> decentralization of user activities. 

> See #5. Linux really does not support delgation of authority well.
> There's one user who can reconfigure/admin the system: root.

No, there is not.  There is a capability for each job (or a group of jobs).
The root user is just UNIX-Legacy. (ok, ok nearly every system has one -
but the Linux security model doesn't really need it).

> 7) Support for a wide range of applications. 

> Well... anything wih source or compiled for the Linux ABI. A
> microkernel-type architecture with servers would provide a lot more of
> this. See QNX, NT, Mach.

Shure. NT supports win32, win16, dos and recompiled UNIX binaries.
QNX supports QNX and now Linux binaries.
Thanks to the personality architecture I can (and do) run UnixWare,
OpenServer, etc binaries under Linux.  And I can use dosemu, wine, etc ...

	Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[spam]

On Tue, 14 Nov 2000, Richard B. Johnson wrote:

> On Tue, 14 Nov 2000, Michael Rothwell wrote:
> 
> > One historically significant "Enterprise" OS is Multics. It had nine
> > major goals. Perhaps we should think about how Linux measures up to
> > these 1965 goals for "Enterprise Computing."
> >
> 2
> Multics???  No way. It was abandoned as unusable and part of the
> kernel code, basically the boot loader, was modified to become
> part of Unix.
> 
> You have way too many persons on this list who know the history of
> Unix to try this BS.

Perhaps this is a call for forking off linux into other project, It is not
unreasonable, if goals of one do not match with the other. =)
However the guy said that goals are applicable to linux, he did not say
rewrite linux to be multics...
Pavel.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[spam]

On Tue, 14 Nov 2000, Mark Hahn wrote:

> Linux is a good Unix.  if adding "enterpriseness" means violating its 
> Unixness, then yes, the goals are bullshit.  in particular, the kind
> of extensive, kernel-based auditing and accounting some people talk about, 
> as well as the complete evisceration of the Unix design for security, 
> would make Linux no Unix at all.  that would be very bad, and indeed Multics
> is a fine example of the kind of history we should not repeat.

Are you one of those people who say X11 sucks? And whole idea of a
neworked gui sucks? Like ones who threaten to rewrite entire gui without
planning, in OpenGL and use the rest of the energy tarishing X?
Well, if it is done, probably you won't have to compile those extensions
in anyway, so what's the whining about? Enterprise level features will
let linux run on Mainframes not in pitiful x86 emulation mode, with hot
swappable hardware. Just like raid. Would you say RAID sucks a** and
weighs down linux, because it is an enterprise feature? By the tone of
your voice it seems so.
I am for a concious featurism, add features as long as others are stable
and fixed(not in MS way)

pavel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Steve VanDevender]

Marty Fouts writes:
 > Actually, you have the sequence of events slightly out of order.  AT&T,
 > specifically Bell Labs, was one of the participants in the program that
 > would develop Multics. AT&T opted out of the program, for various reasons,
 > but it continued apace.  The PDP-8 of fame was one that, according to
 > Thompson, happened to be available and unused.

The original system on which UNIX development started was not a PDP-8,
but a PDP-7.  The earliest UNIX was also written in assembler.  Thompson
and Ritchie developed C as a higher-level implementation language during
the process of porting UNIX from the PDP-7 to the PDP-11.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Alexander Viro]

On Tue, 14 Nov 2000, Richard B. Johnson wrote:

> On Tue, 14 Nov 2000, Michael Rothwell wrote:
> 
> > "Richard B. Johnson" wrote:
> > > Multics???  [..] way too many persons on this list who know the history of
> > > Unix to try this BS.
> > 
> > So, you're saying their nine goals were bullshit? Multics had a lot of
> > problems. But it did a lot of ground-breaking. Perhaps you should reply
> > to the nine goals, or the general topic of "Enterpriseness," rather than
> > merely express your irrelevant hatred for Multics.
> >
> 
> Relating some "nine goals of 'Enterprise Computing'" to Multics is
> the bullshit. When Multics was being developed, the singular goal
> was to make an operating system that worked on DEC Equipment without
> having to use DEC software. The emphasis was on trying to make it
> work period.

WTF are you smoking? Multics never ran on DEC hardware. Moreover, your
ideas about UNIX history ("modified Multics bootloader" bit) are, well,
interesting. Porting from GE to PDP-7... <shudder> Besides, the thing
had wildly different fs usage model - "everything is mmaped segment" vs.
UNIX "everything is stream of characters".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Werner Almesberger]

Michael Rothwell wrote:
> 2) Continuous operation analogous to power & telephone services. 
> 
> No way. Multics could have a whole bank of memory fail and keep running.
[...]

Considering that it's very cheap nowadays to have redundancy at the
box level, designs attempting to achieve robustness at the component
level may fail to benefit from changes in the hardware market in the
last few decades. Maybe we need a Beowulf for fault tolerance ...

> 3) A wide range of system configurations, changeable without system or
> user program reorganization. 

I'd say we're largely there: /proc/sys and modules give you a lot of
freedom, if properly used.

> See comments in #2. Plus, the recent two-kernel-monte, linux-from-linux
> type stuff would be especially excellent if it will allow the kernel to
> be upgraded on the fly.

Difficult, because there's no reliable (= automated) means of tracking
data structures an the semantics of internal interfaces from kernel to
kernel. Feasible for selected subsystems and with coarse granularity,
though. (E.g. modules.)

> console ACLs, etc. If there's a function, it probably needs an ACL.

Empirical evidence with VMS suggests that overly sophisticated
security mechanisms can actually decrease overall security, because
they may lead people to micro-manage security and to neglect the
overall security concept.

> 7) Support for a wide range of applications. 
> 
> Well... anything wih source or compiled for the Linux ABI. A
> microkernel-type architecture with servers would provide a lot more of
> this. See QNX, NT, Mach.

Hmm, I don't think you want to say this :)

> 9) The ability to evolve the system with changes in technology and in
> user aspirations.

That's perhaps the most important point. The computing environment
has changed a lot. Take for example Google's PC farm and compare
this with the mainframe approach one would have chosen twenty or
thirty years ago. Mainframes are still the right answer for some
problems, but their role in the solution may be very different from
the days when they were the only solution, and all of the solution.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Gerhard Mack]

On Tue, 14 Nov 2000, Richard B. Johnson wrote:

> On Tue, 14 Nov 2000, Michael Rothwell wrote:
> 
> > "Richard B. Johnson" wrote:
> > 
> > > Relating some "nine goals of 'Enterprise Computing'" to Multics is
> > > the bullshit. 
> > 
> > Funny, I got those off the "Multics FAQ" page.
> > 
> > -M
> > 
> 
> 
> History is being rewritten. When Multics was being developed by AT&T,
> it was found to be unusable on the DEC. It was a PDP-8, so the
> story is told.  General Electric got the first contract to make
> a machine specifically designed for Multics and development
> continued.
> 
> The original DEC was "given" to W. M. Ritchie and his staff in
> "Department 58213". He wanted to use it for games. To do so, required
> him to write some sort of OS, which became Unix.
> 
> As I said, when Multics was designed, the only criteria as to
> get it to work on a DEC. It didn't. To use this development as
> an example of "enterprise computing" is absurd and belies its
> well documented history.

<SARCASM>
But .. but... but they said so on slashdot. That must make it true. ;)
</SARCASM>

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Leo Mauro]

On Tuesday 14 November 2000 03:43 pm, Steve VanDevender wrote:

>Marty Fouts writes:
> > Actually, you have the sequence of events slightly out of order. 
> > AT&T, specifically Bell Labs, was one of the participants in the
> > program that would develop Multics. AT&T opted out of the
> > program, for various reasons, but it continued apace.  The PDP-8
> > of fame was one that, according to Thompson, happened to be
> > available and unused.
>
>The original system on which UNIX development started was not a
> PDP-8, but a PDP-7.  The earliest UNIX was also written in
> assembler.  Thompson and Ritchie developed C as a higher-level
> implementation language during the process of porting UNIX from the
> PDP-7 to the PDP-11.

I haven't seen anybody point at this URL

	http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

where you can read about early Unix story from the horse's mouth 
himself.  The paper is 20 years old, but still full of very tasty 
tidbits.  Browse around and you'll find many more interesting goodies.
In particular, if you want to know the story of how C came to be, as 
told by its creator, try this URL

	http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Take it from somebody who has been hacking all sorts of Unix and 
Unix-like kernels for the last 25 years: Those who don't know Unix 
history are doomed to reimplement it badly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Advanced Linux Kernel/Enterprise Linux Kernel

[Marty Fouts]

Er, um, yes.  I stand corrected.


-----Original Message-----
From: Steve VanDevender [mailto:stevev@efn.org]
Sent: Tuesday, November 14, 2000 11:44 AM
To: Marty Fouts
Cc: 'root@chaos.analogic.com'; Michael Rothwell; Linux kernel
Subject: RE: Advanced Linux Kernel/Enterprise Linux Kernel


Marty Fouts writes:
 > Actually, you have the sequence of events slightly out of order.  AT&T,
 > specifically Bell Labs, was one of the participants in the program that
 > would develop Multics. AT&T opted out of the program, for various
reasons,
 > but it continued apace.  The PDP-8 of fame was one that, according to
 > Thompson, happened to be available and unused.

The original system on which UNIX development started was not a PDP-8,
but a PDP-7.  The earliest UNIX was also written in assembler.  Thompson
and Ritchie developed C as a higher-level implementation language during
the process of porting UNIX from the PDP-7 to the PDP-11.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Albert D. Cahalan]

Michael Rothwell writes:

> 1) Convenient remote terminal use. 
>
> Telnet, ssh, X windows, rsh, vnc, "screen," ethernet,
> serial, etc. I think we have this one.

Nope: /dev/audio, /dev/cdrom, /dev/floppy, fonts, etc.

Also one would want a local window manager for performance,
but this tends to interfere with starting apps on the other
system.

> 4) A high reliability internal file system. 

Now we want it distributed, with version control, with
mirroring onto N of M machines and migration toward usage...

> 5) Support for selective information sharing. 
>
> Linux has a rather poor security model -- the Unix one.
> It needs ACLs no only on filesystem objects, but on other
> OS features as well; such as the ability to use network
> interfaces, packet types, display ACLs, console ACLs, etc.

It would have been nice to have just put 2 entries right
in the inode years ago. With the KISS method, we'd be using
ACLs right now. Even just a list of UIDs that would share
permission bits with the file's GID would be very useful.
I just want to share a file with one other person!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Bernd Eckenfels]

In article <20001114084949.C723@marowsky-bree.de> you wrote:
> But also scalability: 2TB is a problem for me in some cases, 32bit just don't
> cut it all the time - but I need to circumvent the storage problem even on a
> 32bit system. And adding disks to the system while running is desireable.

Why do you run 32bit Systems in the First Place? This can solve a lot of
flaky PC Hardware Issues, too... (also it does not help in Hotplug PCI and
CPU).

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Daniel Phillips]

Michael Rothwell wrote:
> 4) A high reliability internal file system.
> 
> Ext2 + bdflush + kupdated? Not likely.  To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed. This also ties
> into Linux' convoluted VM system, and is shot in the foot by NFS. We
> would need minimally a journaled filesystem and a clean VM design,
> probably with a unified cache (no separate buffer, directory entry and
> page caches). The Tux2 Phase Trees look to be a good step in the
> direction as well, in terms of FS reliability. The filesystem would have
> to do checksums on every block.

Actually, I was planning on doing on putting in a hack to do something
like that: calculate a checksum after every buffer data update and check
it after write completion, to make sure nothing scribbled in the buffer
in the interim.  This would also pick up some bad memory problems.

> Some type of mirroring/clustering would
> be good. And the ability to grow filesystems online, and replace disks
> online, would be key. If your disks are getting old, you may want to
> pre-emptively replace them with faster, newer, larger ones with more
> MTBF left.

This is all coming, but as you say, it's not quite here yet.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Eric W. Biederman]

Daniel Phillips <news-innominate.list.linux.kernel@innominate.de> writes:

> Actually, I was planning on doing on putting in a hack to do something
> like that: calculate a checksum after every buffer data update and check
> it after write completion, to make sure nothing scribbled in the buffer
> in the interim.  This would also pick up some bad memory problems.

Be very careful that this just applies to metadata.  For normal data
this is a valid case.  Weird but valid.


Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Pavel Machek]

Hi!

> > book, Ext2 throws safety to the wind to achieve speed. This also ties
> > into Linux' convoluted VM system, and is shot in the foot by NFS. We
> > would need minimally a journaled filesystem and a clean VM design,
> > probably with a unified cache (no separate buffer, directory entry and
> > page caches). The Tux2 Phase Trees look to be a good step in the
> > direction as well, in terms of FS reliability. The filesystem would have
> > to do checksums on every block.
> 
> Actually, I was planning on doing on putting in a hack to do something
> like that: calculate a checksum after every buffer data update and check
> it after write completion, to make sure nothing scribbled in the buffer
> in the interim.  This would also pick up some bad memory problems.

You might want to take  look to a patch with crc loop option.

It does verify during read, not during write; but that's even better because
that way you pick up problems in IO subsystem, too.
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Daniel Phillips]

"Eric W. Biederman" wrote:
> 
> Daniel Phillips <news-innominate.list.linux.kernel@innominate.de> writes:
> 
> > Actually, I was planning on doing on putting in a hack to do something
> > like that: calculate a checksum after every buffer data update and check
> > it after write completion, to make sure nothing scribbled in the buffer
> > in the interim.  This would also pick up some bad memory problems.
> 
> Be very careful that this just applies to metadata.  For normal data
> this is a valid case.  Weird but valid.

I'm not sure what you mean.  With the exception of mmap'd files, the
filesystem (or VFS) controls every transfer onto a buffer so... what
does that leave?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Daniel Phillips]

Pavel Machek wrote:
> > Actually, I was planning on doing on putting in a hack to do something
> > like that: calculate a checksum after every buffer data update and check
> > it after write completion, to make sure nothing scribbled in the buffer
> > in the interim.  This would also pick up some bad memory problems.
> 
> You might want to take  look to a patch with crc loop option.
> 
> It does verify during read, not during write; but that's even better because
> that way you pick up problems in IO subsystem, too.

You would have to store the checksums on the filesystem then, or use a
verify-after-write.  What I was talking about is a
verify-the-buffer-didn't get scribbled.  I'd then trust the hardware to
report a write failure.  Note that if something scribbles on your buffer
between the time you put good data on it and when it gets transfered to
disk, you can verify perfectly and still have a hosed filesystem.

It was pointed out that you can't really do what I'm suggesting for
mmaped file data, and there's some truth to that - but certainly the
interval between when ->writepage gets called and when the actual buffer
write happens can be secured in this way.  Doing this only for metadata
is also a good idea because then the overhead would be close to nil and
the basic fs integrity would be protected.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Advanced Linux Kernel/Enterprise Linux Kernel

[Pavel Machek]

Hi!

> > > Actually, I was planning on doing on putting in a hack to do something
> > > like that: calculate a checksum after every buffer data update and check
> > > it after write completion, to make sure nothing scribbled in the buffer
> > > in the interim.  This would also pick up some bad memory problems.
> > 
> > You might want to take  look to a patch with crc loop option.
> > 
> > It does verify during read, not during write; but that's even better because
> > that way you pick up problems in IO subsystem, too.
> 
> You would have to store the checksums on the filesystem then, or use a

I store checksums in separate partition.

> verify-after-write.  What I was talking about is a
> verify-the-buffer-didn't get scribbled.  I'd then trust the hardware to
> report a write failure.  Note that if something scribbles on your buffer
> between the time you put good data on it and when it gets transfered to
> disk, you can verify perfectly and still have a hosed filesystem.

Actually, I have 50% chance detecting that corruption. If it happens
between application and loop, I detect nothing. If it happens between
loop and disk, I catch it.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/