Richard Gooch wrote:
> David S. Miller writes:
> > Matt D. Robinson writes:
> > > > This allows people to make proprietary implementations of TCP under
> > > > Linux. And we don't want this just as we don't want to add a way to
> > > &g
"David S. Miller" wrote:
>
> La Monte H.P. Yarroll writes:
> > Matt D. Robinson writes:
> > > Is there any way to add in the capability to _replace_ TCP with
> > > your own, so you can use your own layer?
>
> ABSOLUTELY NOT!
>
> A
David S. Miller wrote:
La Monte H.P. Yarroll writes:
Matt D. Robinson writes:
Is there any way to add in the capability to _replace_ TCP with
your own, so you can use your own layer?
ABSOLUTELY NOT!
And I will never in my lifetime allow such a facility to be added
Richard Gooch wrote:
David S. Miller writes:
Matt D. Robinson writes:
This allows people to make proprietary implementations of TCP under
Linux. And we don't want this just as we don't want to add a way to
allow someone to do a proprietary Linux VM.
And if as Joe User I
"Eric W. Biederman" wrote:
>
> "Matt D. Robinson" <[EMAIL PROTECTED]> writes:
>
> > It looks like around 2.3.30 or so, someone added the call
> > disable_local_APIC() to smp_send_stop(). I'm not sure what the
> > intention was, but I'
Eric W. Biederman wrote:
Matt D. Robinson [EMAIL PROTECTED] writes:
It looks like around 2.3.30 or so, someone added the call
disable_local_APIC() to smp_send_stop(). I'm not sure what the
intention was, but I'm getting some strange behavior as a result
based on some code I'm
It looks like around 2.3.30 or so, someone added the call
disable_local_APIC() to smp_send_stop(). I'm not sure what the
intention was, but I'm getting some strange behavior as a result
based on some code I'm writing.
Basically, I'm doing the following ...
panic()
{
/* do
It looks like around 2.3.30 or so, someone added the call
disable_local_APIC() to smp_send_stop(). I'm not sure what the
intention was, but I'm getting some strange behavior as a result
based on some code I'm writing.
Basically, I'm doing the following ...
panic()
{
/* do
Werner Almesberger wrote:
>
> Matt D. Robinson wrote:
> > My feeling is we should splinter the kernel development for
> > different purposes (enterprise, UP, security, etc.). I'm sure
> > it isn't a popular view, but I feel it would allow faster progression
>
"Mike A. Harris" wrote:
> On Fri, 16 Feb 2001, Matt D. Robinson wrote:
>
> >The day the Linux kernel splinters into multiple, distinct efforts is the
> >day I'll believe the kernel is fully into progress over "preference". Right
> >now, Alan accepts
The day the Linux kernel splinters into multiple, distinct efforts is the
day I'll believe the kernel is fully into progress over "preference". Right
now, Alan accepts what he thinks should go into stable kernels, and Linus
accepts what he thinks should go into future kernels. I'm not saying
The day the Linux kernel splinters into multiple, distinct efforts is the
day I'll believe the kernel is fully into progress over "preference". Right
now, Alan accepts what he thinks should go into stable kernels, and Linus
accepts what he thinks should go into future kernels. I'm not saying
"Mike A. Harris" wrote:
On Fri, 16 Feb 2001, Matt D. Robinson wrote:
The day the Linux kernel splinters into multiple, distinct efforts is the
day I'll believe the kernel is fully into progress over "preference". Right
now, Alan accepts what he thinks should go
The latest LKCD (Linux Kernel Crash Dumps) patches/RPMs/etc. are
available for download for linux-2.4.{0,1} kernels. You can get
LKCD from:
http://oss.sgi.com/projects/lkcd/download/current/
Please E-mail [EMAIL PROTECTED] if you have any questions/problems.
Thanks.
--Matt
-
To
The latest LKCD (Linux Kernel Crash Dumps) patches/RPMs/etc. are
available for download for linux-2.4.{0,1} kernels. You can get
LKCD from:
http://oss.sgi.com/projects/lkcd/download/current/
Please E-mail [EMAIL PROTECTED] if you have any questions/problems.
Thanks.
--Matt
-
To
Andreas Dilger wrote:
>
> H. Peter Anvin writes:
> > We have:
> >
> >0x82 - Linux swap
> >0x83 - Linux filesystem
> >0x85 - Linux extended partition (yes, this one does matter!)
> >
> > There seems to be some value in having a different value for swap. It
> > lets an automatic
Andreas Dilger wrote:
H. Peter Anvin writes:
We have:
0x82 - Linux swap
0x83 - Linux filesystem
0x85 - Linux extended partition (yes, this one does matter!)
There seems to be some value in having a different value for swap. It
lets an automatic program find a
Werner Almesberger wrote:
>
> Alexander Viro wrote:
> > In the situation above they should have -I/include
> > in CFLAGS. Always had to. No links, no pain in ass, no interference with
> > userland compiles.
>
> As long as there's a standard location for "",
> this is fine. In most cases, the
Werner Almesberger wrote:
Alexander Viro wrote:
In the situation above they should have -Iwherever_the_tree_lives/include
in CFLAGS. Always had to. No links, no pain in ass, no interference with
userland compiles.
As long as there's a standard location for "wherever_the_tree_lives",
64738 wrote:
>
> Hi.
>
> I tried to find some information on whether the Linux Kernel Crash Dumps
> patches are going into 2.4 (or 2.5). Has there been any decision?
LKCD won't go into 2.4 (or 2.5) until I finish writing the direct
disk open/write functions that avoid going through the
[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
[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
"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 t
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
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
"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 th
I'd also want the default kernel build to create a symbol table namelist
object that gets installed into $(INSTALL_PATH) that correlates to the
kernel build. That way you build a symbol table mechanism for user-space
applications that want more complete kernel debug information, but do it
I'd also want the default kernel build to create a symbol table namelist
object that gets installed into $(INSTALL_PATH) that correlates to the
kernel build. That way you build a symbol table mechanism for user-space
applications that want more complete kernel debug information, but do it
Andrea Arcangeli wrote:
>
> Back in May I wrote a quite estensive documentation about all the
> possible/best ways to debug the Linux Kernel for a talk/tranining that I
> did in San Jose in May. I find now the time to clean it up and to upload
> since I think it could result useful to everybody
Andrea Arcangeli wrote:
Back in May I wrote a quite estensive documentation about all the
possible/best ways to debug the Linux Kernel for a talk/tranining that I
did in San Jose in May. I find now the time to clean it up and to upload
since I think it could result useful to everybody
Try LKCD.
--Matt
Gregory Maxwell wrote:
> If this is your primary argument for a kernel debugger, a 'crash dump tool
> with extra controls', then why not just cleanly implement a 'crash dump
> tool with extra controls'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Linus Torvalds wrote:
>
> On Wed, 6 Sep 2000, Alan Cox wrote:
> > >
> > > What would a debugger have done?
> >
> > Let the end user give me essential answers on what was happening at the failure
> > point. Think of it as a crash dump tool with extra controls
>
> Sure. I just don't see many
Try LKCD.
--Matt
Gregory Maxwell wrote:
If this is your primary argument for a kernel debugger, a 'crash dump tool
with extra controls', then why not just cleanly implement a 'crash dump
tool with extra controls'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Mike Coleman wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> > Even M$ doesn't require that I give proprietary information away.
> > If Linux wants to become the new standard for the computing industry,
> > GPL or whatever can't claim any ownership of the work a company
> > has done
I agree with Simon here. I'd personally like to see some form of
GNU GPL Loadable Module Compliance Standard for all loadable modules.
It isn't enough to go with the loose interpretation of the GNU GPL as
it applies to inclusion of header files, system call interfaces,
re-defined function
35 matches
Mail list logo
