Richard B. Johnson writes:
> On Thu, 26 Oct 2000, Albert D. Cahalan wrote:
>> Richard B. Johnson writes:
>>> o Once installed, a kernel module is every bit as "efficient"
>>> as some driver linked into the kernel at build-time. Of course
>>
>> I doubt this is true on most modern processors. On
Andi Kleen <[EMAIL PROTECTED]>:
> On Thu, Oct 26, 2000 at 11:00:03AM -0500, Jesse Pollard wrote:
> > Keith Owens <[EMAIL PROTECTED]>:
> > >
> > > On Thu, 26 Oct 2000 09:17:49 -0400 (EDT),
> > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > >This shows that out of 34,678 bytes
Keith Owens <[EMAIL PROTECTED]>:
>
> On Thu, 26 Oct 2000 09:17:49 -0400 (EDT),
> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
[snip]
> >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5
> >pages. Since there are 5 modules, we waste about 1/3 page per module.
> >
> >So I don'
On Thu, 26 Oct 2000 09:17:49 -0400 (EDT),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>On Thu, 26 Oct 2000, Albert D. Cahalan wrote:
>> I doubt this is true on most modern processors. On the Pentium
>> and above, large pages are used for the kernel. The PowerPC port
> ^^^
On Thu, 26 Oct 2000, Albert D. Cahalan wrote:
> Richard B. Johnson writes:
> > On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
>
> > o Once installed, a kernel module is every bit as "efficient"
> > as some driver linked into the kernel at build-time. Of course
>
> I doubt this is true on
Richard B. Johnson writes:
> On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
> o Once installed, a kernel module is every bit as "efficient"
> as some driver linked into the kernel at build-time. Of course
I doubt this is true on most modern processors. On the Pentium
and above, large pa
On Mon, 23 Oct 2000, Hacksaw wrote:
> > Another linux caveat. Scads of undocumented and virtually undiscoverable
> > behaviours :-)
>
> Undiscoverable? You have the source code, what more do you want?
> Start documenting!
TOO LATE ;)
I documented all that stuff quite a while ago, see
Document
On Mon, 23 Oct 2000, Dennis wrote:
> At 07:19 PM 10/23/2000, Andi Kleen wrote:
> >On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote:
> > > - FreeBSD will display kernel print messages with syslogd not running, and
> > > linux will not.
> >
> >Linux will also when the console log level is set
On Mon, 23 Oct 2000, Andre Hedrick wrote:
> Subject: Re: Topic for discussion: OS Design + GPL
>
> ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz
>
> Could explain to me why ET Inc is modifying GPL drivers and then
> republishing the binaries as modules only?
>
> Not
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > The pc speaker is fine for playing one note at a time - it is
> > extremely shitty hardware if you want to play samples.
>
> It's actually quite reasonable for sound effects. Stuff like beeps and
> boings to announce talk requests, new mail,
On Mon, Oct 23, 2000 at 12:51:16PM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
> > This user also wants a
> > smooth GUI, a mouse pointer that doesn't flinch under load,
>
> Try andrea archangeli's VM patches. When I use those patches X gets much
> smoo
On Mon, Oct 23, 2000 at 07:43:24PM -0400, Dennis wrote:
> At 07:19 PM 10/23/2000, Andi Kleen wrote:
> >On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote:
> > > - FreeBSD will display kernel print messages with syslogd not running, and
> > > linux will not.
> >
> >Linux will also when the cons
On Mon, 23 Oct 2000, Hacksaw wrote:
> > Another linux caveat. Scads of undocumented and virtually undiscoverable
> > behaviours :-)
>
> Undiscoverable? You have the source code, what more do you want? Start
> documenting!
Oh no then they would have to publish their findings, and that is only
> Another linux caveat. Scads of undocumented and virtually undiscoverable
> behaviours :-)
Undiscoverable? You have the source code, what more do you want? Start
documenting!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
At 07:19 PM 10/23/2000, Andi Kleen wrote:
>On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote:
> > - FreeBSD will display kernel print messages with syslogd not running, and
> > linux will not.
>
>Linux will also when the console log level is set high enough (which it
>is by default, just it i
ftp://ftp.etinc.com/pub/linux/linux22_hdlc.tgz
Hi Dennis,
Could explain to me why ET Inc is modifying GPL drivers and then
republishing the binaries as modules only?
Not that it is my sub-system, but I am not sure that my friend Don knows
of this issue. If Don does not care then, good day.
l
On Mon, Oct 23, 2000 at 06:43:28PM -0400, Dennis wrote:
> - FreeBSD will display kernel print messages with syslogd not running, and
> linux will not.
Linux will also when the console log level is set high enough (which it
is by default, just it is usually too low after you killed klogd).
Unqu
At 04:35 PM 10/23/2000, you wrote:
>On Mon, 23 Oct 2000, Dennis wrote:
>
> > This is typical of the "linux mentality". Why do other OSs have solutions
> > that work, yet linux's method requires special coding? If it "has to be
> > done that way", why do other OS's have solutions that dont do it th
On Mon, 23 Oct 2000, Dennis wrote:
> This is typical of the "linux mentality". Why do other OSs have solutions
> that work, yet linux's method requires special coding? If it "has to be
> done that way", why do other OS's have solutions that dont do it that way?
> the size of the buffer is an a
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
> This user also wants a
> smooth GUI, a mouse pointer that doesn't flinch under load,
Try andrea archangeli's VM patches. When I use those patches X gets much
smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11.
> and a s
This is typical of the "linux mentality". Why do other OSs have solutions
that work, yet linux's method requires special coding? If it "has to be
done that way", why do other OS's have solutions that dont do it that way?
the size of the buffer is an annoyance but not a serious problem however.
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
> Then I start hearing about khttpd, something that (ideally)
> should go in user space,
> hardware drivers are rejected (PCSP is my example, but what if
> some other device is as kludgy as the pcsp? Will it be rejected
> too?)
PCSP isn't in
On Mon, 23 Oct 2000, Dennis wrote:
> >
> >o What used to take a month to get working in SunOS, will
> >take a few hours on Linux. Linux has continually improved the
> >resources available to the modules. In the beginning there was
> >a kernel memory allocator. Now we have common resource al
>
>Then you get more incorrect documentation and discover that the
>kernel interface has changed. You repeat this whole episode until
>you finally get to 'talk' to the hardware that your driver is
>supposed to control. This is only the beginning.
>
>With Linux, you just write the code. You put in
"Dwayne C . Litzenberger" wrote:
>
> First of all, I'd like to say that I'm not writing this to piss anyone off.
> It's not a flame, a troll, or a personal attack on anyone. I my writing will
> aid in the improvement of Linux. Please read this with as much neutrality as
> you can summon.
I th
[EMAIL PROTECTED] said:
> The pc speaker is fine for playing one note at a time - it is
> extremely shitty hardware if you want to play samples.
It's actually quite reasonable for sound effects. Stuff like beeps and
boings to announce talk requests, new mail, etc. But yes, playing mp3s on
it d
[EMAIL PROTECTED] said:
> 5. Linus tends to blame patches for inadequacies in the kernel. The
> PC speaker driver is a perfect example: No driver should have to do
> something "dirty" in order to function, because the operating system
> should provide clean ways to do this.
Bad example. The P
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
>
> Linux's loadable modules design is insufficient. I have several reasons for
> making this claim:
>
> 1. Many things are inaccessible to the modules: There are relatively few
> kernel modifications that can be compiled without patching the
"Dwayne C . Litzenberger" <[EMAIL PROTECTED]> said:
[...]
> Then, I heard of Linux, and installed it. What a difference! Much
> faster, and sooo stable! I loved it. It was still clunky, and slow
> (compare a P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's
> not),
Comparing di
"Dwayne C . Litzenberger" <[EMAIL PROTECTED]> said:
[...]
> So what we really need to do is get some custom "RAM blitter" into our
> hardware to do the memory copies needed for fast context switching and
> message passing.
Nope. The problem is that RAM is slow. No way around that.
--
Dr. Horst
"Dwayne C . Litzenberger" wrote:
>
> First of all, I'd like to say that I'm not writing this to piss anyone off.
> It's not a flame, a troll, or a personal attack on anyone. I my writing will
> aid in the improvement of Linux. Please read this with as much neutrality as
> you can summon.
And
Marty Fouts writes:
> I have had the good fortune of working with one architecture (PA-RISC) which
> gets the separation of addressability and accessability 'right' enough to be
> able to partition efficiently and use ordinary procedure calls (with some
> magic at server boundaries) rather than IP
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote:
> Too bad nobody on this list works at an electronics design company... ;-P
Doesn't Transmeta count as an electronics design company? ;)
--
Adam Sampson
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "u
On Sun, Oct 22, 2000 at 04:29:19PM -0600, Dwayne C . Litzenberger wrote:
> 5. Linus tends to blame patches for inadequacies in the kernel. The PC
> speaker driver is a perfect example: No driver should have to do something
> "dirty" in order to function, because the operating system should provi
[EMAIL PROTECTED] (Dwayne C . Litzenberger) writes:
You contradict yourself:
[...]
> 3. Modules can very easily crash the whole kernel. This is because
> each module does not get to run in its own protected memory space, as
> it would i= n a well-designed microkernel.
[...]
> very elegant op
imization for all-in-one-address-space
'kernels.'
By the way, even highly decomposed very modular systems aren't as flexible
as the people who first developed them expected them to be, but the reason
behind that is for a whole other discussion.
Marty
-Original Message-
From
he VAX-ish memory architecture of systems like
x86. It doesn't have to be in IA-64, if one is willing to abandon 'legacy.'
-Original Message-
From: Dwayne C . Litzenberger [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 22, 2000 8:57 PM
To: Erno Kuusela
Cc: [EMAIL PROTECTED
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote:
> [snip]
> > crossing memory protection domains is slow, there's no way around
> > it (except better hardware).
>
> So what we really need to do is get some custom "RAM blitter" into our
> hardware to do the memory copies ne
I'll explain my reason for this rant.
The Amiga was my second computer, and the one I spend most of my computing
life on. I've grown up noticing all the things the PC/Windows did wrong while
the Amiga did it right (mostly UI stuff).
Later, I got my own PC, running Windows 95. Horror. Win95 is
[snip]
> crossing memory protection domains is slow, there's no way around
> it (except better hardware).
So what we really need to do is get some custom "RAM blitter" into our
hardware to do the memory copies needed for fast context switching and message
passing.
Too bad nobody on this list wor
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
>Although I am a programmer, I am not yet a kernel hacker, so some of my claims
Point 1.
>*very* efficient. However, there are some drawbacks to microkernels that have
>been raised
Point 2.
>(and I don't have the expertise to argue about t
On Sun, Oct 22, 2000 at 04:58:45PM -0600, Dwayne C . Litzenberger wrote:
> Could you elaborate? AFAIK, both Neutrino and exec.library are microkernels,
> and they by no means lack performance. Even Windows is a microkernel (sort
> of), and it doesn't lack in performance that much.
Exec.library
In article <[EMAIL PROTECTED]> you wrote:
> A few years ago, there was an intense debate around the question of
> cooperative vs. preemptive multitasking operating system design. Today,
> however, cooperative multitasking is a thing of the past, and it is virtual=
> ly
> undisputed that the preem
[EMAIL PROTECTED] proclaimed...
> Could you elaborate? AFAIK, both Neutrino and exec.library are
> microkernels, and they by no means lack performance.
Whilst I've not used Neutrino, I did use exec.library for several
years (and was part of a project to rewrite the bad parts before
CBM went dow
Yikes! Within 5 minutes, I already got a few personal attacks! (and some very
insightful messages as well.)
I'll end this here before it gets too out-of-control.
I should have done my homework before posting. I don't totally agree that my
posts were wrong (as an end user, I can definitely see
On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote:
> Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's
> probably slower than Linux, but it's a microkernel.
I'll ignore that.
> I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentall
> "Dwayne" == Dwayne C Litzenberger <[EMAIL PROTECTED]> writes:
Dwayne> First of all, I'd like to say that I'm not writing this to
Dwayne> piss anyone off. It's not a flame, a troll, or a personal
Dwayne> attack on anyone. I my writing will aid in the improvement of
Dwayne> Linux. Please r
47 matches
Mail list logo