Linux-Development-Sys Digest #678, Volume #7 Mon, 13 Mar 00 22:13:19 EST
Contents:
beep "color"? ([EMAIL PROTECTED])
Re: kernel in C++ ("Frank V. Castellucci")
Re: kernel in C++ (Kaz Kylheku)
[Q] I/O Benchmark in Linux (Kim Tae-hyoung(M2000))
Re: Plug and Pray PCI Modem support (student)
Re: LILO and GRUB: where do you pick disk geometry from? (repost) (student)
Re: kernel in C++ (Christopher Browne)
Re: kernel in C++ (Christopher Browne)
Re: kernel in C++ (Christopher Browne)
Re: kernel in C++ (Christopher Browne)
[Q] LILO question? ("Tae-sung Kim")
Re: Uhhuh. NMI received for unknown reason 3c/2c/3d/2d (Robert Redelmeier)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: beep "color"?
Date: Tue, 14 Mar 2000 00:47:46 GMT
linux 2.2:
I would like to have a program that can beep with different
characteristics, using just the PC Speaker. Something like
beep(100 /*Hz*/, 0.3 /*secs*/)
would be great. Preferably, it would work under X, under the console,
and in a program that is a daemon. In other words, just access to a pc
speaker device. (I am willing to take the security risk of making the
audio device [??] world writeable, so that someone could annoyingly beep
me for a while.) Anyone have such a C routine?
This should also be useful in other situations. For example, in a
shell, a "multiple-completions-possible" should beep differently from
"no-completion-possible."
/iaw
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 13 Mar 2000 20:24:28 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Kaz Kylheku wrote:
>
> On Mon, 13 Mar 2000 18:03:17 -0500, Frank V. Castellucci
> <[EMAIL PROTECTED]> wrote:
> >
> >Personally, I have a problem with talk of C++ exceptions used in the
> >context of a kernel. Whereas an application can elect to either continue
> >operating or exit the application, only under EXTREME circumstances
> >(like work that hasn't been completed to handle the situation where it
> >just stops) does a OS have that as an option, not a robust one anyway.
>
> Then you must have a problem with all the calls to the panic() function
> inside the kernel when some catastrophic condition is detected. Or with system
> calls returning a negative value to user space to indicate that a system call
> failed.
>
> An unhandled or unexpected C++ exception in the kernel would just call panic.
> A handled exception would be treated in various sensible ways, suchas being
> converted to an E* error code at the top level of a system call.
I have no control over what has already been done. I was stating that
there are liberties that a application has in regards to exception
HANDLING, or lack thereof, versus the kernel.
Also, how many times would you expect the unhandled exception need be
called before you would consider that fact alone a defect? Hardware
malfunctions or similar problems aside, if it is a logic error then it
is a defect.
> >I also don't like the idea of using C++ exceptions to control the flow
> >of execution.
>
> That's your opinion. Some people don't like the idea of using function
> calls to control the flow of execution, so they write programs that are
> nothing but a huge main() function.
>
> The alternative to using exceptions is to check for an error result at every
> level of a function call chain, and be sure to free any locally acquired
> resources before returning.
>
> There is nothing inherently evil or dangerous about exceptions. There are just
> some practical concerns: code bloat in modules that use it, complexity of run
> time suport.
>
> Debugging exceptions is also hard---in particular, getting the coverage of
> every possibility. But debugging any kind of error recovery is hard in the
> same way. Whether you throw an exception or percolate an error result,
> there are similar verification and testing challenges in either approach.
There are a number of discipline lines that are being crossed, logic
flow, invarient state, error handling, kernel bloat, etc. that have to
be considered. C++ exceptions are a wonderful boon to development which
"helps" codify the discipline of cleaning up and reseting invarient
state. It provides a meaningful reasoning mechanism through type
extension as well. Is it what you want to control flow in the kernel?
Maybe. Does it bloat code? Probably. Is it worth it? Depends.
I would think it may be useful in early kernel development stages, but
with an eye on performance I would think there are elegant solutions
that don't require it.
Frank
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 01:37:59 GMT
On Mon, 13 Mar 2000 20:24:28 -0500, Frank V. Castellucci
<[EMAIL PROTECTED]> wrote:
>
>Also, how many times would you expect the unhandled exception need be
>called before you would consider that fact alone a defect?
Just once.
>Hardware malfunctions or similar problems aside, if it is a logic error then
>it is a defect.
Yes; an unhandled exception is a serious problem in a system that is supposed
to run indefinitely. It essentially means that the system has paniced.
>There are a number of discipline lines that are being crossed, logic
>flow, invarient state, error handling, kernel bloat, etc. that have to
>be considered. C++ exceptions are a wonderful boon to development which
>"helps" codify the discipline of cleaning up and reseting invarient
>state. It provides a meaningful reasoning mechanism through type
>extension as well. Is it what you want to control flow in the kernel?
>Maybe. Does it bloat code? Probably. Is it worth it? Depends.
I might want it in a given module, not necessarily kernel-wide. If people start
using it in module programming, it would be nice to factor out the run-time
support for it into a module, to eliminate redundancy.
Thus if a driver is loaded which requires C++ runtime support, a C++ runtime
support module is also loaded automatically.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kim Tae-hyoung(M2000))
Subject: [Q] I/O Benchmark in Linux
Date: 14 Mar 2000 10:44:12 +0900
Hi!
I need some I/O benchmark programs running on Linux.
What I want to do is to test the raw I/O performance
of md or LVM in Linux.
I have tried the program 'Bonnie'. But the result is
very strange.
Thanks in advance.
------------------------------
Date: Mon, 13 Mar 2000 20:24:21 -0600
From: student <[EMAIL PROTECTED]>
Subject: Re: Plug and Pray PCI Modem support
since everything that is pci is a form of pnp, the configuration of your
modem is done entirely by software, either your bios or your os. if you
want the details of setting up your pci modem in linux, check my web
page. the page was written specifically for 3com modems, but it applies
to any controller-based pci modem.
http://members.xoom.com/mhpatters/comp/hardware/5613conf.htm
MHP
Crasy1_69 wrote:
> Is there a kernel that supports PCI Plug and Pray modems?
>
> --
> Posted via CNET Help.com
> http://www.help.com/
------------------------------
Date: Mon, 13 Mar 2000 20:35:27 -0600
From: student <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: LILO and GRUB: where do you pick disk geometry from? (repost)
Here's your fix:
1. Re-compile your kernel. Something you should do anyway. (I see no
reason to not customize your os to your system when given the opportunity.
2. Forget Lilo. Why have a boot manager on a single-dual boot system?
fdisk /mbr
3. Copy your kernel image to /dev/hda0.
4. Shut down and reboot.
MHP
[EMAIL PROTECTED] wrote:
> Hi!
>
> I tried to solve system boot problem using both LILO and GRUB. System
> is P90, with Phoenix BIOS 4.04 and Fujitsu's MPB3021AT hard drive, and
> only Linux is there. Manufacturer data says that Bios setting should
> be Cyl/Head/sec = 4470/15/63. BIOS has LBA mode enabled and it
> autodetects disk with C/H/S=4470/15/63. OS images are on the partition
> that is 1023 cylinders, and it's a first partition on the drive. Boot
> sequence in BIOS is set to be A: then C:.
>
> LILO story (quite interesting!): ------------------------
>
> In lilo.conf I specified "linear" option, and tried switching on/off
> the "compact" option.
>
> When I turn on the system, it gets to "LI" and stops. NOW THIS: when I
> first boot using a floppy, take the floppy out and subsequently
> shutdown the system to reboot, LILO prompt appears. Now, I can press
> hardware RESET button many times, the boot will always be
> successful. Interestingly, disk geometry during the boot is reported
> as 558/120/63. But, THE FIRST TIME I TURN PC OFF, and try to boot, it
> gets to "LI" and stops. I tried to explicitely set disk geometry to
> real values, then reported (558...) but nothing worked.
>
> Conclusion:
> It looks as that after the first successful boot somenone
> (BIOS?Linux?) somehow sets up proper hard disk geometry parameters and
> stores them in some volatile RAM location that preserves its content
> on RESET, but loses it on power down. LILO works flawlessly once
> floppy has been accessed but fails when it has to do it on its own.
>
> GRUB story:
>
> After LILO failure, I decided to try GRUB. The behaviour is similar: I
> created a boot floopy containing only "stage1" loader. When I boot
> with that floppy, I get a GRUB prompt and then commands:
>
> kernel (hd0,0)/vmlinuz
> boot
>
> make it boot the system effortlessly. Then I used "install" command to
> make it boot directly from the hard disk, using stage1_lba. After the
> reset, GRUB reported:
>
> LBA Error
>
> QUESTION:
>
> I read in Large-Disk HOWTO that these problems are caused by
> incompatibility of various standards regarding representation of disk
> geometry. However, it did not give any hint about overcoming this
> problem. If the boot process IS possible directly from the hard disk,
> without a floppy, obviously there is a set of geometry parameters that
> works. I guess the solution is to find right geometry parameters. Is
> there some systematic procedure that leads to successful guess? Does
> anyone know of some volatile RAM location, that does not get
> initialized on hardware RESET, and might contain disk geometry params
> I look for? Could it be in CMOS chip that has a real-time clock?
>
> Thanks a lot.
>
> Milan
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 02:44:00 GMT
Centuries ago, Nostradamus foresaw a time when Frank V. Castellucci
would say:
>Christopher Browne wrote:
>>
>> You want to write an OS kernel in C++?
>>
>> _Feel free._
>
>In my first response I posted without completing the sentence. What was
>intended was:
>
>I would gladly give up all other work if I was funded to undertake a C++
>Linux OS opportunity.
>
>And there is a word that no one has used.
If you can convince someone to fund you to do the task, that's cool.
If you haven't had some history in contributing significant changes to
the Linux kernel "in C," you may find it challenging to find anyone
who will trust you with funding for such a project.
If realistically wish to take up such a project, I'd suggest you start
by putting some effort into understanding "Linux in C," as that is an
appropriate way of:
a) Understanding *precisely* what it is that kernel authors are
writing, and
b) Making your name more familiar so that someone might be willing
to say, "That guy is credible as a known kernel developer," which
I'd expect to be a prerequisite to "getting funding."
--
Rules of the Evil Overlord #57. "I will not rely entirely upon "totally
reliable" spells that can be neutralized by relatively inconspicuous
talismen."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 02:44:01 GMT
Centuries ago, Nostradamus foresaw a time when Mario Klebsch would say:
>[EMAIL PROTECTED] (Christopher Browne) writes:
>
>>It seems to me that it would be vastly more sensible for the people
>>that want to create an OS in C++ to *START THEIR OWN PROJECT.*
>
>That probbaly is the best aproach. And there are other issues to
>handle: The system call API is a very traditional procedural API. For
>an object oriented OS using a kernel written in C++, I would expect an
>object oriented API to the kernel. This API would (and should) be
>incompatible to the current linux system call interface.
... And *that* expectation ("not compatible with Linux as we know it")
was not foreign to my thinking here ...
It makes very little sense to do a "shallow" port of Linux to C++, as
this means going through all the contortions of figuring out policies
(e.g. - what C++ features not to use) without having any significant
benefits from the port. Quite a lot of work, with *no* benefits.
It only makes sense to consider C++ *if there is to be a substantial
redesign* to take advantage of some C++ features.
And where *that* leads is to what amounts to a completely new project.
It's not Linux; it's "C++nix." If you want to do this, feel free, but
take it to comp.os.research or some such place, not here.
--
quit When the quit statement is read, the bc processor
is terminated, regardless of where the quit state-
ment is found. For example, "if (0 == 1) quit"
will cause bc to terminate.
(Seen in the manpage for "bc". Note the "if" statement's logic)
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 02:44:05 GMT
Centuries ago, Nostradamus foresaw a time when Oliver Bandel would
say:
>Is it really a problem to use higher level-ed languages only in
>higher levels/layers?
It would be nice to have *some* degree of integration to support some
of the features that higher level languages use.
For instance, most modern languages offer garbage-collected memory
management, and it would be attractive to have the OS provide some
support for this.
Alternatively, it might be nice to have the OS implementation language
be extendable (ala Lisp via macros) so that in those places where the
kernel requires that data structures be synchronized, that there be a
control structure available that does this *automatically.*
Case in point... There has, of late, been minor "flame war" going on
over the integration of ReiserFS with the Official Linux Kernel source
stream. The controversy surrounds the "proper use" of the VFS layer;
apparently VFS functionality has changed, and ReiserFS isn't "playing
nicely" with it.
The Lisp Way of coping with this would be to create some macros that
would represent one's interface to the VFS, and enforce the "correct
use" of VFS. (At least to some degree.)
This would amount, in a C-like syntax, to having a new control
structure like unto while {} or case {}, where it would toss in the
needed "bookkeeping" code to manage locks, synchronization, or
whatever.
vfs_operation {
do_this();
do_that();
if (error_condition())
vfs_roll_back(); break;
}
}
And have this toss in the fruit salad of additional commits, writes,
syncs, and whatever else might be needed to support having this
conform to the "VFS standards."
>Put a layer on top of the (high-performant) kernel, providing
>the abstraction you miss (instead of put the higher level
>things in the kernel like a fat person pressing into a small jeans.
>It looks ugly and the jeans explodes if that person does his first
>move...).
There may be a place for either:
a) Pushing functionality into the kernel to guarantee atomicity;
b) Pushing functionality into the kernel to improve performance.
[And I'm *quite* aware that the latter is *not* guaranteed; pushing a
GUI into the kernel is the classic example of something would *not*
necessarily have positive effects on performance.]
>Modularity and layers are the flexible concepts/ideas.
>
>The problem most people have with so-called-non-OO-Kernels
>is (even if this kernels use a lot of OO-ideas, but aren't
>written in their hype-language C++) is, that they have to use
>system-near functions instead of libraries (or are they looking
>for a good application software instead?).
Actually, the problem that people tend to have with kernels not
written using whatever language they're "hyping" is the very fact that
it's not the language they're "hyping."
People take a course on C++, and part-way through (it's mid-March
right now...), after having 2.5 months of exposure to C++, decide that
all of computing should be recast in light of their 2.5 months of
exposure to C++.
>The OO-Hype-people often says: it's easier to develop with
>the inheritance-concept, because of code-reuse.
>But why aren't there libraries, providing the missed
>functionality?
It is a major *fallacy* that OO results in code reuse.
What results in code reuse is the notion of *genericity,* which is
*not* the first thing that gets taught, and with the limited support
C++ implementations have tended to have for templates, it may be the
*last* thing that people are likely to learn...
>If there are no ideas what one want to do, there is no need
>to select a(ny) language.
"What is the purpose of a person acquiring perfect French
pronunciation if they have nothing of value to say in any language?"
-- Walter Ong
>Not the language solves the problems; it's the programmer;
>and the programmer only solve the problem, if he has an
>idea about what the problem is. And therefore there have
>to be problems at all.
The "let's rewrite Linux in C++" thing is more of a solution looking
for a problem than anything else.
>It's ok to think about maybe optimzing kernels by using other
>languages; but I think it's more practical and effective, to chose or
>develop a librarie, which provide missed (really missed?) features.
Anyone that wants to create a kernel using some other language should
absolutely try to do so.
There are efforts going on in FORTH, Modula-3 (if I were to suggest
rewriting Linux in something else, Modula-3 would be high on my list),
Scheme, ML, and likely others.
Anyone that would realistically lead a migration of Linux to some
other language needs to prove their credibility in two ways:
a) Creating/porting a kernel into the desired language.
That would prove that they have sufficient competence in the language
in question to make valid claims about its abilities as a systems
programming language.
b) Building changes, *in C,* for Linux, that are integrated into the
official source tree.
*That* would establish that the individual has competence and
understanding in the way that Linux is implemented, in C.
The person that has established BOTH of these "proofs of competence"
would then have established sufficient credibility that it would make
*some* sense for people to believe their claims that they could redo
Linux in (say!) Fortran. (Note that is distinct from FORTRAN, which
would be exceedingly unsuitable to the task...)
>...or extend the kernel's functionality; extending the functionality
>is not the same as using an other programming language (with
>more overhead).
>The functionality must be implemented by the programmer.
>And if you want a small and fast kernel, it's the best way
>to use as much as needed, but as less as possible.
Actually, I'll take a contrarian view to this.
Linux is *not* a "small" kernel, and "small" is *not* synonymous with
"fast."
- QNX is a small kernel.
- ECos is a small kernel.
Linux is a moderately big kernel, and when "big" means that you have
tables in memory that track useful things so that they do not need to
be continually recalculated, or pushed from process to process, BIGGER
CAN BE BETTER.
X gets bashed for being big; the vast majority of the memory that X
consumes represents caches that contain graphical objects, which
diminishes the amount of recalcs that have to be done when you move
windows around. When you've got the memory, THAT CAN BE WORTHWHILE.
I don't mind seeing the Linux kernel grow bigger when this either
provides useful utility, or allows the use of optimizations that trade
off memory for time. More memory consumed, but less calculations that
get *redone.*
--
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2000 02:44:06 GMT
Centuries ago, Nostradamus foresaw a time when Frank V. Castellucci
would say:
>Personally, I have a problem with talk of C++ exceptions used in the
>context of a kernel. Whereas an application can elect to either continue
>operating or exit the application, only under EXTREME circumstances
>(like work that hasn't been completed to handle the situation where it
>just stops) does a OS have that as an option, not a robust one anyway.
>
>I also don't like the idea of using C++ exceptions to control the flow
>of execution.
... And this is exactly what really irritates me about C++
exceptions. [Ditto for Java...]
There's a sort of schizophrenia about them, where some people seem to
think that they should be only used for "critical errors," whilst they
appear to be designed to provide an event-based control structure.
They provide some of the functionality that CL catch/throw provide,
but the lack of GC'ed memory management means that either allocating
or destroying objects in them is, um, not particularly safe, and quite
tedious.
--
Q: If toast always lands butter-side down, and cats always land on
their feet, what happens if you strap toast on the back of a cat and
drop it?
A: it spins, suspended horizontally, a few inches from the ground.
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: "Tae-sung Kim" <[EMAIL PROTECTED]>
Subject: [Q] LILO question?
Date: Tue, 14 Mar 2000 11:53:11 +0900
Why boot sector loaded at 0x07C00 copy itselt to 0x9A000?
0x07C00 is determined by ROM-BIOS&PENTIUM, I guess.
But, 0x9A000 has any special meaning?
I'm porting linux for MIPS based board which is our proprietary
architecture without hdd.
RAMDISK will be our sulution for running linux on diskless system.
Anybody have good site for this kind of approche.
I already checked Linux Router Project.
No floopy, no disk makes it hard to proceed.
Thanks
--
====================
Tae-sung Kim
Engineer, R&D Center
MEDIALINCS Co., Ltd.
1F Keopyung B-Town,203,Nonhyun-dong,Kangnam-gu,Seoul,135-010,Korea
TEL: +82-2-3446-8119(ex.353) FAX: +82-2-3446-8288
EMAIL: [EMAIL PROTECTED]
AOL : CORBA20
------------------------------
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: Uhhuh. NMI received for unknown reason 3c/2c/3d/2d
Date: Mon, 13 Mar 2000 20:59:03 -0800
Jerry Natowitz wrote:
>
> I occasionally get between 1 and 15 messages like the following:
> Uhhuh. NMI received for unknown reason 3d.
> Dazed and confused, but trying to continue
> Do you have a strange power saving mode enabled?
>
> I am running a Tyan 1854 with a P3 500E O/c to 667. I have PC133 SDRAM.
> I am currently running 2.3.50.
> I have PM and ACPI disabled in BIOS and otherwise have a rather normal setup.
> I don't get any crashes or hangs, at least in Linux - Windoze is a whole
> 'nother issue.
>
> If I enable IO-APICS the kernel will panic when I get one of these. Lowering
> my bus speed from 133 to 124 didn't make a difference, and in fact I think
> I saw a couple of these when I wasn't even overclocked.
Is your hardware OK? Try out my `cpuburn` package to test the CPU
and RAM/controller.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
------------------------------
** 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
******************************
