[EMAIL PROTECTED] wrote:
> > Well, not necessarily so while lkcd is not get accepted into the standard
> > kernel source. [..]
>
> It won't until it uses a separate driver that doesn't depend on scsi or
> ide layer.
We're working on it ... can't quit my day job, you know ... :)
--Matt
-
To
Please respond to Andrea Arcangeli <[EMAIL PROTECTED]>
To: Richard J Moore/UK/IBM@IBMGB
cc:
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Wed, Nov 15, 2000 at 05:14:57AM +, [EMAIL PROTECTED] wrote:
>
>
> Andrea,
>
> I am very great
Andrea,
I am very greatful for your detailed analysis. I have yet to digest
everything you commented but will get back to you on all points you raise
very soon. Here are my thoughts so far:
> I think gkhi should be renamed to something like "Fast Unregistered
Kernel
> Hook Interface" to
Please respond to Andrea Arcangeli [EMAIL PROTECTED]
To: Richard J Moore/UK/IBM@IBMGB
cc:
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Wed, Nov 15, 2000 at 05:14:57AM +, [EMAIL PROTECTED] wrote:
Andrea,
I am very greatful for your detailed analysis. I
Andrea,
I am very greatful for your detailed analysis. I have yet to digest
everything you commented but will get back to you on all points you raise
very soon. Here are my thoughts so far:
I think gkhi should be renamed to something like "Fast Unregistered
Kernel
Hook Interface" to avoid
[EMAIL PROTECTED] wrote:
Well, not necessarily so while lkcd is not get accepted into the standard
kernel source. [..]
It won't until it uses a separate driver that doesn't depend on scsi or
ide layer.
We're working on it ... can't quit my day job, you know ... :)
--Matt
-
To
Andi Kleen wrote:
>I think using dprobes for collecting information is ok, but when you want
>to do actual actions with it (not only using it as a debugger) IMHO it
>is better to patch and recompile the kernel.
I absolutely agree. The only time I ever used this capability was to modify
a
On Mon, Nov 13, 2000 at 11:38:23AM +0100, Andi Kleen wrote:
> notifier lists would be sufficient because dprobes does not hook into any
> performance critical paths.
Current dprobes patch adds branches in the the main page fault handler,
device_not_available exception at least. Those are
On Sun, Nov 12, 2000 at 11:27:26PM +, [EMAIL PROTECTED] wrote:
>
>
>
> Andi Kleen wrote:
> > It will just help some people who have a unrational aversion against
> kernel
> >recompiles and believe in vendor blessed binaries.
>
>
> An interesting remark Andi, especially in the light of
[EMAIL PROTECTED] wrote:
>
>Date: Fri, 10 Nov 2000 19:29:26 -0800
>From: "Matt D. Robinson" <[EMAIL PROTECTED]>
>
>We're planning to isolate the write functions as much as possible.
>In the past, we've been bitten by this whole concept of Linux "raw I/O".
>When I was at SGI,
[EMAIL PROTECTED] wrote:
Date: Fri, 10 Nov 2000 19:29:26 -0800
From: "Matt D. Robinson" [EMAIL PROTECTED]
We're planning to isolate the write functions as much as possible.
In the past, we've been bitten by this whole concept of Linux "raw I/O".
When I was at SGI, we were
On Sun, Nov 12, 2000 at 11:27:26PM +, [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
It will just help some people who have a unrational aversion against
kernel
recompiles and believe in vendor blessed binaries.
An interesting remark Andi, especially in the light of your note to
On Mon, Nov 13, 2000 at 11:38:23AM +0100, Andi Kleen wrote:
notifier lists would be sufficient because dprobes does not hook into any
performance critical paths.
Current dprobes patch adds branches in the the main page fault handler,
device_not_available exception at least. Those are _very_
Andi Kleen wrote:
I think using dprobes for collecting information is ok, but when you want
to do actual actions with it (not only using it as a debugger) IMHO it
is better to patch and recompile the kernel.
I absolutely agree. The only time I ever used this capability was to modify
a
Alexander Viro wrote:
> It's not a good idea, it's an obvious fact. Oh, you mean forking the
tree?
Again I find your terminology at odds with mine; what do you mean by
forking the tree? I get the impression that it's a very restrictive notion
where any functional ehancement applied as a patch
Andi Kleen wrote:
> It will just help some people who have a unrational aversion against
kernel
>recompiles and believe in vendor blessed binaries.
An interesting remark Andi, especially in the light of your note to me
regarding your use of DProbes - i.e. you'd rather use DProbes to dump out
Andi Kleen wrote:
It will just help some people who have a unrational aversion against
kernel
recompiles and believe in vendor blessed binaries.
An interesting remark Andi, especially in the light of your note to me
regarding your use of DProbes - i.e. you'd rather use DProbes to dump out
Alexander Viro wrote:
It's not a good idea, it's an obvious fact. Oh, you mean forking the
tree?
Again I find your terminology at odds with mine; what do you mean by
forking the tree? I get the impression that it's a very restrictive notion
where any functional ehancement applied as a patch
Lars Marowsky-Bree wrote:
> And I am still very fond of the idea of crash dumping to a network server ;-)
I second that. Serial can be slow, and has that pesky cable-length
limit...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On 2000-11-10T19:12:29,
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> said:
> Great! Are you thinking about putting the crash dumper and the raw
> write disk routines in a separate text section, so they can be located
> in pages which are write-protected from accidental modification in case
> some
Date: Fri, 10 Nov 2000 19:29:26 -0800
From: "Matt D. Robinson" <[EMAIL PROTECTED]>
We're planning to isolate the write functions as much as possible.
In the past, we've been bitten by this whole concept of Linux "raw I/O".
When I was at SGI, we were able to write to a block device
Date: Fri, 10 Nov 2000 19:29:26 -0800
From: "Matt D. Robinson" [EMAIL PROTECTED]
We're planning to isolate the write functions as much as possible.
In the past, we've been bitten by this whole concept of Linux "raw I/O".
When I was at SGI, we were able to write to a block device
On 2000-11-10T19:12:29,
"Theodore Y. Ts'o" [EMAIL PROTECTED] said:
Great! Are you thinking about putting the crash dumper and the raw
write disk routines in a separate text section, so they can be located
in pages which are write-protected from accidental modification in case
some kernel
On Fri, 10 Nov 2000 19:29:26 -0800,
"Matt D. Robinson" <[EMAIL PROTECTED]> wrote:
>We're removing lcrash from
>the kernel, putting it into its own RPM, and adding patches to the
>kernel for LKCD that build in crash dump functionality and make a new
>"Kernsyms" file so that we can dynamically
"Theodore Y. Ts'o" wrote:
>
>Date: Fri, 10 Nov 2000 10:36:31 -0800
>From: "Matt D. Robinson" <[EMAIL PROTECTED]>
>
>As soon as I finish writing raw write disk routines (not using kiobufs),
>we can _maybe_ get LKCD accepted one of these days, especially now that we
>don't
Date: Fri, 10 Nov 2000 10:36:31 -0800
From: "Matt D. Robinson" <[EMAIL PROTECTED]>
As soon as I finish writing raw write disk routines (not using kiobufs),
we can _maybe_ get LKCD accepted one of these days, especially now that we
don't have to build 'lcrash' against a kernel
PROTECTED]>
To: "Theodore Y. Ts'o" <[EMAIL PROTECTED]>
cc: Richard J Moore/UK/IBM@IBMGB, Paul Jakma <[EMAIL PROTECTED]>, Michael
Rothwell <[EMAIL PROTECTED]>, Christoph Rohland
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Generalised Ke
Matti,
>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..)
RAS = Reliabilty, Availability & Serviceability = those things that are are
not mainline to an OS but add the qualities
Christoph Rohland wrote:
>
> Hi Theodore,
>
> On Fri, 10 Nov 2000, Theodore Y. Ts'o wrote:
> > P.S. There are some such RAS features which I wouldn't be surprised
> > there being interest in having integrated into the kernel directly
> > post-2.4, with no need to put in "kernel hooks" for that
> Right. So what you're saying is that GKHI is adding complexity to the
> kernel to make it easier for peopel to put in non-standard patches which
> exposes non-standard interfaces which will lead to kernels not supported
> by the Linux Kernel Development Community. Right?
I don't think I
On Fri, Nov 10, 2000 at 11:24:28AM -0500, Theodore Y. Ts'o wrote:
> Right. So what you're saying is that GKHI is adding complexity to the
> kernel to make it easier for peopel to put in non-standard patches which
> exposes non-standard interfaces which will lead to kernels not supported
> by the
Hi Theodore,
On Fri, 10 Nov 2000, Theodore Y. Ts'o wrote:
> P.S. There are some such RAS features which I wouldn't be surprised
> there being interest in having integrated into the kernel directly
> post-2.4, with no need to put in "kernel hooks" for that particular
> feature. A good example
From: [EMAIL PROTECTED]
Date:Fri, 10 Nov 2000 11:41:09 +
It has the potential to to make patches easier to re-work for different
kernel versions, and to enable development maintence and fixing of the
patch to be done independently of a kernel build. And it also has the
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
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
On Fri, 10 Nov 2000, Michael Rothwell wrote:
> > Sorry. You don't "embed" the patch. You either get it accepted or not.
> > Or you fork the tree and then it's officially None Of My Problems(tm).
>
> Sounds like a good idea.
It's not a good idea, it's an obvious fact. Oh, you mean forking
how is that any different then a module? modules that are not included
with the kernel source are not guarenteed to work with any other kernel
version (including during the stable kernel series)
David Lang
On Fri, 10 Nov 2000, Alexander Viro wrote:
> On Fri, 10 Nov 2000 [EMAIL PROTECTED]
Alexander "see figure 1" Viro wrote:
> Sorry. You don't "embed" the patch. You either get it accepted or not.
> Or you fork the tree and then it's officially None Of My Problems(tm).
Sounds like a good idea.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, 10 Nov 2000 [EMAIL PROTECTED] wrote:
>
>
>
> > The problem with the hooks et.al. is very simple - they promote every
> > bloody implementation detail to exposed API.
>
> Surely not, having the kernel source does that. The alternative to the hook
> is embed a patch in the
> The problem with the hooks et.al. is very simple - they promote every
> bloody implementation detail to exposed API.
Surely not, having the kernel source does that. The alternative to the hook
is embed a patch in the kernel source. What proveds greater exposure to
internals: hooks of
> That being said, the real problem with the GKHI is that as Al said, it
> does expose internal kernel interfaces --- and the Linux kernel
> development community as a whole refuses to be bound by such interfaces,
> sometimes even during a stable kernel series.
I'm not sure that GKHI exposes
>> Why? I think the IBM GKHI code would be of tremendous value. It would
>
> And we already refuse to support those kernels - your point being?
>
> Making this "commonplace" is a nightmare. Go away with that.
How is so?
Richard Moore - RAS Project Lead - Linux Technology Centre
>> extensions using the GKHI would not be breaking the license agreement, I
>> don't think. There's lots of binary modules right now -- VMWare, Aureal
> sound card drivers, etc.
>
>All of which just cause large numbers of bugs to go in the bitbucket
because
>nobody can tell whose the problem
> Yes, and that's why I am opposing here: Technically you are right, but
> proposing that enterprise Linux should go this way is inviting binary
> only modules due to the lax handling of modules.
Not so sure it does. If a kernel module wants to make use of GKHI then it
will have to
1)
Alexander Viro wrote:
>
> On 9 Nov 2000, Mike Coleman wrote:
>
> > Alexander Viro <[EMAIL PROTECTED]> writes:
> > > 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
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.% of the hardware in the world isn't big
>> iron and never will be, so something approximating 99% of
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
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.% of the hardware in the world isn't big
iron and never will be, so something approximating 99% of the
effort
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
Alexander Viro wrote:
On 9 Nov 2000, Mike Coleman wrote:
Alexander Viro [EMAIL PROTECTED] 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
That being said, the real problem with the GKHI is that as Al said, it
does expose internal kernel interfaces --- and the Linux kernel
development community as a whole refuses to be bound by such interfaces,
sometimes even during a stable kernel series.
I'm not sure that GKHI exposes any
The problem with the hooks et.al. is very simple - they promote every
bloody implementation detail to exposed API.
Surely not, having the kernel source does that. The alternative to the hook
is embed a patch in the kernel source. What proveds greater exposure to
internals: hooks of
On Fri, 10 Nov 2000 [EMAIL PROTECTED] wrote:
The problem with the hooks et.al. is very simple - they promote every
bloody implementation detail to exposed API.
Surely not, having the kernel source does that. The alternative to the hook
is embed a patch in the kernel source.
Alexander "see figure 1" Viro wrote:
Sorry. You don't "embed" the patch. You either get it accepted or not.
Or you fork the tree and then it's officially None Of My Problems(tm).
Sounds like a good idea.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
how is that any different then a module? modules that are not included
with the kernel source are not guarenteed to work with any other kernel
version (including during the stable kernel series)
David Lang
On Fri, 10 Nov 2000, Alexander Viro wrote:
On Fri, 10 Nov 2000 [EMAIL PROTECTED] wrote:
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
From: [EMAIL PROTECTED]
Date:Fri, 10 Nov 2000 11:41:09 +
It has the potential to to make patches easier to re-work for different
kernel versions, and to enable development maintence and fixing of the
patch to be done independently of a kernel build. And it also has the
Hi Theodore,
On Fri, 10 Nov 2000, Theodore Y. Ts'o wrote:
P.S. There are some such RAS features which I wouldn't be surprised
there being interest in having integrated into the kernel directly
post-2.4, with no need to put in "kernel hooks" for that particular
feature. A good example of
Right. So what you're saying is that GKHI is adding complexity to the
kernel to make it easier for peopel to put in non-standard patches which
exposes non-standard interfaces which will lead to kernels not supported
by the Linux Kernel Development Community. Right?
I don't think I
Christoph Rohland wrote:
Hi Theodore,
On Fri, 10 Nov 2000, Theodore Y. Ts'o wrote:
P.S. There are some such RAS features which I wouldn't be surprised
there being interest in having integrated into the kernel directly
post-2.4, with no need to put in "kernel hooks" for that
]
To: "Theodore Y. Ts'o" [EMAIL PROTECTED]
cc: Richard J Moore/UK/IBM@IBMGB, Paul Jakma [EMAIL PROTECTED], Michael
Rothwell [EMAIL PROTECTED], Christoph Rohland
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Fri, Nov 10, 200
Matti,
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..)
RAS = Reliabilty, Availability Serviceability = those things that are are
not mainline to an OS but add the qualities named
Date: Fri, 10 Nov 2000 10:36:31 -0800
From: "Matt D. Robinson" [EMAIL PROTECTED]
As soon as I finish writing raw write disk routines (not using kiobufs),
we can _maybe_ get LKCD accepted one of these days, especially now that we
don't have to build 'lcrash' against a kernel
"Theodore Y. Ts'o" wrote:
Date: Fri, 10 Nov 2000 10:36:31 -0800
From: "Matt D. Robinson" [EMAIL PROTECTED]
As soon as I finish writing raw write disk routines (not using kiobufs),
we can _maybe_ get LKCD accepted one of these days, especially now that we
don't have to
On Fri, 10 Nov 2000 19:29:26 -0800,
"Matt D. Robinson" [EMAIL PROTECTED] wrote:
We're removing lcrash from
the kernel, putting it into its own RPM, and adding patches to the
kernel for LKCD that build in crash dump functionality and make a new
"Kernsyms" file so that we can dynamically read the
Date: Thu, 9 Nov 2000 14:26:33 + (GMT)
From: Alan Cox <[EMAIL PROTECTED]>
> Actually, he's been quite specific. It's ok to have binary modules as
> long as they conform to the interface defined in /proc/ksyms.
What is completely unclear is if he has the authority to say
On 9 Nov 2000, Mike Coleman wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
> > 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?
>
>
>
Alexander Viro <[EMAIL PROTECTED]> writes:
> 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?
*Hello*? GNU gcc? GNU emacs? Way below zero?
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.% 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,
Alan Cox wrote:
>
> > Actually, he's been quite specific. It's ok to have binary modules as
> > long as they conform to the interface defined in /proc/ksyms.
>
> What is completely unclear is if he has the authority to say that given that
> there is code from other people including the FSF
Date:Wed, 08 Nov 2000 16:35:33 -0500
From: Michael Rothwell <[EMAIL PROTECTED]>
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
> Actually, he's been quite specific. It's ok to have binary modules as
> long as they conform to the interface defined in /proc/ksyms.
What is completely unclear is if he has the authority to say that given that
there is code from other people including the FSF merged into the tree.
I've
Date:Thu, 09 Nov 2000 08:43:14 -0500
From: Michael Rothwell <[EMAIL PROTECTED]>
And how would a hypothetical Advanced Linux Kernel Project be different?
Set aside the GKHI and the issue of binary-only hook modules; how would
an "enterprise" fork be any different than RT or
Date:Thu, 9 Nov 2000 13:39:04 + (GMT)
From: Paul Jakma <[EMAIL PROTECTED]>
I actually think Linus has been too loose/vague on modules. The
official COPYING txt file in the tree contains an exception on linking
to the kernel using syscalls from linus and the GPL.
On Thu, 9 Nov 2000, Paul Jakma wrote:
> On Thu, 9 Nov 2000, Michael Rothwell wrote:
>
> > Well, then, problem solved.
> >
>
> :)
>
> > > afaik linus allows binary modules in most cases.
> >
> > And since an "Advanced Linux Kernel Project" wouldn't be a Linus kernel,
> > what then? Would
Larry McVoy <[EMAIL PROTECTED]>:
> 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
Alan Cox wrote:
> RTLinux is hardly a fork. UcLinux is a fork, it has its own mailing list, web
> site and everything. Post 2.4 I'm still very interested in spending time merging
> the 2.4 uc and the main tree. I think it can be done and they are doing it in
> a way that leads logically to this.
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=Google+Search
->
http://spiffy.cso.uiuc.edu/~kline/Stuff/see-figure-1.html
->
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...
>
>
On Thu, 9 Nov 2000, Michael Rothwell wrote:
> Well, then, problem solved.
>
:)
> > afaik linus allows binary modules in most cases.
>
> And since an "Advanced Linux Kernel Project" wouldn't be a Linus kernel,
> what then? Would they have the same discretion as Linus? Would Linus'
> exception
> > Making this "commonplace" is a nightmare. Go away with that.
>
> It would be a third major fork (AFAIK), not a first, and not a
> nightmare. Are RTLinux and uclinux nightmares? How much do they impact
> your life?
RTLinux is hardly a fork. UcLinux is a fork, it has its own mailing list, web
> reason to hamstring their efforts because of the possibility of binary
> modules. The GPL allows that, right? So any developer of binary-only
Its not clear the GPL does allow it.
> extensions using the GKHI would not be breaking the license agreement, I
> don't think. There's lots of binary
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...
>
>
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
Paul Jakma wrote:
>
> On Thu, 9 Nov 2000, Michael Rothwell wrote:
>
> > Why? I think the IBM GKHI code would be of tremendous value. It would
> > make the kernel much more flexible, and for users, much more friendly.
> > No more patch-and-recompile to add a filesystem or whatever. There's no
>
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
On Thu, 9 Nov 2000, Michael Rothwell wrote:
> Why? I think the IBM GKHI code would be of tremendous value. It would
> make the kernel much more flexible, and for users, much more friendly.
> No more patch-and-recompile to add a filesystem or whatever. There's no
> reason to hamstring their
Lars Marowsky-Bree wrote:
> And we already refuse to support those kernels - your point being?
Who says you would support theirs? My point is, forks have been made in
the past and are useful for the people that use them, and prevent
"pollution" of the common kernel with hghly specialized
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
On 2000-11-09T07:20:27,
Michael Rothwell <[EMAIL PROTECTED]> 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
>
On 2000-11-09T07:25:52,
Michael Rothwell <[EMAIL PROTECTED]> said:
> Why? I think the IBM GKHI code would be of tremendous value. It would
> make the kernel much more flexible, and for users, much more friendly.
> No more patch-and-recompile to add a filesystem or whatever. There's no
>
Christoph Rohland wrote:
> If we really need a special enterprise tree lets do
> it without module tricks.
Why? I think the IBM GKHI code would be of tremendous value. It would
make the kernel much more flexible, and for users, much more friendly.
No more patch-and-recompile to add a filesystem
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
Hi Richard,
On Thu, 9 Nov 2000, richardj moore wrote:
> Let be clear about one thing: the GKHI make no statement about
> enabling proprietary extensions and that's a common
> misconception. GKHI is intended to make optional facilities easier
> to co-install and change. We designed it for
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
09/11/2000 07:44:11
Please respond to Christoph Rohland <[EMAIL PROTECTED]>
To: Michael Rothwell <[EMAIL PROTECTED]>
cc: Richard J Moore/UK/IBM@IBMGB, [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Hi Michael,
On Wed, 08 Nov 2000, Mich
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
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
/2000 07:44:11
Please respond to Christoph Rohland [EMAIL PROTECTED]
To: Michael Rothwell [EMAIL PROTECTED]
cc: Richard J Moore/UK/IBM@IBMGB, [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Hi Michael,
On Wed, 08 Nov 2000, Michael Rothwell wrote:
Sounds
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
1 - 100 of 137 matches
Mail list logo
