Linux-Development-Sys Digest #669, Volume #7 Fri, 10 Mar 00 17:13:13 EST
Contents:
Re: kernel in C++ (Dieter Stueken)
Re: kernel in C++ (Alexander Viro)
Re: kernel in C++ ("Frank V. Castellucci")
Re: kmalloc allocate swappable memory? (Fabrice Peix)
Re: kmalloc allocate swappable memory? (Mathias Waack)
Re: init_module: device or resource busy error (Martin Gruber)
Re: Installing glibc (Please Help!) ([EMAIL PROTECTED])
Re: FastTrak66 driver? (Harvey Taylor)
Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)? ([EMAIL PROTECTED])
Re: Plug and Pray PCI Modem support (Mei)
Re: How to determine the Maximum nymber of system call per seconds? (Alan Donovan)
Re: Installing glibc (Please Help!) (Andreas Jaeger)
Re: Bus-master PCI slots (Gert van der Knokke)
Kernel Module Problem (orion22) (Francisco Obispo)
Bug in localedef or localeconv? (Andre Charbonneau)
Re: Bus-master PCI slots (Timothy J. Lee)
----------------------------------------------------------------------------
From: Dieter Stueken <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Fri, 10 Mar 2000 13:38:53 +0100
Bernd Strieder wrote:
> You say crap, but this crap has been designed to make
> programmers life easier, ...
but not the kernel life :-)
With this discussion we easily can fill up a discussion group
of it's on (is there some group already?). This C++ discussion
came up again and again with no result. Yes, many things might
be expressed much much clearer using C++, but it is simply
impossible for several reasons: Who is willing to rewrite the
whole kernel in C++? If you start now, it would take years to
do that and to test it and find all bugs you will introduce.
Meanwhile the original kernel will continue to develop much
faster than your C++ project, you will never overhaul it.
Even if all programmers, including Linus himself, will stop using
C and turn to C++ this means, that all development of linux will
stop for years too. Its really hard to accept, but the C train
runs too fast, to jump off now without beeing killed.
So it's right to refuse the statement: "all parts of the kernel
schould be recoded in C++ using all language features", but
on the other hand, it is silly to refuse any goods of C++
due to some bad properties of C++, like exceptions, which
are in fact absolutely unusuable within a linux kernel
environment. Also the statement "C++ is too buggy to be
taken into account" will not hold for ever.
The question should be: under which circumstances would it
be possible to introduce C++ into the kernel? There are big
parts which are not dealing directly with hardware or interrupts,
i.e. the filesystem parts. If you once have interfaces and wrapper
classes around the kernel structures you can start testing C++
without affecting the inner kernel construction. If it turns out
to be usuable, you may have a change to convert the inner kernel
routines step by step in the far future.
Dieter
--
Dieter St�ken, con terra GmbH, M�nster
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.conterra.de/ http://qgp.uni-muenster.de/~stueken
(0)251-980-2027 (0)251-83-334974
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: kernel in C++
Date: 10 Mar 2000 08:44:33 -0500
In article <[EMAIL PROTECTED]>,
Dieter Stueken <[EMAIL PROTECTED]> wrote:
>The question should be: under which circumstances would it
>be possible to introduce C++ into the kernel? There are big
>parts which are not dealing directly with hardware or interrupts,
>i.e. the filesystem parts. If you once have interfaces and wrapper
>classes around the kernel structures you can start testing C++
>without affecting the inner kernel construction. If it turns out
>to be usuable, you may have a change to convert the inner kernel
>routines step by step in the far future.
Leave filesystems alone. Contrary to luserish faith, OOP can be done in
C just fine and it's _much_ better to have clean langauge with well-understood
semantics for doing that stuff. C++ is too messy for that. It tries too hard
to look like C and that harms it. Big way. As for acceptance - heh. You know,
guys from the place where C++ was written did an OS several years after that.
And then one more. Ask Rob Pike why they didn't write their kernels in C++.
Arguments about lack of knowledge or legacy code do not fly - kernel was done
from scratch and that was the group that did the first C++ compilers.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Date: Fri, 10 Mar 2000 09:02:48 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Dieter Stueken wrote:
>
> Bernd Strieder wrote:
> > You say crap, but this crap has been designed to make
> > programmers life easier, ...
>
> but not the kernel life :-)
>
> With this discussion we easily can fill up a discussion group
> of it's on (is there some group already?). This C++ discussion
> came up again and again with no result. Yes, many things might
> be expressed much much clearer using C++, but it is simply
> impossible for several reasons: Who is willing to rewrite the
> whole kernel in C++? If you start now, it would take years to
> do that and to test it and find all bugs you will introduce.
> Meanwhile the original kernel will continue to develop much
> faster than your C++ project, you will never overhaul it.
> Even if all programmers, including Linus himself, will stop using
> C and turn to C++ this means, that all development of linux will
> stop for years too. Its really hard to accept, but the C train
> runs too fast, to jump off now without beeing killed.
>
> So it's right to refuse the statement: "all parts of the kernel
> schould be recoded in C++ using all language features", but
> on the other hand, it is silly to refuse any goods of C++
> due to some bad properties of C++, like exceptions, which
> are in fact absolutely unusuable within a linux kernel
> environment. Also the statement "C++ is too buggy to be
> taken into account" will not hold for ever.
>
> The question should be: under which circumstances would it
> be possible to introduce C++ into the kernel? There are big
> parts which are not dealing directly with hardware or interrupts,
> i.e. the filesystem parts. If you once have interfaces and wrapper
> classes around the kernel structures you can start testing C++
> without affecting the inner kernel construction. If it turns out
> to be usuable, you may have a change to convert the inner kernel
> routines step by step in the far future.
>
> Dieter
> --
> Dieter St�ken, con terra GmbH, M�nster
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> http://www.conterra.de/ http://qgp.uni-muenster.de/~stueken
> (0)251-980-2027 (0)251-83-334974
I disagree on the FUD factor layed on here. While I agree it would not
be a trivial undertaking I would consider that one of the fundemental
requirements would be to preserve the API, which could be easily done.
There are synchronized issues between current Linux in asm and C, and
with Linux in asm and C++.
Is it the right thing to do? If you lecture about why NOT instead of
ISSUES and HOW-TO we may never see it. What ever happened to
encouragement? If nobody encouraged Linus (through participation) our
choices would be the various general processing OS would be limited.
A C++ interface, and abstraction of key parts is quite desirable.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: Fabrice Peix <[EMAIL PROTECTED]>
Subject: Re: kmalloc allocate swappable memory?
Date: Fri, 10 Mar 2000 15:18:33 +0100
Alan Donovan wrote:
>
> Er, I think that's not true. Kernel addresses are simply physical
> addresses shifted by some constant amount, they're not virtual
> addresses. Therefore you can DMA to/from kernel buffers without further
> action.
>
> I don't claim to be an expert, but I'm pretty sure my undergrad OS
> course said "UNIX kernel pages never swap".
>
> alan
I think if you use GFP_DMA the memory is not swap but in other case
memory can be swap.
(I am not sure ...)
Bye.
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: kmalloc allocate swappable memory?
Date: Fri, 10 Mar 2000 15:23:10 +0100
Fabrice Peix wrote:
> I think if you use GFP_DMA the memory is not swap but in other case
> memory can be swap.
GFP_DMA ensures that the memory is accessable by old PC ISA hardware,
that means it must be below 16MB. Thats all.
Mathias
--
Mathias Waack | [EMAIL PROTECTED]
Tel.: +49 621 181 2717 Fax.: +49 621 181 2713
------------------------------
From: Martin Gruber <[EMAIL PROTECTED]>
Subject: Re: init_module: device or resource busy error
Date: Fri, 10 Mar 2000 15:47:46 +0100
Surya wrote:
>
> Everything is OK now................
> I made a simple mistake i.e. I returned 1 instead of 0 for success and
> hence the init_module() is showing that error message.
> The correct code should look like....
>
> int init_module()
> {
> blah..... blah..... //device driver initialization stuff
> if(success)
> return 0;
> else{
> ////// remove any previously initialized stuff here otherwise they
> will remain forever
> return 1;
> }
> }
>
> Then everything should be OK.
>
> Surya.
High,
I think you should take a look at asm/errno.h in your linux directory
and use the defines instead of just returning magic numbers which result
in "magic" error-messages :-).
Bye
Martin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Installing glibc (Please Help!)
Date: Fri, 10 Mar 2000 15:22:41 GMT
In article <[EMAIL PROTECTED]>,
Andreas Jaeger <[EMAIL PROTECTED]> wrote:
The FAQs are great!
But I still lack some answers:
Last time I tried to install glibc-2.1.3 - I think it was configure - a
sym link "gnu -> gnu" has been made and make failed.
Then I removed the folder and unpacked the tar a second time,
configured, made install ... and after running 'make install' for two
hours it seems as if a make rule would be missing:
make[2]: *** No rule to make target
`/usr/src/gnu/glibc-2.1.3-build/db/libdb1.so.2', needed by
`/usr/src/gnu/glibc-2.1.3-build/db2/db_dump185'. Stop.
make[2]: Leaving directory `/usr/src/gnu/glibc-2.1.3/db2'
make[1]: *** [db2/subdir_install] Error 2
make[1]: Leaving directory `/usr/src/gnu/glibc-2.1.3'
make: *** [install] Error 2
circumstances:
##############
Pentium 120, Suse 6.3 (kernel 2.2.13), all needed programs in
appropriate version.
calling from /usr/src/gnu/glibc-2.1.3-build
../glibc-2.1.3/configure \
--prefix /usr/local/glibc-2.1.3 \
--with-headers=/usr/src/linux-2.2.13/include \
--enable-add-ons=crypt,glibc-compat,linuxthreads
Please, what can I do??
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Harvey Taylor <[EMAIL PROTECTED]>
Subject: Re: FastTrak66 driver?
Date: Fri, 10 Mar 2000 09:34:43 -0800
Vetle Roeim wrote:
> * Harvey Taylor
> > Does anybody happen to know about any Promise FastTrak66
> > driver development happening?
>
> what's that? a Ultra66 controller?
Thanks for the reply Vetle.
The FastTrak66 and the Ultra66 are two different products.
I'm not sure how similar the drivers may be.
Any info appreciated.
<ciao>
-het
---
"Assembly of Japanese bicycle require great peace of mind."
- Instruction manual mentioned by R. Pirsig
Harvey Taylor mailto:[EMAIL PROTECTED] http://www.pangea.ca/~het
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)?
Date: Fri, 10 Mar 2000 15:58:24 GMT
In article <[EMAIL PROTECTED]>,
Robert Redelmeier <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > repeating the same procedure.). And a normal
> > user's job shouldn't kill the Unix system, should
> > it?
>
> Not if the hardware is OK.
>
> But I've written (GPL) testing utilities `burnP6` and `burnBX`
> that run as normal user processes. Since they are written
> in optimized asm, they _do_ work the processor/Northbridge/RAM
> very hard, and can provoke lockups and/or errors when the
> hardware is excessively clocked or weak in some other
> respect (cooling and power supply). Give'em a try.
>
> -- Robert author `cpuburn` http://users.ev1.net/~redelm
No, Robert,
I've tried both programs. Nothing happened. No hanging, nothing.
They were all running quite well, ten minutes or so.
No problems with the hardware! ???;-).
I doubt this, because I could repeat the whole hanging procedure
not only on a single machine. I've observed this halting phenomene
on at least four LINUX-SMP-systems (three with four Xeon-550MHz systems,
one with 2 PII 400MHz system).
If you'd know how to repeat the hanging fun, let me know: I can tell you
more about it,;-). Sorry. I'd wish that that was due to a hardware
problem, but this....
-Yan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mei <[EMAIL PROTECTED]>
Subject: Re: Plug and Pray PCI Modem support
Date: Fri, 10 Mar 2000 17:30:09 +0100
Reply-To:
[EMAIL PROTECTED]
Crasy1_69 ha scritto:
>
> Is there a kernel that supports PCI Plug and Pray modems?
>
If it's lucent then yes. See www.linmodems.org.
Ciao Mei
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: How to determine the Maximum nymber of system call per seconds?
Date: Fri, 10 Mar 2000 16:49:10 +0000
[EMAIL PROTECTED] wrote:
> I think a limitation of system calls will limit the trhoughput of
> the gigabit ethernet card.
Bigger chunks of data per call??
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Installing glibc (Please Help!)
Date: 10 Mar 2000 17:46:25 +0100
>>>>> irgei writes:
> In article <[EMAIL PROTECTED]>,
> Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> The FAQs are great!
> But I still lack some answers:
> Last time I tried to install glibc-2.1.3 - I think it was configure - a
> sym link "gnu -> gnu" has been made and make failed.
> Then I removed the folder and unpacked the tar a second time,
> configured, made install ... and after running 'make install' for two
configure;make;make check;make install - don't use make install
directly and always check that everything is fine.
> hours it seems as if a make rule would be missing:
> make[2]: *** No rule to make target
> `/usr/src/gnu/glibc-2.1.3-build/db/libdb1.so.2', needed by
> `/usr/src/gnu/glibc-2.1.3-build/db2/db_dump185'. Stop.
> make[2]: Leaving directory `/usr/src/gnu/glibc-2.1.3/db2'
> make[1]: *** [db2/subdir_install] Error 2
Could be a bug in the makefiles.
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: Gert van der Knokke <[EMAIL PROTECTED]>
Subject: Re: Bus-master PCI slots
Date: Fri, 10 Mar 2000 19:13:03 +0100
Alan Donovan wrote:
> "Timothy J. Lee" wrote:
> >
> > In kernels 2.0.* and 2.2.*, what are the ways to tell if a device
> > is in a bus-master capable PCI slot?
>
> Mastering capability resides with the card, not the slot itself. Look at
> /proc/pci for a listing of what devices you have and whether they are
> Master Capable. Look at kernel source drivers/pci/pci.c to find out how
> it's done. Basically it's the PCI_COMMAND_MASTER (Master Enable) bit in
> the PCI_COMMAND register for that device.
>
Still I remember some motherboards not being able to bus mastering on the PCI
slot next to the ISA slot (sharing the same slot plate).
So it could well be a hardware feature.
Gert
--
===============================================================
= LINUX = Unix The Next Generation .......................... =
= [EMAIL PROTECTED] running Linux on Intel and Alpha =
===============================================================
------------------------------
From: Francisco Obispo <[EMAIL PROTECTED]>
Subject: Kernel Module Problem (orion22)
Date: Fri, 10 Mar 2000 16:55:41 -0400
Hello.
Im currently writing a character device driver for a serial board that
a friend is developing... my problem is that when I try to write to the
por 0x301, using writeb(0x8f,0x301); It does it too fast for the decoder
to notice this change... so I was reading and found out that slow boards
use outb_p but when I use this function, I get no errors at compile time
but then I get unresolved symbol outb_p when I try to load the module...
Any Ideas???
I'm using
gcc -D__KERNEL__ -DLINUX -DMODULE -DMODVERSIONS -Wall
to compile the module.... do I need anything else??
I'm also including
<asm/irq.h>
<asm/io.h>
<linux/interrupt.h>
<linux/wrapper.h>
<linux/fs.h>
Thanx
------------------------------
Date: Fri, 10 Mar 2000 16:51:14 -0800
From: Andre Charbonneau <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.misc
Subject: Bug in localedef or localeconv?
Hi,
I think I found a bug in localedef or localeconv.
If you take the fr_CA locale and edit it so that you put p_cs_precedes
to 1, but leave n_cs_precedes to 0 and recompile the locale binaries
using localedef, it looks like n_cs_precedes gets set to 1 also. (the
structure returned by localeconv contains a '1' for both p_cs_precedes
and n_cs_precedes)
Can you please let me know if you ever experienced this kind of problem
before...
Thanks,
--
Andre Charbonneau
Software Engineer
Corel Corporation
728-0826 x5612
------------------------------
From: [EMAIL PROTECTED] (Timothy J. Lee)
Subject: Re: Bus-master PCI slots
Date: 10 Mar 2000 21:50:24 GMT
Reply-To: see-signature-for-email-address---junk-not-welcome
Alan Donovan <[EMAIL PROTECTED]> writes:
|"Timothy J. Lee" wrote:
|>
|> In kernels 2.0.* and 2.2.*, what are the ways to tell if a device
|> is in a bus-master capable PCI slot?
|
|Mastering capability resides with the card, not the slot itself.
There are some motherboards which have non-busmaster capable slots
in them. Documentation for the Luckystar 6VABX2 (Via Apollo Pro
chipset) and Luckystar 6ZBX2V (Intel 440ZX chipset) indicates that
these boards have non-busmaster capable slots.
|Look at
|/proc/pci for a listing of what devices you have and whether they are
|Master Capable. Look at kernel source drivers/pci/pci.c to find out how
|it's done.
So the question is, if a busmaster capable PCI card is put in a
non-busmaster capable PCI slot, does the method above work to tell
that situation?
--
========================================================================
Timothy J. Lee timlee@
Unsolicited bulk or commercial email is not welcome. netcom.com
No warranty of any kind is provided with this message.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
