Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
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 don't want Linux TCP, but Joe's TCP, they can't > > > do that (in a supportable way)? Are you saying Linux is, "do it my > > > way, or it's the highway"? > > Pardon my cynicism, but this reads more like "I'm an ACME Inc. and I > want to sell a proprietary TCP stack for Linux, please change Linux to > make this possible/easy". I doubt there are many Joe Users out there > who want to replace their TCP stack. I bet they would be much happier > to see patches go in which improve the performance of the generic > kernel. Performance Improvements != Innovation. If the maintainers of the Linux kernel only want evolution, not revolution, then that's fine, but it should be a bit more clear to everyone. Let's say someone wanted to come in and completely restructure devfs. And let's say 75% of the people out there loved it, but you didn't. Are you willing to stand in the way of allowing the new code to come into the kernel for sake of your exclusive opinion? And if you are willing to promote the changes, what does the community say if they don't like it? And is this thought process consistent among all maintainers? Mr. Yarroll has a great patch, one that offers some help to all kinds of developers. I worry now that it'll either not be accepted or it'll end up changing enough that developers using it will have a hard time taking advantage of its benefits. > But I'm sure there are plenty of ACME Inc.'s out there who would love > to sell a replacement TCP stack. And suck users down a proprietary > solution path. But I don't see why the Linux community should help the > ACME's of this world. And Linux is doing very nicely in the corporate > world, so we needn't to lose any sleep over what our current policies > do for our acceptance levels. > > If it bothers you that Linux caters more the the users and less to the > vendors, then use another OS. We don't mind. The door is over there. > Please don't slam it on your way out. I'm sorry, I normally wouldn't respond, but there are so many points to make. I don't mean to make this into a OSS religious war, but I'm curious: 1) Why would you limit people's ability to use solutions that are not open source? I mean, you don't do it in user space, so why bother doing it in the kernel? Doesn't the eventual goal of opening up solutions to everyone also provide room for companies to make a profit, if it does nothing to hurt the kernel's eventual dominance over other kernels? And if not, why not? 2) Why won't Linux take FreeBSD OSL'd code into the kernel without also requiring a dual license which also allows for the GNU GPL? I mean, the FreeBSD license is OSL certified, right? Or is it so important to use GPL over other OSL's that you'd rather styme innovation for the sake of purity? 3) Why take the position that if you don't like it, go to some other OS? What if I like Linux? Does that mean I have to give up all thought of using Linux because I want a proprietary solution for one or two things? Doesn't that seem completely counterintuitive to being "open"? 4) Why are Linux kernel developers turning into a community of gatekeepers who are increasingly less "open" about changes to the product? Is it really these days only what Linus wants? By that I mean, does he really control the majority of changes, or just those things he has time to look at or really cares about? All those other tree components are now maintained, some loosely, some in a draconian fashion. If someone isn't flexible, how is innovation maintained? > > If Joe's TCP is opensource, they are more than welcome to publish > > such changes. > > Yep. And then we can all benefit. And if it's released under the FreeBSD OSL, it won't be placed into the Linux kernel (at least according to one rather important maintainer). So Linux users as a whole won't benefit. And that's a real shame. Just my opinion. I just get the feeling that some of the maintainers are taking a "I'd rather cut off my nose to spite my face" stand on their beliefs rather than considering how the Linux kernel can evolve to help everyone -- even those that want to make money. The kernel can allow for both, but they (meaning the maintainers) just choose not to permit it. Maybe they just want some more of those RedHat stock options ... > Regards, > > Richard See ya, --Ma
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
"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 to > the Linux kernel. Who's to say you will always own the stack in the Linux kernel, or have the right to make such a statement? > 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 don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, "do it my way, or it's the highway"? Seems rather Microsoft-ish of an attitude, if you ask me. I think this is EXACTLY the reason why you run into companies like Caldera and Microsoft saying that Linux stifles innovation. You say, "Oh, we allow you to do whatever you want", and when someone really does want to do that in a way that works for open source and for proprietary/high-security developers, you slam the door in their face. Quite a shame. Take it easy, --Matt > Later, > David S. Miller > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
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 to the Linux kernel. Who's to say you will always own the stack in the Linux kernel, or have the right to make such a statement? 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 don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, do it my way, or it's the highway? Seems rather Microsoft-ish of an attitude, if you ask me. I think this is EXACTLY the reason why you run into companies like Caldera and Microsoft saying that Linux stifles innovation. You say, Oh, we allow you to do whatever you want, and when someone really does want to do that in a way that works for open source and for proprietary/high-security developers, you slam the door in their face. Quite a shame. Take it easy, --Matt Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
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 don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, do it my way, or it's the highway? Pardon my cynicism, but this reads more like I'm an ACME Inc. and I want to sell a proprietary TCP stack for Linux, please change Linux to make this possible/easy. I doubt there are many Joe Users out there who want to replace their TCP stack. I bet they would be much happier to see patches go in which improve the performance of the generic kernel. Performance Improvements != Innovation. If the maintainers of the Linux kernel only want evolution, not revolution, then that's fine, but it should be a bit more clear to everyone. Let's say someone wanted to come in and completely restructure devfs. And let's say 75% of the people out there loved it, but you didn't. Are you willing to stand in the way of allowing the new code to come into the kernel for sake of your exclusive opinion? And if you are willing to promote the changes, what does the community say if they don't like it? And is this thought process consistent among all maintainers? Mr. Yarroll has a great patch, one that offers some help to all kinds of developers. I worry now that it'll either not be accepted or it'll end up changing enough that developers using it will have a hard time taking advantage of its benefits. But I'm sure there are plenty of ACME Inc.'s out there who would love to sell a replacement TCP stack. And suck users down a proprietary solution path. But I don't see why the Linux community should help the ACME's of this world. And Linux is doing very nicely in the corporate world, so we needn't to lose any sleep over what our current policies do for our acceptance levels. If it bothers you that Linux caters more the the users and less to the vendors, then use another OS. We don't mind. The door is over there. Please don't slam it on your way out. I'm sorry, I normally wouldn't respond, but there are so many points to make. I don't mean to make this into a OSS religious war, but I'm curious: 1) Why would you limit people's ability to use solutions that are not open source? I mean, you don't do it in user space, so why bother doing it in the kernel? Doesn't the eventual goal of opening up solutions to everyone also provide room for companies to make a profit, if it does nothing to hurt the kernel's eventual dominance over other kernels? And if not, why not? 2) Why won't Linux take FreeBSD OSL'd code into the kernel without also requiring a dual license which also allows for the GNU GPL? I mean, the FreeBSD license is OSL certified, right? Or is it so important to use GPL over other OSL's that you'd rather styme innovation for the sake of purity? 3) Why take the position that if you don't like it, go to some other OS? What if I like Linux? Does that mean I have to give up all thought of using Linux because I want a proprietary solution for one or two things? Doesn't that seem completely counterintuitive to being open? 4) Why are Linux kernel developers turning into a community of gatekeepers who are increasingly less open about changes to the product? Is it really these days only what Linus wants? By that I mean, does he really control the majority of changes, or just those things he has time to look at or really cares about? All those other tree components are now maintained, some loosely, some in a draconian fashion. If someone isn't flexible, how is innovation maintained? If Joe's TCP is opensource, they are more than welcome to publish such changes. Yep. And then we can all benefit. And if it's released under the FreeBSD OSL, it won't be placed into the Linux kernel (at least according to one rather important maintainer). So Linux users as a whole won't benefit. And that's a real shame. Just my opinion. I just get the feeling that some of the maintainers are taking a I'd rather cut off my nose to spite my face stand on their beliefs rather than considering how the Linux kernel can evolve to help everyone -- even those that want to make money. The kernel can allow for both, but they (meaning the maintainers) just choose not to permit it. Maybe they just want some more of those RedHat stock options ... Regards, Richard See ya, --Matt P.S. I guess the next thing on the list for the Linux kernel is to create WHQL-like process for drivers before the code can end up in newer kernel revisions. Then I'll really know things have gone into the toilet. - To unsubscribe from this list
Re: smp_send_stop() and disable_local_APIC()
"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 writing.
> >
> > Basically, I'm doing the following ...
> >
> > panic()
> > {
> > /* do whatever you want, notifier list, etc. */
> > smp_send_stop();
> > write_system_memory();
> > /* then do whatever */
> > }
> >
> > write_system_memory() does a write of all system memory pages to some
> > block device. It uses kiobufs as the way to get the pages to disk,
> > doing brw_kiovec() on those pages (using either the IDE or SCSI
> > driver to write the data).
>
> IDE being less likely to hang than SCSI as it tends to use legacy isa
> interrupt lines.
Actually, we see the problem more with IDE than SCSI, but that's
neither here nor there.
> > The wierd behavior I see is that sometimes, smp_send_stop()
> > being called causes the system to hang up (not every time).
>
> Doing event driver i/o after disabling the interrupt controller
> hmm, I wonder why...
It's an SMP (and only when your system crashes on a CPU other
than 0) problem. I did some more checking of this to verify the
specifics of the behavior. Thanks for the sarcasm, though. :)
> > If we don't call smp_send_stop() on those systems, everything works fine.
> > This looks to be directly caused by the disabling of the APIC, which
> > we may need to dump pages to local disk. This only applies to some
> > people's systems -- not everyone displays the same behavior.
> >
> > I'm sure it's good to disable the APIC, but there's no clean way to
> > wait on disabling the APIC until after I'm done writing pages out.
> >
> > My questions are:
> >
> > 1) Why was disable_local_APIC() added to stop_this_cpu()
> >and smp_send_stop()? Completeness?
> >
> > 2) Is there a better way around this to disable all the
> >other CPUs without disabling the APIC?
> >
>
> I don't know what a good way is, since there is a kernel panic it
> should only be something truly fatal. Given that reusing anything
> that hasn't been designed to run in that situation is playing with
> fire.
Someone's sent me a suggestion as to how to get around this issue.
It goes back to turning off the disable_local_APIC() behavior for
one (if I'm writing pages out), but secondly to avoid doing any
TLB flushing of CPUs that are stopped.
The problem is, on SMP configurations where one CPU's
task causes a panic() condition to another CPU's task (let's say
they are playing with the same list of structures in the kernel),
I need to stop all CPUs except the one panic()ing, and let him
be responsible for dumping system memory, so I can at least try
to figure out what the other CPU's task did to cause the problem.
A hack way around this is to stop job scheduling, but it doesn't
help if you want to catch the state of the task that caused the
problem on another CPU just after it happens. Secondly, because there
is no disk driver to dump raw to disk (I've written one, but
not for SCSI -- only for IDE), you require interrupts and must
use the current block driver. Sure, brw_kiovec() is nice, but it
isn't raw I/O without kernel interrupts.
All I wanted was clarification as to why it was added in the first
place, and whether there was a better way around the scenario.
I think Ingo added the code, but I never heard back from him.
Thanks for the response.
> Eric
--Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: smp_send_stop() and disable_local_APIC()
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 writing.
Basically, I'm doing the following ...
panic()
{
/* do whatever you want, notifier list, etc. */
smp_send_stop();
write_system_memory();
/* then do whatever */
}
write_system_memory() does a write of all system memory pages to some
block device. It uses kiobufs as the way to get the pages to disk,
doing brw_kiovec() on those pages (using either the IDE or SCSI
driver to write the data).
IDE being less likely to hang than SCSI as it tends to use legacy isa
interrupt lines.
Actually, we see the problem more with IDE than SCSI, but that's
neither here nor there.
The wierd behavior I see is that sometimes, smp_send_stop()
being called causes the system to hang up (not every time).
Doing event driver i/o after disabling the interrupt controller
hmm, I wonder why...
It's an SMP (and only when your system crashes on a CPU other
than 0) problem. I did some more checking of this to verify the
specifics of the behavior. Thanks for the sarcasm, though. :)
If we don't call smp_send_stop() on those systems, everything works fine.
This looks to be directly caused by the disabling of the APIC, which
we may need to dump pages to local disk. This only applies to some
people's systems -- not everyone displays the same behavior.
I'm sure it's good to disable the APIC, but there's no clean way to
wait on disabling the APIC until after I'm done writing pages out.
My questions are:
1) Why was disable_local_APIC() added to stop_this_cpu()
and smp_send_stop()? Completeness?
2) Is there a better way around this to disable all the
other CPUs without disabling the APIC?
I don't know what a good way is, since there is a kernel panic it
should only be something truly fatal. Given that reusing anything
that hasn't been designed to run in that situation is playing with
fire.
Someone's sent me a suggestion as to how to get around this issue.
It goes back to turning off the disable_local_APIC() behavior for
one (if I'm writing pages out), but secondly to avoid doing any
TLB flushing of CPUs that are stopped.
The problem is, on SMP configurations where one CPU's
task causes a panic() condition to another CPU's task (let's say
they are playing with the same list of structures in the kernel),
I need to stop all CPUs except the one panic()ing, and let him
be responsible for dumping system memory, so I can at least try
to figure out what the other CPU's task did to cause the problem.
A hack way around this is to stop job scheduling, but it doesn't
help if you want to catch the state of the task that caused the
problem on another CPU just after it happens. Secondly, because there
is no disk driver to dump raw to disk (I've written one, but
not for SCSI -- only for IDE), you require interrupts and must
use the current block driver. Sure, brw_kiovec() is nice, but it
isn't raw I/O without kernel interrupts.
All I wanted was clarification as to why it was added in the first
place, and whether there was a better way around the scenario.
I think Ingo added the code, but I never heard back from him.
Thanks for the response.
Eric
--Matt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
smp_send_stop() and disable_local_APIC()
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 whatever you want, notifier list, etc. */
smp_send_stop();
write_system_memory();
/* then do whatever */
}
write_system_memory() does a write of all system memory pages to some
block device. It uses kiobufs as the way to get the pages to disk,
doing brw_kiovec() on those pages (using either the IDE or SCSI
driver to write the data).
The wierd behavior I see is that sometimes, smp_send_stop()
being called causes the system to hang up (not every time). If
we don't call smp_send_stop() on those systems, everything works fine.
This looks to be directly caused by the disabling of the APIC, which
we may need to dump pages to local disk. This only applies to some
people's systems -- not everyone displays the same behavior.
I'm sure it's good to disable the APIC, but there's no clean way to
wait on disabling the APIC until after I'm done writing pages out.
My questions are:
1) Why was disable_local_APIC() added to stop_this_cpu()
and smp_send_stop()? Completeness?
2) Is there a better way around this to disable all the
other CPUs without disabling the APIC?
Thanks for any feedback.
--Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
smp_send_stop() and disable_local_APIC()
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 whatever you want, notifier list, etc. */
smp_send_stop();
write_system_memory();
/* then do whatever */
}
write_system_memory() does a write of all system memory pages to some
block device. It uses kiobufs as the way to get the pages to disk,
doing brw_kiovec() on those pages (using either the IDE or SCSI
driver to write the data).
The wierd behavior I see is that sometimes, smp_send_stop()
being called causes the system to hang up (not every time). If
we don't call smp_send_stop() on those systems, everything works fine.
This looks to be directly caused by the disabling of the APIC, which
we may need to dump pages to local disk. This only applies to some
people's systems -- not everyone displays the same behavior.
I'm sure it's good to disable the APIC, but there's no clean way to
wait on disabling the APIC until after I'm done writing pages out.
My questions are:
1) Why was disable_local_APIC() added to stop_this_cpu()
and smp_send_stop()? Completeness?
2) Is there a better way around this to disable all the
other CPUs without disabling the APIC?
Thanks for any feedback.
--Matt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
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 > > of kernel functionality and features in the long run. > > "enterprise" XOR security ? I think you understand the problem with > your approach well ;-) Actually I do. Perhaps I should define enterprise as "big iron". In that way, enterprise kernels would be far more innovative than a secure kernel (which cares less about performance gains and large features and more about just being "secure"). Unless you meant something else and I'm misinterpreting what you've stated. :) > Linux scales well from PDAs to large clusters. This is quite an > achievement. Other operating systems are not able to match this. > So why do you think that Linux should try to mimic their flaws ? > Out of pity ? I always considered SGI's kernels, from the low-end system up to the large server configurations, to scale well. Certainly it didn't work on PDAs. :) If you consider it a flaw for vendors to be able to create their own Linux kernels based on optimizations for their hardware and their customers, then that's a horrible perspective on overall open source progression. In fact, I think if some of these vendors created their own kernel trees, it would inevitably lead to inclusion of the best features into the primary kernel tree. Where's the harm in that? > BTW, parallel development does happen all the time. The point of > convergence in a single "mainstream" kernel is that you benefit > from all the work that's been going on while you did the stuff > you care most about. Agreed. It's great to have a "primary" kernel. I'd like to see more splintered kernels (not smaller project efforts), that's all. And I don't think that convergence happens quickly or efficiently enough, despite all the great work Linus and Alan do. > - Werner (having pity with the hungry looking trolls) --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
"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 into stable kernels, and Linus > >accepts what he thinks should go into future kernels. I'm not saying they > >aren't doing the right things, or that the system doesn't work, but it's > >hardly what I would call a progressive movement. It's simply long, > >drawn-out evolution at best. > > > >I'm surprised the major vendors haven't created their own consortium > >by now to create a Linux kernel they think is best suited for their own > >hardware. But then again, they probably still spend all their time worrying > >about whether their efforts will be "accepted" into the mainstream Linux > >kernel. Now _that's_ what I consider to be stifling innovation and > >progression. > > > >Kind of off-topic, but whatever ... > > Basically it boils down to this.. By continuing this thread here, > I'm preaching to the choir, and I'd rather not waste my time on > those with no clue of the open source movement. The other > alterative is to stick up for open source, and debate you until > I'm blue in the face - and you wont change your mind anyways, > and considering you're the minority here.. who cares? > > Thread == dead. Mike, next time, read someone's post before responding, okay? If you think I don't care about open source, perhaps you weren't paying enough attention. I'd like to see open source evolve even faster than it does now. If you somehow missed that, then go back and read what I wrote again. And I'm sure you can find much more positive ways to defend open source than responding in the way you just did -- your tone projects the kind of animosity that causes these closed vs. open source debates in the first place. 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 of kernel functionality and features in the long run. And that's simply a different view than you have. It's certainly not one that is against the open source movement (as you've implied). --Matt (http://oss.sgi.com/projects/lkcd) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
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 they aren't doing the right things, or that the system doesn't work, but it's hardly what I would call a progressive movement. It's simply long, drawn-out evolution at best. I'm surprised the major vendors haven't created their own consortium by now to create a Linux kernel they think is best suited for their own hardware. But then again, they probably still spend all their time worrying about whether their efforts will be "accepted" into the mainstream Linux kernel. Now _that's_ what I consider to be stifling innovation and progression. Kind of off-topic, but whatever ... --Matt "Mike A. Harris" wrote: > On Fri, 16 Feb 2001, Dennis wrote: > > >The biggest thing that the linux community does to stifle innovation is to > >bash commercial vendors trying to make a profit by whining endlessly about > >"sourceless" distributions and recommending "open-source" solutions even > >when they are wholly inferior. You're only hurting yourselves in the long > >run. In that respect MS is correct, because those with the dollars to > >innovate will stay away. > > Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell, > SGI, and a handful of other _major_ computer companies that now > realize the importance of open source. > > Seriously, get a copy of Eric S. Raymond's book, "The Cathedral > and the Bazaar" (or view it online at http://www.opensource.org), > and read through it. It is very well written and covers all > aspects of what you are fearing - in a positive way. > > Linux is one of the most stable operating systems ever written. > That's not just advocacy, that is fact. Drivers marked > experimental are not just experimental - some are, but a lot are > not, they just have not had anyone send in loud positive > feedback, and so the maintainers left them that way. > > If you think the various crud commercial OS's out there are > stable and have no experimental code in them, and that drivers do > not crash or have bugs, you haven't been computing for long. > > At any rate, nobody has a gun to your head - go use something > else that works for you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
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 they aren't doing the right things, or that the system doesn't work, but it's hardly what I would call a progressive movement. It's simply long, drawn-out evolution at best. I'm surprised the major vendors haven't created their own consortium by now to create a Linux kernel they think is best suited for their own hardware. But then again, they probably still spend all their time worrying about whether their efforts will be "accepted" into the mainstream Linux kernel. Now _that's_ what I consider to be stifling innovation and progression. Kind of off-topic, but whatever ... --Matt "Mike A. Harris" wrote: On Fri, 16 Feb 2001, Dennis wrote: The biggest thing that the linux community does to stifle innovation is to bash commercial vendors trying to make a profit by whining endlessly about "sourceless" distributions and recommending "open-source" solutions even when they are wholly inferior. You're only hurting yourselves in the long run. In that respect MS is correct, because those with the dollars to innovate will stay away. Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell, SGI, and a handful of other _major_ computer companies that now realize the importance of open source. Seriously, get a copy of Eric S. Raymond's book, "The Cathedral and the Bazaar" (or view it online at http://www.opensource.org), and read through it. It is very well written and covers all aspects of what you are fearing - in a positive way. Linux is one of the most stable operating systems ever written. That's not just advocacy, that is fact. Drivers marked experimental are not just experimental - some are, but a lot are not, they just have not had anyone send in loud positive feedback, and so the maintainers left them that way. If you think the various crud commercial OS's out there are stable and have no experimental code in them, and that drivers do not crash or have bugs, you haven't been computing for long. At any rate, nobody has a gun to your head - go use something else that works for you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
"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 into stable kernels, and Linus accepts what he thinks should go into future kernels. I'm not saying they aren't doing the right things, or that the system doesn't work, but it's hardly what I would call a progressive movement. It's simply long, drawn-out evolution at best. I'm surprised the major vendors haven't created their own consortium by now to create a Linux kernel they think is best suited for their own hardware. But then again, they probably still spend all their time worrying about whether their efforts will be "accepted" into the mainstream Linux kernel. Now _that's_ what I consider to be stifling innovation and progression. Kind of off-topic, but whatever ... Basically it boils down to this.. By continuing this thread here, I'm preaching to the choir, and I'd rather not waste my time on those with no clue of the open source movement. The other alterative is to stick up for open source, and debate you until I'm blue in the face - and you wont change your mind anyways, and considering you're the minority here.. who cares? Thread == dead. Mike, next time, read someone's post before responding, okay? If you think I don't care about open source, perhaps you weren't paying enough attention. I'd like to see open source evolve even faster than it does now. If you somehow missed that, then go back and read what I wrote again. And I'm sure you can find much more positive ways to defend open source than responding in the way you just did -- your tone projects the kind of animosity that causes these closed vs. open source debates in the first place. 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 of kernel functionality and features in the long run. And that's simply a different view than you have. It's certainly not one that is against the open source movement (as you've implied). --Matt (http://oss.sgi.com/projects/lkcd) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] LKCD 3.1 For 2.4.{0,1} Available
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] LKCD 3.1 For 2.4.{0,1} Available
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Partition IDs in the New World TM
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 partition that does not contain data. > > What would be wrong with changing the kernel to skip the first page of > swap, and allowing us to put a signature there? This would be really > useful for systems that mount ext2 filesystems by LABEL or UUID. With > the exception of swap, you currently don't need to care about what disk > a filesystem is on. Of course, LVM also fixes this, but not everyone > runs LVM. LKCD starts writing a crash dump after the first page of the swap partition (if that is used as the dump partition), so I'd hate to see this implemented. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Partition IDs in the New World TM
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 partition that does not contain data. What would be wrong with changing the kernel to skip the first page of swap, and allowing us to put a signature there? This would be really useful for systems that mount ext2 filesystems by LABEL or UUID. With the exception of swap, you currently don't need to care about what disk a filesystem is on. Of course, LVM also fixes this, but not everyone runs LVM. LKCD starts writing a crash dump after the first page of the swap partition (if that is used as the dump partition), so I'd hate to see this implemented. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
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 tree one expects to find is "roughly > the kernel we're running". Actually, maybe a script to provide the > path would be even better (*). Such a script could also complain if > there's an obvious problem. I personally think the definition of an environment variable to point to a header file location is the right way to go. Same with tools -- that way I can say build with $(TOOLDIR), which pulls whatever tools that tree uses, and use $(INCDIR) as my kernel include files. Then you can build using whatever header files you want to use, using whatever compilers/linkers/whatever you want to. So: TOOLDIR=/src/gcctree INCDIR=/src/2.2.18 or: TOOLDIR=/src/egcstree INCDIR=/src/2.4.0-test12-custom Then a 'make' from my $(TOPDIR) builds everything with the tools in $(TOOLDIR) and uses -I$(INCDIR) for header files. It's a beautiful thing. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
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", this is fine. In most cases, the tree one expects to find is "roughly the kernel we're running". Actually, maybe a script to provide the path would be even better (*). Such a script could also complain if there's an obvious problem. I personally think the definition of an environment variable to point to a header file location is the right way to go. Same with tools -- that way I can say build with $(TOOLDIR), which pulls whatever tools that tree uses, and use $(INCDIR) as my kernel include files. Then you can build using whatever header files you want to use, using whatever compilers/linkers/whatever you want to. So: TOOLDIR=/src/gcctree INCDIR=/src/2.2.18 or: TOOLDIR=/src/egcstree INCDIR=/src/2.4.0-test12-custom Then a 'make' from my $(TOPDIR) builds everything with the tools in $(TOOLDIR) and uses -I$(INCDIR) for header files. It's a beautiful thing. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LKCD from SGI
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 standard IDE and SCSI drivers. I'm working on it. As far as work for 2.4 goes, we've got a version on SourceForge that works well (for i386 and 95% for ia64). As soon as the drivers are done, we'll hopefully get acceptance. --Matt P.S. Any way we can standardize 'make install' in the kernel? It's disturbing to have different install mechanisms per platform ... I can make the changes for a few platforms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
[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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
[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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
"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 build 'lcrash' against a kernel revision. I'm in the >middle of putting together raw IDE functions now -- see LKCD mailing >list for details if you're curious. > > 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 code goes wild? (Who me? Paranoid? :-) > > - Ted 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 directly through low-level driver functions that weren't inhibited by any locking, and that was after shutting down all processors and any other outstanding interrupts. For Linux, I had given up and stuck with the raw I/O interpretation of kiobufs, which is just flat out wrong to do for dumping purposes. Secondly, as Linus said to me a few weeks ago, he doesn't trust the current disk drivers to be able to reliably dump when a crash occurs. Don't even ask me to go into all the reasons kiobufs are wrong for crash dumping. Just read the code -- it'll be obvious enough. So I guess after a few months/years, we're finally at a point where we're saying, "Okay, forget all this, let's do this the right way, so we don't have these problems anymore." 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 symbol table of major parts of the kernel and give you memory dumps, stack traces, and even dump out entire structures dynamically. Then we'll have the right crash dump mechanism for everyone. It's time to get RAS moving for Linux. GKHI and LKCD are the first steps to get us there (IMHO). --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
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 particular > > feature. A good example of that would be kernel crash dumps. For > > all Linux houses which are doing support of customers remotely, > > being able to get a crash dump so that developers can investigate a > > problem remotely instead of having to fly a developer out to the > > customer site is invaluable. In fact, it might be considerd more > > valuable than the kernel debugger > > *Yes* :-) 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 revision. I'm in the middle of putting together raw IDE functions now -- see LKCD mailing list for details if you're curious. IMHO, GKHI is a good thing -- it would be great to see this used for ASSERT() cases (something you can turn on by 'insmod assert.o', which would then trigger assert conditionals throughout the kernel ...) I realize it would mean some bloat, and I doubt Linus would accept it, but it's a nifty concept for enterprise Linux servers (especially those that want quick answers to system crashes). --Matt > Greetings > Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
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 particular feature. A good example of that would be kernel crash dumps. For all Linux houses which are doing support of customers remotely, being able to get a crash dump so that developers can investigate a problem remotely instead of having to fly a developer out to the customer site is invaluable. In fact, it might be considerd more valuable than the kernel debugger *Yes* :-) 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 revision. I'm in the middle of putting together raw IDE functions now -- see LKCD mailing list for details if you're curious. IMHO, GKHI is a good thing -- it would be great to see this used for ASSERT() cases (something you can turn on by 'insmod assert.o', which would then trigger assert conditionals throughout the kernel ...) I realize it would mean some bloat, and I doubt Linus would accept it, but it's a nifty concept for enterprise Linux servers (especially those that want quick answers to system crashes). --Matt Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
"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 build 'lcrash' against a kernel revision. I'm in the
middle of putting together raw IDE functions now -- see LKCD mailing
list for details if you're curious.
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 code goes wild? (Who me? Paranoid? :-)
- Ted
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 directly
through low-level driver functions that weren't inhibited by any
locking, and that was after shutting down all processors and any
other outstanding interrupts. For Linux, I had given up and stuck
with the raw I/O interpretation of kiobufs, which is just flat out
wrong to do for dumping purposes. Secondly, as Linus said to me a
few weeks ago, he doesn't trust the current disk drivers to be able
to reliably dump when a crash occurs. Don't even ask me to go into
all the reasons kiobufs are wrong for crash dumping. Just read
the code -- it'll be obvious enough.
So I guess after a few months/years, we're finally at a point where
we're saying, "Okay, forget all this, let's do this the right way,
so we don't have these problems anymore." 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 symbol table of
major parts of the kernel and give you memory dumps, stack traces,
and even dump out entire structures dynamically. Then we'll have
the right crash dump mechanism for everyone.
It's time to get RAS moving for Linux. GKHI and LKCD are the first
steps to get us there (IMHO).
--Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux RAS
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 without bloating the kernel with all that gstabs data (which is duplicated many times over if you turn on -gstabs for an entire build). CONFIG_??* options are good to know about, but what really matters to me during debugging is how those CONFIG_??* settings actually change structure definitions. And the only way to really know that is to have the gstabs data outlining what is in the kernel. How does that sound? --Matt Daniel Phillips wrote: > > Keith Owens wrote: > > * Standardize on tracking the System.map and .config with the kernel. > > There was a suggestion from Alan Cox that .config.gz be appended to > bzImage, after the part that gets loaded into memory, to which I added > the suggestion that System.map.gz also be appended. That about takes > care of all the descriptive kernel information that normally gets out > of sync. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux RAS
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 without bloating the kernel with all that gstabs data (which is duplicated many times over if you turn on -gstabs for an entire build). CONFIG_??* options are good to know about, but what really matters to me during debugging is how those CONFIG_??* settings actually change structure definitions. And the only way to really know that is to have the gstabs data outlining what is in the kernel. How does that sound? --Matt Daniel Phillips wrote: Keith Owens wrote: * Standardize on tracking the System.map and .config with the kernel. There was a suggestion from Alan Cox that .config.gz be appended to bzImage, after the part that gets loaded into memory, to which I added the suggestion that System.map.gz also be appended. That about takes care of all the descriptive kernel information that normally gets out of sync. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Debugging Documentation
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 dealing with kernel > developement. Good slides, Andrea. As far as LKCD is concerned, the latest versions for 2.2 dump to IDE as well as SCSI. You are correct as far as a dumb disk driver is concerned. Linus said that if he's to even _consider_ acceptance for LKCD in the kernel, we'd have to write our own dumb disk driver (which I'm in the process of doing). As soon as that's done, I'll post the changes to lkml. It would also be nice if Linus included the rest of sct's kiobuf changes into 2.4.X -- I mean, if they are spending all this time getting the rest of 2.4 to work, there's no reason not to include all the map_kernel_kiobuf() functionality. Some of us could use it (for LKCD ...) Same goes for Alan including the 2.2 changes. Just my 0.02. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Debugging Documentation
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 dealing with kernel developement. Good slides, Andrea. As far as LKCD is concerned, the latest versions for 2.2 dump to IDE as well as SCSI. You are correct as far as a dumb disk driver is concerned. Linus said that if he's to even _consider_ acceptance for LKCD in the kernel, we'd have to write our own dumb disk driver (which I'm in the process of doing). As soon as that's done, I'll post the changes to lkml. It would also be nice if Linus included the rest of sct's kiobuf changes into 2.4.X -- I mean, if they are spending all this time getting the rest of 2.4 to work, there's no reason not to include all the map_kernel_kiobuf() functionality. Some of us could use it (for LKCD ...) Same goes for Alan including the 2.2 changes. Just my 0.02. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
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 the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
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 end-users single-stepping through interrupt > handlers etc. > > But yes, there probably are a few. > > But problems that tend to be hard to debug are things that don't happen > all the time. Or require special timing to happen. And I don't think > you'll find that those are very easy to attach to with a debugger either. > So the guy at the debugger end has to be really good. > > Basically, I'd hate to depend on that. Then why not allow more complex post-failure analysis tools into the kernel as an option to debuggers? I agree that debugging should not act as a crutch for poor design up front, but at the same time, once you ship a product, you can't just ask the customer to "drop down into the debugger and give me a stack trace". If the system doesn't save the crash state for you, you might as well wave a magic wand over the system or pray that someone can read an Oops report. --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
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 the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
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 while using it. > > This almost seems like a troll. We who write GPLed software don't claim > ownership of other's work--we just specify the conditions under which the > others can use *our* work. What's wrong with that? Are you saying we should > just give our work away to you with compensation at all? You Communist! ;-) The GNU GPL is reasonable, but ... I would re-iterate the need for a clear definition as to how to add proprietary functionality into the kernel without violating the GNU GPL. The syntax and inclusion issues I mentioned in my previous post (along with I'm sure many others I left out) need to be addressed. The document doesn't need to be complex; it just has to be clear and concise enough for people to use as a guideline. Modules, drivers, system calls, include files, memory subsystem replacements, whatever. I can imagine many people are wary of extending the Linux kernel's functionality for fear that including their code might potentially lead to GNU GPL violation, inevitably leading to license, royalty or patent problems. And I'm sure most people want to do the right thing, but don't have the luxury of exploring every possible violation simply for the sake of a change or two in a kernel subsystem. This is particularly concerning for cross-license issues between people and/or companies. ... or am I way off-base here? --Matt (who writes GPL'd software) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
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 pointers for operations tables, inline functions, macro #defines, etc. Who is best qualified to judge whether something must be released as GPL or not? In addition, are there specific lawyers to speak with about kernel related GPL concerns before releasing a driver/module? --Matt Simon Richter wrote: > On Tue, 29 Aug 2000, Mike A. Harris wrote: > > #include'ing header files is not necessarily ok. Some headers > > include "inline functions" which is GPL code. Such inclusion in > > a module makes that module have to comply with GPL. > > I think this needs to be resolved ASAP. I don't have kernel sources handy, > so I cannot tell you whether the functions are actually worth being > protected (inb/outb doesn't belong to this group really), > >Simon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
