On Thu, September 8, 2005 4:18 pm, Bill Davidsen said:
> Is "maintain your own operating system" really better in your mind? Does
> that sound like a viable alternative?
No, that's a false choice. You folks just need to convince your
distribution to apply the patches you "need" or create your
Bill Davidsen wrote:
It appears that Linus has decided that there are not going to be any
such from kernel.org. That's a bad thing for users, to choose between
obsolete and stable, but it's his kernel.
Most users are best served to stick with the latest kernel *from their
distro*. It's
Horst von Brand wrote:
Just go and try to make some piece of ancient hardware work on some of the
propietary systems. /There/ you get no chance but "Oh, just change your
machine".
Is "maintain your own operating system" really better in your mind? Does
that sound like a viable alternative?
Willy Tarreau wrote:
Hi,
On Mon, Sep 05, 2005 at 12:12:56AM -0400, Sean wrote:
On Mon, September 5, 2005 12:03 am, Alex Davis said:
What if you don't have a choice? When someone comes to me with their
laptop
containing a built-in wireless card not natively supported by Linux, am I
supposed
Jan Kiszka wrote:
2005/9/7, Bill Davidsen <[EMAIL PROTECTED]>:
Is there a technical reason ("hard to implement" is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
Mike Galbraith wrote:
At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
You must have something more useful to work on, which would ADD value
to the kernel instead of breaking existing installations. Ripping out
petty stuff which works is a waste of your time and talent, please
find something
Mike Galbraith wrote:
At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
You must have something more useful to work on, which would ADD value
to the kernel instead of breaking existing installations. Ripping out
petty stuff which works is a waste of your time and talent, please
find something
Jan Kiszka wrote:
2005/9/7, Bill Davidsen [EMAIL PROTECTED]:
Is there a technical reason (hard to implement is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
Willy Tarreau wrote:
Hi,
On Mon, Sep 05, 2005 at 12:12:56AM -0400, Sean wrote:
On Mon, September 5, 2005 12:03 am, Alex Davis said:
What if you don't have a choice? When someone comes to me with their
laptop
containing a built-in wireless card not natively supported by Linux, am I
supposed
Horst von Brand wrote:
Just go and try to make some piece of ancient hardware work on some of the
propietary systems. /There/ you get no chance but Oh, just change your
machine.
Is maintain your own operating system really better in your mind? Does
that sound like a viable alternative?
Bill Davidsen wrote:
It appears that Linus has decided that there are not going to be any
such from kernel.org. That's a bad thing for users, to choose between
obsolete and stable, but it's his kernel.
Most users are best served to stick with the latest kernel *from their
distro*. It's
On Thu, September 8, 2005 4:18 pm, Bill Davidsen said:
Is maintain your own operating system really better in your mind? Does
that sound like a viable alternative?
No, that's a false choice. You folks just need to convince your
distribution to apply the patches you need or create your own
On Thu, 8 Sep 2005 01:25:20 +0200, Jan Kiszka <[EMAIL PROTECTED]> said:
Jan> Yes, I can provide some numbers around atheros devices (10-20%
Jan> speed-up). And yes, I can explain why ndiswrapper suffers from
Are you comparing atheros Windows driver with ndiswrapper or madwifi
with
--- Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Alex Davis wrote:
> >>Please don't tell me to "care for closed-source drivers".
> >
> > ndiswrapper is NOT closed source. And I'm not asking you to "care".
> >
> >
> >>I don't want the pain of debugging crashes on the machines which run
>
2005/9/7, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
>
> > Ndiswrapper is already slower than native drivers are, also due to
> > horribly implemented Windows drivers btw (the ndis model itself isn't
> > that bad, though).
>
> Do you have any evidence to back your claims? What
Jan Kiszka wrote:
> Ndiswrapper is already slower than native drivers are, also due to
> horribly implemented Windows drivers btw (the ndis model itself isn't
> that bad, though).
Do you have any evidence to back your claims? What tests did you do to say
that ndiswrapper is slower than native
2005/9/7, Daniel Phillips <[EMAIL PROTECTED]>:
> On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
> Ah, there's another issue: an interrupt can come in when esp is on the ndis
> stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
> this one is nasty.
>
Oh, you
2005/9/7, Daniel Phillips <[EMAIL PROTECTED]>:
> > > Is there a technical reason ("hard to implement" is a practical reason)
> > > why all stacks need to be the same size?
> >
> > Because of
> >
> > static inline struct thread_info *current_thread_info(void)
> > {
> > struct thread_info
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Regards,
Daniel
-
To unsubscribe from this list: send the line
> > Is there a technical reason ("hard to implement" is a practical reason)
> > why all stacks need to be the same size?
>
> Because of
>
> static inline struct thread_info *current_thread_info(void)
> {
> struct thread_info *ti;
> __asm__("andl %%esp,%0; ":"=r" (ti) : ""
At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
You must have something more useful to work on, which would ADD value to
the kernel instead of breaking existing installations. Ripping out petty
stuff which works is a waste of your time and talent, please find
something better to do.
Ahem.
2005/9/7, Bill Davidsen <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
> > 2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> >
> >>Jan Kiszka wrote:
> >>
> >>
> >>>The only way I see is to switch stacks back on ndiswrapper API entry.
> >>>But managing all those stacks correctly is challenging, as you
Jan Kiszka wrote:
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point.
Alex Davis wrote:
Please don't tell me to "care for closed-source drivers".
ndiswrapper is NOT closed source. And I'm not asking you to "care".
I don't want the pain of debugging crashes on the machines which run unknown
code
in kernel space.
I'm not asking you to debug crashes. I'm
Dave Jones wrote:
On Sun, Sep 04, 2005 at 10:13:10PM +0200, Bas Westerbaan wrote:
> > > Though 4K stacks are used a lot, they probably aren't used on all
> > > configurations yet. Other situations may arise where 8K stacks may be
> > > preferred. It is too early to kill 8K stacks imho.
> >
Dave Jones wrote:
On Sun, Sep 04, 2005 at 10:13:10PM +0200, Bas Westerbaan wrote:
Though 4K stacks are used a lot, they probably aren't used on all
configurations yet. Other situations may arise where 8K stacks may be
preferred. It is too early to kill 8K stacks imho.
Please
Alex Davis wrote:
Please don't tell me to care for closed-source drivers.
ndiswrapper is NOT closed source. And I'm not asking you to care.
I don't want the pain of debugging crashes on the machines which run unknown
code
in kernel space.
I'm not asking you to debug crashes. I'm simply
Jan Kiszka wrote:
2005/9/6, Giridhar Pemmasani [EMAIL PROTECTED]:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point.
2005/9/7, Bill Davidsen [EMAIL PROTECTED]:
Jan Kiszka wrote:
2005/9/6, Giridhar Pemmasani [EMAIL PROTECTED]:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to
At 12:38 PM 9/7/2005 -0400, Bill Davidsen wrote:
You must have something more useful to work on, which would ADD value to
the kernel instead of breaking existing installations. Ripping out petty
stuff which works is a waste of your time and talent, please find
something better to do.
Ahem.
Is there a technical reason (hard to implement is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
__asm__(andl %%esp,%0; :=r (ti) : (~(THREAD_SIZE - 1)));
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Regards,
Daniel
-
To unsubscribe from this list: send the line
2005/9/7, Daniel Phillips [EMAIL PROTECTED]:
Is there a technical reason (hard to implement is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
2005/9/7, Daniel Phillips [EMAIL PROTECTED]:
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Oh, you already
Jan Kiszka wrote:
Ndiswrapper is already slower than native drivers are, also due to
horribly implemented Windows drivers btw (the ndis model itself isn't
that bad, though).
Do you have any evidence to back your claims? What tests did you do to say
that ndiswrapper is slower than native
2005/9/7, Giridhar Pemmasani [EMAIL PROTECTED]:
Jan Kiszka wrote:
Ndiswrapper is already slower than native drivers are, also due to
horribly implemented Windows drivers btw (the ndis model itself isn't
that bad, though).
Do you have any evidence to back your claims? What tests did you
--- Bill Davidsen [EMAIL PROTECTED] wrote:
Alex Davis wrote:
Please don't tell me to care for closed-source drivers.
ndiswrapper is NOT closed source. And I'm not asking you to care.
I don't want the pain of debugging crashes on the machines which run
unknown code
in kernel
On Thu, 8 Sep 2005 01:25:20 +0200, Jan Kiszka [EMAIL PROTECTED] said:
Jan Yes, I can provide some numbers around atheros devices (10-20%
Jan speed-up). And yes, I can explain why ndiswrapper suffers from
Are you comparing atheros Windows driver with ndiswrapper or madwifi
with ndiswrapper?
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
> ...as long as ->task and ->previous_esp are initialized,
> staying on the bigger stack looks fine (previous_esp is apparently used
> only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else does: it isn't
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis stack. You save ESP of the kernel stack at the base of the ndis
> > stack. When the Windows code calls your api, you get the ndis
On Tue, 2005-09-06 at 21:59 -0400, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis
> > stack. You save ESP of the kernel stack at the base of the ndis stack.
> > When
> > the Windows code calls your api, you get
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
> Daniel> There are only two stacks involved, the normal kernel
> Daniel> stack and your new ndis stack. You save ESP of the kernel
> Daniel> stack at the base of the ndis stack. When the Windows
> Daniel> code calls your
On Tue, 2005-09-06 at 18:36 -0400, Daniel Phillips wrote:
> But then how would thread_info->task on the irq stack ever get initialized?
>
> My "what for" question was re why interrupt routines even need a valid
> current. I see one answer out there on the web: statistical profiling. Is
> that
On Tue, 6 Sep 2005 18:19:45 -0400, Daniel Phillips <[EMAIL PROTECTED]> said:
Daniel> There are only two stacks involved, the normal kernel stack
Daniel> and your new ndis stack. You save ESP of the kernel stack
Sadly, that is not the case: Some drivers, especially USB drivers,
create
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
> On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> > Andi, their stack will have to have a valid thread_info->task because
> > interrupts will use it. Out of interest, could you please explain what
> > for?
>
> No, with 4k
Daniel> There are only two stacks involved, the normal kernel
Daniel> stack and your new ndis stack. You save ESP of the kernel
Daniel> stack at the base of the ndis stack. When the Windows
Daniel> code calls your api, you get the ndis ESP, load the kernel
Daniel> ESP from
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> Andi, their stack will have to have a valid thread_info->task because
> interrupts will use it. Out of interest, could you please explain what
> for?
No, with 4k interrupts run on their own stack with their own thread_info
Or rather
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
On Tue, 6 Sep 2005, Jan Kiszka wrote:
> 2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
>> Jan Kiszka wrote:
>>
>>> The only way I see is to switch stacks back on ndiswrapper API entry.
>>> But managing all those stacks correctly is challenging, as you will
>>> likely not want to create a new
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Jan Kiszka wrote:
>
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging, as you will
> > likely not want to create a new stack on each switching point. Rather,
>
>
On Tue, Sep 06, 2005 at 02:42:02PM -0400, linux-os (Dick Johnson) wrote:
> I think
... and we have clear winner for the most incredible statement made on l-k.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Tue, 6 Sep 2005, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
>
>> The only way I see is to switch stacks back on ndiswrapper API entry.
>> But managing all those stacks correctly is challenging, as you will
>> likely not want to create a new stack on each switching point. Rather,
>
> This
Jan Kiszka wrote:
> The only way I see is to switch stacks back on ndiswrapper API entry.
> But managing all those stacks correctly is challenging, as you will
> likely not want to create a new stack on each switching point. Rather,
This is what I had in mind before I saw this thread here. I, in
2005/9/6, Giridhar Pemmasani <[EMAIL PROTECTED]>:
> Andi Kleen wrote:
>
> > AFAIK with interrupt stacks it shouldn't be a big issue to switch
> > to a private bigger stack. ndiswrapper just needs to have its own private
> > way to do "current" which accesses thread_info at the bottom of the
On Mon, Sep 05, 2005 at 12:26:41AM -0400, Dave Jones wrote:
> As someone who gets to read a lot of bug reports from end-users,
> this thing is far from perfect judging by the number of tainted
> oopses I've seen, and not all of them look like stack size issues.
It would make sense to use 4KB
El Tue, 06 Sep 2005 17:32:57 +1000,
Nick Piggin <[EMAIL PROTECTED]> escribió:
> Are there still good reasons to have such a thing?
Bigger block sizes was one of their features.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 04 Sep 2005 at 15:49:11 +0100, Alan Cox wrote:
> The question is whether ndiswrapper can do stack switching itself. Since
> as I understand it the NT stack is way more than 8K.
W2K usable kernel stack is about two pages. I'm not clear whether
this is
> Are there still good reasons to have such a thing?
I think so yes. It just doesn't make much sense to handle larger 64bit
setups with multiple GB of memory with 4K pages. While larger softpage
size will not increase TLB usage it will give you less cache use and in
general less cycles while
On Tue, 2005-09-06 at 09:13 +0200, Andi Kleen wrote:
> At some point we undoubtedly will need to increase it further,
> the logical point would be when Linux switches to larger softpage
> sizes.
Is this really a "when"?
Hugh and wli were both working on this and IIRC neither could
show enough
On Tuesday 06 September 2005 08:39, Denis Vlasenko wrote:
> I think one of the reasons is:
>
> "No matter how big stack is, there are always careless
> code which can overflow it. 4k, 8k, 64k (hypotetically),
> we still must keep stack size in mind when coding.
>
> So, since we already are
On Tuesday 06 September 2005 07:37, Andi Kleen wrote:
> Running with tight stack is just a fundamentally fragile configuration
> and will come back to bite you later. Even with 8k we regularly
> had overflows reported and with 4k it will be much worse.
I think one of the reasons is:
"No matter
On Tuesday 06 September 2005 07:37, Andi Kleen wrote:
Running with tight stack is just a fundamentally fragile configuration
and will come back to bite you later. Even with 8k we regularly
had overflows reported and with 4k it will be much worse.
I think one of the reasons is:
No matter how
On Tuesday 06 September 2005 08:39, Denis Vlasenko wrote:
I think one of the reasons is:
No matter how big stack is, there are always careless
code which can overflow it. 4k, 8k, 64k (hypotetically),
we still must keep stack size in mind when coding.
So, since we already are writing stack
On Tue, 2005-09-06 at 09:13 +0200, Andi Kleen wrote:
At some point we undoubtedly will need to increase it further,
the logical point would be when Linux switches to larger softpage
sizes.
Is this really a when?
Hugh and wli were both working on this and IIRC neither could
show enough
Are there still good reasons to have such a thing?
I think so yes. It just doesn't make much sense to handle larger 64bit
setups with multiple GB of memory with 4K pages. While larger softpage
size will not increase TLB usage it will give you less cache use and in
general less cycles while
In-Reply-To: [EMAIL PROTECTED]
On Sun, 04 Sep 2005 at 15:49:11 +0100, Alan Cox wrote:
The question is whether ndiswrapper can do stack switching itself. Since
as I understand it the NT stack is way more than 8K.
W2K usable kernel stack is about two pages. I'm not clear whether
this is
El Tue, 06 Sep 2005 17:32:57 +1000,
Nick Piggin [EMAIL PROTECTED] escribió:
Are there still good reasons to have such a thing?
Bigger block sizes was one of their features.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Mon, Sep 05, 2005 at 12:26:41AM -0400, Dave Jones wrote:
As someone who gets to read a lot of bug reports from end-users,
this thing is far from perfect judging by the number of tainted
oopses I've seen, and not all of them look like stack size issues.
It would make sense to use 4KB pages
2005/9/6, Giridhar Pemmasani [EMAIL PROTECTED]:
Andi Kleen wrote:
AFAIK with interrupt stacks it shouldn't be a big issue to switch
to a private bigger stack. ndiswrapper just needs to have its own private
way to do current which accesses thread_info at the bottom of the stack.
I am
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point. Rather,
This is what I had in mind before I saw this thread here. I, in
On Tue, 6 Sep 2005, Giridhar Pemmasani wrote:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point. Rather,
This is what I
On Tue, Sep 06, 2005 at 02:42:02PM -0400, linux-os (Dick Johnson) wrote:
I think
... and we have clear winner for the most incredible statement made on l-k.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
2005/9/6, Giridhar Pemmasani [EMAIL PROTECTED]:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point. Rather,
This is
On Tue, 6 Sep 2005, Jan Kiszka wrote:
2005/9/6, Giridhar Pemmasani [EMAIL PROTECTED]:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
stack.
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
Andi, their stack will have to have a valid thread_info-task because
interrupts will use it. Out of interest, could you please explain what
for?
No, with 4k interrupts run on their own stack with their own thread_info
Or rather
Daniel There are only two stacks involved, the normal kernel
Daniel stack and your new ndis stack. You save ESP of the kernel
Daniel stack at the base of the ndis stack. When the Windows
Daniel code calls your api, you get the ndis ESP, load the kernel
Daniel ESP from the
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
Andi, their stack will have to have a valid thread_info-task because
interrupts will use it. Out of interest, could you please explain what
for?
No, with 4k interrupts run
On Tue, 6 Sep 2005 18:19:45 -0400, Daniel Phillips [EMAIL PROTECTED] said:
Daniel There are only two stacks involved, the normal kernel stack
Daniel and your new ndis stack. You save ESP of the kernel stack
Sadly, that is not the case: Some drivers, especially USB drivers,
create multiple
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
Daniel There are only two stacks involved, the normal kernel
Daniel stack and your new ndis stack. You save ESP of the kernel
Daniel stack at the base of the ndis stack. When the Windows
Daniel code calls your api, you
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new ndis
stack. You save ESP of the kernel stack at the base of the ndis stack. When
the Windows code calls your api, you get the ndis ESP, load the kernel ESP
from the base of the ndis stack, push
On Tue, 2005-09-06 at 21:59 -0400, Mark Lord wrote:
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new
ndis
stack. You save ESP of the kernel stack at the base of the ndis stack.
When
the Windows code calls your api, you get the ndis
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new
ndis stack. You save ESP of the kernel stack at the base of the ndis
stack. When the Windows code calls your api, you get the ndis ESP, load
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
...as long as -task and -previous_esp are initialized,
staying on the bigger stack looks fine (previous_esp is apparently used
only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else does: it isn't
Alan Cox <[EMAIL PROTECTED]> writes:
> On Sul, 2005-09-04 at 07:51 -0700, Alex Davis wrote:
> > I'm not asking you to debug crashes. I'm simply requesting that the
> > kernel stack size situation remain as it is: with 8K as the default
> > and 4K configurable.
>
> How about the relevant
On Sep 5, 2005, at 18:32:32, Thorild Selen wrote:
Adrian Bunk <[EMAIL PROTECTED]> writes:
Please name situations where 8K stacks may be preferred that do not
involve binary-only modules.
How about NFS-exporting a filesystem on LVM atop md? I believe it has
been mentioned before in
Adrian Bunk <[EMAIL PROTECTED]> writes:
> Please name situations where 8K stacks may be preferred that do not
> involve binary-only modules.
How about NFS-exporting a filesystem on LVM atop md? I believe it has
been mentioned before in discussions that 8k stacks are strongly
recommended in this
On Sul, 2005-09-04 at 09:30 -0400, Ed Tomlinson wrote:
> MS stuff. We know that 4K stacks hurt the above. Do we really want to break
> working
> configs just to enforce 4K stacks? How does it hurt to make 4K the default
> and
> allow 8K? What _might_ make sense is to make 8K a reason to
On Sul, 2005-09-04 at 07:51 -0700, Alex Davis wrote:
> I'm not asking you to debug crashes. I'm simply requesting that the
> kernel stack size situation remain as it is: with 8K as the default
> and 4K configurable.
How about the relevant question - why hasn't someone fixed ndiswrapper
yet - its
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
[...]
> > But the real crux of the argument here is not whether or not people should
> > ever use binary-only drivers, it's whether the open source kernel
> > developers should spend any time
Willy Tarreau wrote (ao):
> So you're both half-right from your point of view. But you're both half-wrong
> too : no, people can't always choose, and no, people who don't choose their
> laptop are not impacted by development kernels. So let's turn the page and
> wait for a stable kernel.
If the
On 9/5/05, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Except that someone has to maintain the patch, because with the speed the
> kernel is changing, a patch against 2.6.14 will not work on 2.6.15.
Indeed. It has to be maintained in tree as well and I don't see any
justification for making
On Mon, September 5, 2005 2:04 am, Willy Tarreau said:
> They don't mind. Those people install Checkpoint on Linux. A product of
> which previous releases were even incompatible with security updates !
Heh.. well all the power to them. Still no reason for an open source
developer to waste one
On Mon, Sep 05, 2005 at 01:31:29AM -0400, Sean wrote:
> On Mon, September 5, 2005 1:01 am, Willy Tarreau said:
>
> > But how do you think Linux has penetrated the enterprise market ???
> > We all have put dual boots on every windows machine we had access to,
> > eventhough this was clearly
On Mon, Sep 05, 2005 at 01:31:29AM -0400, Sean wrote:
On Mon, September 5, 2005 1:01 am, Willy Tarreau said:
But how do you think Linux has penetrated the enterprise market ???
We all have put dual boots on every windows machine we had access to,
eventhough this was clearly forbidden. And
On Mon, September 5, 2005 2:04 am, Willy Tarreau said:
They don't mind. Those people install Checkpoint on Linux. A product of
which previous releases were even incompatible with security updates !
Heh.. well all the power to them. Still no reason for an open source
developer to waste one
On 9/5/05, Willy Tarreau [EMAIL PROTECTED] wrote:
Except that someone has to maintain the patch, because with the speed the
kernel is changing, a patch against 2.6.14 will not work on 2.6.15.
Indeed. It has to be maintained in tree as well and I don't see any
justification for making mainline
Willy Tarreau wrote (ao):
So you're both half-right from your point of view. But you're both half-wrong
too : no, people can't always choose, and no, people who don't choose their
laptop are not impacted by development kernels. So let's turn the page and
wait for a stable kernel.
If the
Willy Tarreau [EMAIL PROTECTED] wrote:
On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
[...]
But the real crux of the argument here is not whether or not people should
ever use binary-only drivers, it's whether the open source kernel
developers should spend any time worrying about
1 - 100 of 198 matches
Mail list logo
