Linux-Development-Sys Digest #670, Volume #7 Sat, 11 Mar 00 00:13:06 EST
Contents:
Re: Linux or Windows (Paul Jackson)
Re: Linux or Windows (Paul Jackson)
Re: Kernel Module Problem (orion22) (Jeff Biviano)
Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)? (Robert Redelmeier)
Re: FastTrak66 driver? (Mario Michele Macaluso)
How to re-create a boot disk (Tony Wiegand)
Re: Fieldbuses ([EMAIL PROTECTED])
Re: kernel in C++ (Mark Hahn)
Re: kernel in C++ (Mark Hahn)
Re: LILO and GRUB: where do you pick disk geometry from? (repost) (John in SD)
Re: kernel in C++ ("Frank V. Castellucci")
Re: kernel in C++ (Christopher Browne)
S-Link Device Driver - slink.tgz (0/1) ([EMAIL PROTECTED])
Re: kernel in C++ (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Subject: Re: Linux or Windows
Date: 10 Mar 2000 23:27:36 GMT
"Mark Tranchant" <[EMAIL PROTECTED]>
> and 4: a CONFIG.SYS menu, combined with LOADLIN
Yes - another good alternative
If you want to get fancy in the config.sys menu
arena, consider:
BOOT.SYS - a fine old classic tight DOS-style
config.sys menu utility, which I used to
depend on totally, until System Commander.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Subject: Re: Linux or Windows
Date: 10 Mar 2000 23:48:26 GMT
Or yet another choice:
5) VMware - see www.vmware.com - lets you boot both
Linux and Windows at the same time. You can boot Linux
as your base "host" operating system, and run Windows as a
"guest" os, for specific apps (devices need for games not
well supported) in a window, right on your Linux desktop.
Then when that Windows crashes, you "reboot" that Window,
while your host Linux keeps on ticking. If you don't mind
adding enough memory to avoid swapping with both Linux
and Windows present at the same time, then this is the
cat's meow.
I am currently in the process of switching my System
Commander and BootMagic setups to VMware (about $100
personal license per system, or about $300 per system on
my work machines, which are "for profit", in the terms of
VMware's license).
If you have enough disk and memory, you can run several
guest Linux and Windows boots at the same time.
Unlike WINE (an open source Linux Windows emulator),
VMware provides a highly compatible environment for
guest os's, with only specific hardware (like certain
SCSI setups, fancier sound cards, game controllers)
listed in the "limitations".
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: Jeff Biviano <[EMAIL PROTECTED]>
Subject: Re: Kernel Module Problem (orion22)
Date: Sat, 11 Mar 2000 00:00:19 GMT
Francisco Obispo wrote:
> 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
Try turning on the optimizations like this:
gcc -D__KERNEL__ -DLINUX -DMODULE -DMODVERSIONS -Wall -O2
- Jeff
------------------------------
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)?
Date: Fri, 10 Mar 2000 18:04:06 -0800
[EMAIL PROTECTED] wrote:
>
> 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 consider an hour minimum for stability, with at least 2 * #CPU
copies of `burnP6` running. For burnBX, I like 4 * #CPU processes,
at least overnight. Some errors are rare.
> 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....
Yes, please tell us/me more. If there's some repeatable process,
then it points to software [kernel] we need to fix it.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
------------------------------
From: [EMAIL PROTECTED] (Mario Michele Macaluso)
Subject: Re: FastTrak66 driver?
Date: Sat, 11 Mar 2000 00:18:16 GMT
On 10 Mar 2000 10:51:17 +0100, Vetle Roeim <[EMAIL PROTECTED]> wrote:
>* Harvey Taylor
>> Hi,
>> Does anybody happen to know about any Promise FastTrak66
>> driver development happening?
>
>what's that? a Ultra66 controller?
Yes and not at the same time.
Yes: it is an ultra66 dma controller
Not: it is a *RAID* ide controller
look at http://www.promise.com
No, I don't know nothing about his support, but, is a good idea to ask
directly to Promise.
michele
--
Mario Michele Macaluso | Distress, n.: A disease incurred by
m.macaluso .@. libero.it | exposure to the prosperity of a friend.
-o) | -- Ambrose Bierce, "The Devil's Dictionary"
/\\ |
Kernel 2.0.36 on a i586 _\\_v |
(All addresses in headers are fake. Only one dot in signature.)
------------------------------
From: Tony Wiegand <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.misc
Subject: How to re-create a boot disk
Date: Sat, 11 Mar 2000 01:38:07 GMT
Here's my story. I have to disks, the first disk has windows installed
and
the second disk has linux installed. I'm running Mandrake 6.0. When I
installed Mandrake, LILO had a problem. So I re-installed windows into
the Master boot record and booted to linux with the boot disk. Now my
boot disk is screwed up and I can't get back to Linux.
I tried downloading the boot.img from Red Hat, but it just tries to do a
re-install of the OS.
Any help would be appreciated.
Thanks,
Tony
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Fieldbuses
Date: Sat, 11 Mar 2000 01:43:04 GMT
Jeff:
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jeff McWilliams) wrote:
> While we're at it, how about support for Allen-Bradley DataHighway+ ?
> I'd love to be able to talk to a PLC-5 from a Linux box.
>
> Jeff
How about checking out the work I have done on this. I have a driver set (open
source) for talking to AB PLC5's, SLC's, and Pyramid Integrators. The only caveat
right now is my project is only Ethernet, but I am currently working on adding RS-232
support. Supporting DH+ (via a KT card) will be a distant aim.
The project can be downloaded from:
http://freshmeat.net/appindex/1999/11/07/941993013.html
Ron Gage - Saginaw, MI
([EMAIL PROTECTED])
>
>
>
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: 11 Mar 2000 02:20:37 GMT
> You can't write a kernel in C++ or C. That is to say, if you take the ISO C or
> C++ standard and stick to the language features described there, you won't get
> anywhere.
this is quite wrong, since it assumes that there are hardware constructs
that can't be addressed with standard-conforming C. that assumption is
certainly true for some hardware, but not necessarily all possible hardware.
<long sermon against C++ omitted>
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: 11 Mar 2000 02:30:37 GMT
> A C++ interface, and abstraction of key parts is quite desirable.
mere syntactic sugar.
------------------------------
From: John in SD <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: LILO and GRUB: where do you pick disk geometry from? (repost)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 03:31:28 GMT
If your BIOS supports the EDD packet call interface then LILO 21.3
will be of some help to you. This release was announced on 3/8/00
(comp.os.linux.announce). It is also at: ftp://sunsite.unc.edu
/pub/Linux/system/boot/lilo
--John Coffman <[EMAIL PROTECTED]>
On 07 Mar 2000 07:52:05 +0000, [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
------------------------------
Date: Fri, 10 Mar 2000 23:35:20 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Mark Hahn wrote:
>
> > A C++ interface, and abstraction of key parts is quite desirable.
>
> mere syntactic sugar.
A typical response.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 04:36:57 GMT
Centuries ago, Nostradamus foresaw a time when Frank V. Castellucci would say:
>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.
>
>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++.
What "FUD factor" are you talking about?
There were none of the (typical) salacious comments about C++ being
"evil, bad, and bloated."
And:
>> Also the statement "C++ is too buggy to be taken into account" will
>> not hold for ever.
is not what someone trying to "FUD" C++ would say.
>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.
It's desirable *to you.*
It's manifestly clear that it is *NOT* desired by the people that
write kernel code.
<http://www.tux.org/lkml/#s1-4> provides some comments not dissimilar
to those above...
The point are thus:
1. Transforming Linux to C++ would be a Substantial Task.
If I hazarded a guess, the task of merely redeploying it to
*compile* using G++ would be liable to be a six month task, and be
problematic.
2. Time of breakage.
For the time during which the transformation is taking place, there
would be a considerable period of time during which the kernel
would be BROKEN. Not "a bit buggy;" not "with a few flaws."
BROKEN. As in CANNOT COMPILE.
3. Merely Recompiling in C++ is worthless.
It makes *no* sense to go through the effort of making it work
using G++ and *not* do some substantial redesign to take advantage
of C++ language features.
4. There are parts of C++ that would be troublesome.
new, vtables, and exceptions represent merely three of the things
where C++ expects to have some "external environment" out there to
manage things for it. These things would have to be
"bootstrapped."
This is a bit worse than with C.
5. Which Subset of C++ Should Get Picked?
Using the whole thing, with bits arbitrarily picked for use, would
be fairly disastrous.
But the process of building up a "policy document" of what bits of
C++ must, and must not, be used, would add a further task, and
would be highly flameworthy.
Note that all five of the above matters need to be resolved before you
get a functioning kernel. In effect, in order to get something that
might still be buggy, there's a huge amount of design work that would
have to be done.
I think it could *easily* take a year or more for there to be a
faintly usable result.
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.*
You want to write an OS kernel in C++?
_Feel free._
You want to use Linux 2.3.something as the initial code base?
_That's AOK. The Linux kernel uses the GPL, and thus you're free to
do that._
If you can attract a bunch of other people to work with you, _that's
great._
If, two years from now, you have a usable kernel, and it is fast
enough and stable enough that people want to use it rather than Linux,
it would be fair to offer congratulations.
BUT.
The people working on Linux are doing so in C, and prefer it that way.
And enough have enough experience with this that they're arrogant (and
somewhat justifiably so) enough to not care what some newcomer
blathering about C++ says.
You go write "C++nix", and when you get it working, you'll have enough
technical authority to tell them some merits and demerits of using C++
for the purpose from other than a purely academic perspective.
--
The only problem
with Haiku is that you just
get started and then
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED]
Subject: S-Link Device Driver - slink.tgz (0/1)
Date: Sat, 11 Mar 2000 04:40:28 GMT
A while back, I set to work writing a fairly simple device driver
for my Sony S-Link CD changers. After deducing the S-Link protocol,
which is simply TTL level serial, I built some simple hardware and
tied it to the interrupt pin on my parralel port. Once I fleshed out
the command set, it worked great... but here's the problem.
The S-Link decks appear to work with up to 16 byte packets, if you
send a command that's the biggest response you can expect. Now for
anything under a 16 byte packet my driver behaves flawlessly. It'll
recieve the serial data and decode it, stick it in a buffer and wait
for me to grab it from the driver. If I get a 16 byte packet however
it once again recives it, decodes it, sticks it in a buffer, however
then immediately closes the stream. For no apparent reason what so
ever, but it's like clock work. 16 bytes or up and it'll close the
stream all on its own.
So here's my question, what possible conditions within linux's
device driver support could cause it to close down the driver on me?
Are there some traps I'm hitting in the kernel that might trigger
this? The module stays loaded just fine, and I can easily reopen the
stream and for small packets it's still rock solid stable. I've read
Rubini's book in detail, and can find no mention of anything like
this. Does anyone have ideas? I wrote versions of the driver for
both 2.1 and 2.2 kernels and they both have identical symptoms. I'll
attach the driver source, which I know is slightly unorhtodox, but I
would love any and all ideas. I've been fighting with this for quite
a while now. Thanks.
Brian Behlendorf
[EMAIL PROTECTED]
Man will occasionally stumble over the truth,
but most times he will pick himself up and carry on.
-- Winston Churchill
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 04:50:35 GMT
Centuries ago, Nostradamus foresaw a time when Mark Hahn would say:
>> You can't write a kernel in C++ or C. That is to say, if you take
>> the ISO C or C++ standard and stick to the language features
>> described there, you won't get anywhere.
>
>this is quite wrong, since it assumes that there are hardware constructs
>that can't be addressed with standard-conforming C. that assumption is
>certainly true for some hardware, but not necessarily all possible hardware.
No, you can't write a kernel in standards-conforming C or C++.
Standards-conforming C and C++ programs run within an environment that
starts *before* you start main(), and which terminate (if they *do*
terminate) *after* main().
The standards only speak to what happens once you get to main(); they
do not provide the "boot up" environment in which the programs run.
With C, this means that programs *normally* depend on there being this
little library called "crt.o" or "gcrt.o" linked in to provide the
environment in which main() can run. These libs are about 1K in size;
they provide small, but crucial services.
With Objective C, the equivalent appears to be objcrt.a, which, on
Linux, appears to be about 55K of code to support Objective C
messaging.
With C++, there does not appear to be a direct equivalent; it appears
to leap straight to the Standard C++ Libraries, replete with exception
handlers, iostreams, and such.
At any rate, the given is that you *have* to have code that lies
outside the standards in order to supply an environment in which
"standard" code can execute. With C, that "outside" code is quite
tiny, so that there isn't much that lies between ordinary C and "the
real world" outside. With C++, the "environment" needs to be vastly
larger...
--
When you awake, you will remember nothing of what I have told you.
[EMAIL PROTECTED] - - <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
