Ricky Beam wrote:
>
> On Thu, 14 Sep 2000, Nick Pollitt wrote:
> ...
> >And second, why is the 4K limit there in the first place?
>
> Primarily because it was never designed for 90% of the crap that's in there
> now. I have long hated the BS required to get more than 4k worth of stuff
> out of
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:John Byrne <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Anyway, one of the things I was hoping to find out by going to
> > linux-kernel was if there was anything other than devfs in the offing:
> > such
"H. Peter Anvin" wrote:
Followup to: [EMAIL PROTECTED]
By author:John Byrne [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Anyway, one of the things I was hoping to find out by going to
linux-kernel was if there was anything other than devfs in the offing:
such a larger dev_t.
Ricky Beam wrote:
On Thu, 14 Sep 2000, Nick Pollitt wrote:
...
And second, why is the 4K limit there in the first place?
Primarily because it was never designed for 90% of the crap that's in there
now. I have long hated the BS required to get more than 4k worth of stuff
out of /proc.
Andi Kleen wrote:
>
> On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote:
> > About B) I can' believe you seriously want to duplicate the merging code
> > in each lowlevel driver given most of them could share the same code (as
> > they're doing in linux).
>
> I guess it would
Andrea Arcangeli wrote:
>
> On Wed, 13 Sep 2000, Martin Dalecki wrote:
>
> >"Jeff V. Merkey" wrote:
> >
> >> lessons learned in live customer accounts. In NetWare, requests are
> >> merged at A) the boundry between the File Cache and the I/O
Andrea Arcangeli wrote:
On Wed, 13 Sep 2000, Martin Dalecki wrote:
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and B) in the drivers
"Jeff V. Merkey" wrote:
>
> Martin,
>
> I'm glad you are not still mad at me. :-) I hope this info was
> helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the
Hans Reiser wrote:
>
> I really think Rik has it right here. In particular, an MP3 player needs to be able
>to say, I have
> X milliseconds of buffer so make my worst case latency X milliseconds. The number
>of requests is
> the wrong metric, because the time required per request depends on
"Jeff V. Merkey" wrote:
> lessons learned in live customer accounts. In NetWare, requests are
> merged at A) the boundry between the File Cache and the I/O subsystem,
> and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place to do this. The generic elevator on a
Andrea Arcangeli wrote:
>
> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>
> >First of all: In the case of the mp3 player and such there is already a
> >fine
> >proper way to give it better chances on getting it's job done smooth -
> >RT kernel sceduler prioriti
Chris Evans wrote:
>
> On Tue, 12 Sep 2000, Hans Reiser wrote:
>
> > I really think Rik has it right here. In particular, an MP3 player
> > needs to be able to say, I have X milliseconds of buffer so make my
> > worst case latency X milliseconds. The number of requests is the
> > wrong
Chris Evans wrote:
On Tue, 12 Sep 2000, Hans Reiser wrote:
I really think Rik has it right here. In particular, an MP3 player
needs to be able to say, I have X milliseconds of buffer so make my
worst case latency X milliseconds. The number of requests is the
wrong metric, because
Andrea Arcangeli wrote:
On Tue, 12 Sep 2000, Martin Dalecki wrote:
First of all: In the case of the mp3 player and such there is already a
fine
proper way to give it better chances on getting it's job done smooth -
RT kernel sceduler priorities and proper IO buffering. I did something
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place to do this. The generic elevator on a
Hans Reiser wrote:
I really think Rik has it right here. In particular, an MP3 player needs to be able
to say, I have
X milliseconds of buffer so make my worst case latency X milliseconds. The number
of requests is
the wrong metric, because the time required per request depends on disk
"Jeff V. Merkey" wrote:
Martin,
I'm glad you are not still mad at me. :-) I hope this info was
helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the same
Gary Lawrence Murphy wrote:
> The analogy to typing hex codes or toggling code at the console is
> also apt. Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I
> tend to debug intuitively based on my knowledge of
Gary Lawrence Murphy wrote:
The analogy to typing hex codes or toggling code at the console is
also apt. Unix ascended over Multix in no small part because of C,
which drew sneers from the trad programmer of the day. Personally, I
tend to debug intuitively based on my knowledge of code,
Simon Richter wrote:
>
> On Thu, 7 Sep 2000, Martin Dalecki wrote:
>
> > > I've done an implementation of some of the Win32 "system calls" in a kernel
> > > module in an attempt to speed up Wine.
>
> > 1. Linux is UNIX not NT... (in terms of API)
David Howells wrote:
>
> I've done an implementation of some of the Win32 "system calls" in a kernel
> module in an attempt to speed up Wine.
Please by no way don't include this patch into the official tree.
It's insane due to the following:
1. Linux is UNIX not NT... (in terms of API)
2.
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> >
> > So may I just suggest to repleace the usage of cpp at all with something
> > more
> > suitable for the task at hand and with a much more regular/stringent
> > syntax
> >
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> > We could use some more infrastructure here.
> >
> > (1) A 'make randomconfig' tool that generates a random configuration.
> >
> > (2) Make the architecture a configuration variable (!)
> >
> > (3) A collection
Alan Cox wrote:
>
> > 1. This function is only used in the poorly maintained ftape driver.
> >The usage there isn't appriopriate for modern kernels.
>
> The ftape driver isnt exactly poorly maintained. Its just not integrated into
> 2.3/2.4. Ftape 4.0 is still elsewhere
This is wrong,
Alan Cox wrote:
1. This function is only used in the poorly maintained ftape driver.
The usage there isn't appriopriate for modern kernels.
The ftape driver isnt exactly poorly maintained. Its just not integrated into
2.3/2.4. Ftape 4.0 is still elsewhere
This is wrong, since last
Alexander Viro wrote:
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
We could use some more infrastructure here.
(1) A 'make randomconfig' tool that generates a random configuration.
(2) Make the architecture a configuration variable (!)
(3) A collection of RPM's so that
Alexander Viro wrote:
On Wed, 6 Sep 2000, Martin Dalecki wrote:
IRONY ON
So may I just suggest to repleace the usage of cpp at all with something
more
suitable for the task at hand and with a much more regular/stringent
syntax
better fitting into the syntax of the pure C language
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > Easy - the same way you do for cross compilation. Basically just:
> >
> > export CC=g++ --some-magic-long-option-i-dont-remember; make
>
> ... and you still have only a subset of t
1. This function is only used in the poorly maintained ftape driver.
The usage there isn't appriopriate for modern kernels.
2. This function acts only on the sig set of the current process, so
the first parameter should be just a porinter to current, instead of
currgen->sigset.
So it
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed,
Linus Torvalds wrote:
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > >
> > > What would be acceptable is something that understands C, and that can be
> > > used to follow these things. Like "tags".
> >
> > I don't like hungarian notation too, but tags is out of question,
> >
"Jeff V. Merkey" wrote:
>
> Ingo Molnar wrote:
> >
> > On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> >
> > > Your arguments are personal, not technical. [...]
> >
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > My point was basically that omitting useful debugging tools makes it
> > not any less likely that people use the (A) strategy (easy fix instead
> > of real understanding). For some people it is so painfull to work with
> > raw
Linus Torvalds wrote:
On Tue, 5 Sep 2000, Alexander Viro wrote:
What would be acceptable is something that understands C, and that can be
used to follow these things. Like "tags".
I don't like hungarian notation too, but tags is out of question,
unfortunately. Too much
1. This function is only used in the poorly maintained ftape driver.
The usage there isn't appriopriate for modern kernels.
2. This function acts only on the sig set of the current process, so
the first parameter should be just a porinter to current, instead of
currgen-sigset.
So it
Alexander Viro wrote:
On Wed, 6 Sep 2000, Martin Dalecki wrote:
Easy - the same way you do for cross compilation. Basically just:
export CC=g++ --some-magic-long-option-i-dont-remember; make
... and you still have only a subset of the tree, simply because it is fed
through cpp
Elmer Joandi wrote:
understanding the
underlying principles and the code.
Speaking about that, I have been long time dreaming
about following strict standard template for linux kernel functions:
(macroplay intended)
--
INLINE(context,level,for_speed, fixed)
Ingo Molnar wrote:
On Tue, 5 Sep 2000, Andi Kleen wrote:
My point was basically that omitting useful debugging tools makes it
not any less likely that people use the (A) strategy (easy fix instead
of real understanding). For some people it is so painfull to work with
raw dumps that
"Jeff V. Merkey" wrote:
Ingo Molnar wrote:
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
Your arguments are personal, not technical. [...]
no, my arguments are technical, but are simply focused towards the
conceptual (horizontal) development of Linux, not the vertical
development
201 - 239 of 239 matches
Mail list logo
