Linux-Development-Sys Digest #762, Volume #7 Wed, 12 Apr 00 13:13:25 EDT
Contents:
Re: How compatible is Linux with .. Linux (aflinsch)
Re: Read combining on memory-mapped I/O? (Pasi Savolainen)
Re: Modules versions and insmod -f (Pasi Savolainen)
Re: How compatible is Linux with .. Linux (aflinsch)
Re: To core or not to core - You tell me (mike burrell)
Re: Idea !!! (Pasi Savolainen)
Re: Help: problem on interupt handling (Martin Gruber)
?: Serial-only Linux box problems (Dave Newton)
Re: To core or not to core - You tell me (Dima Volodin)
Re: catching signals for bad stack (Kaz Kylheku)
Re: How compatible is Linux with .. Linux ("The Wogster")
Re: Bootdisks, rdev, and root filesystems...aargh! (bob smith)
Re: readline() (Philip)
Re: Idea !!! ("The Wogster")
PCI soundcard driver ("Hung P. Tran")
Re: How compatible is Linux with .. Linux (Michael Wojcik)
Re: Alternative OS Implementation Languages (Ed Carp)
Re: Random system hangs on Compaq P166/2.2.14 (Bill Hayles)
----------------------------------------------------------------------------
From: aflinsch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Wed, 12 Apr 2000 10:20:39 -0500
"Peter T. Breuer" wrote:
>
> So could one do pipes?
>
Not really, but the system was never designed to do so either. I can
think of a way to implement a rather perverse simulation of named
pipes for online processing (CICS & and tsqueues), however.
------------------------------
From: Pasi Savolainen <[EMAIL PROTECTED]>
Subject: Re: Read combining on memory-mapped I/O?
Date: Wed, 12 Apr 2000 17:40:32 +0300
David Ellsworth wrote:
> As for #2... it seems I need to patch the kernel. But where do I start? I'm
> hoping all I need to do is add a range check somewhere. But where?
I really don't know much about this thing, but one place to look at
things is kernels MTRR section and, of course, framebuf code. especially
matrox one as it seems to be most well written.
hope-this-did-help-you
pasi
------------------------------
From: Pasi Savolainen <[EMAIL PROTECTED]>
Subject: Re: Modules versions and insmod -f
Date: Wed, 12 Apr 2000 17:48:44 +0300
Mark McDougall wrote:
> I've developed a driver which is to be distributed in binary form (not
> my call). I've compiled in versioning support under 2.2.5-15.
plain source is best redistribution format =)
> on demand - but doesn't work under 2.2.12. I'm assuming this is related
> to the insmod problem/warning!?!
As far as I can tell, the kernel (since 2.1.something) have a load-on
demand (kmod) module. I guess you just have to compile it in.
It's just that I've had boot message telling that kerneld isn't loading
because there's kmod builtin.. didn't had tiime to rewrite the startup
script...
best,
pasi.
------------------------------
From: aflinsch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Wed, 12 Apr 2000 10:31:27 -0500
The Wogster wrote:
>
>
> I will admit that JES JCL could win an ugly contest, I usually worked with
> VSE JCL, and it was a lot easier to work with. The advantage with JCL was
Easier to work with than MVS JCL, and a simpler syntax also, but with
greater device dependencies. MVS removed device dependency.
> that you could point a COBOL program to a different dataset, without having
The way to do that in Linux (and other non big blue COBOLs), would be
to set an environment variable equal to a filename, then look at the
value of the variable from within the program. I suppose that under
COBOL, one would need to diddle with the code for the
SELECT/ASSIGN/FD/OPEN statements. But first wee would need a GNU
COBOL. I seem to recall a project to develop one a while back, but
have not heard about it in a while.
> to recompile the program, and that was a nice feature. I wonder if it's
> possible to port VSE JCL over to Linux, would be nice for running batch
> stuff.
Actually, the conditional execution features would be even more handy.
------------------------------
From: mike burrell <[EMAIL PROTECTED]>
Subject: Re: To core or not to core - You tell me
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Date: Wed, 12 Apr 2000 14:54:21 GMT
In comp.lang.c Ron Natalie <[EMAIL PROTECTED]> wrote:
> Mark McIntyre wrote:
>> Not quite. It must only compare equal to (int)0 when cast to int
>> (either explicitly or implicitly). It may be represented by all-ones
>> or all zeros or half of each.
> It's the other way, it's the 0 that is converted to the pointer type
> for the comparison (by virtue of it being a null pointer constant).
this is a question of implementation.
> It is not required that casting a null pointer to int return any
> specific value (at least in C++, where it says the mapping is implementation
> defined).
if i'm not mistaken, casting in C (and presumably C++) works by value, not
by bit representation. if that's true, one would expect (int)((void *)0) to
be the same on all platforms.
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]
X AGAINST HTML MAIL
/ \
------------------------------
From: Pasi Savolainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Idea !!!
Date: Wed, 12 Apr 2000 17:58:11 +0300
The Wogster wrote:
> A better mechanism might be for Linux, BSD, SCO, Solaris to bind together
> with a common driver interface.
This is where Linus draws the line. He wants to keep driver
interface/API fully flexible, no guaranties that it doesn't change in
next prepatch. And he is totally right. If he'd freeze the api, it'd
take too long for some functions to come to kernel.
best,
pasi.
ps. no-one is stopping one from writing
per-kernel-version-call-translator that'd translate function calls...
but i'm blabbing again.
------------------------------
From: [EMAIL PROTECTED] (Martin Gruber)
Crossposted-To: linux.dev.kernel
Subject: Re: Help: problem on interupt handling
Date: Wed, 12 Apr 2000 17:42:22 +0200
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
Guillaume Lorand <[EMAIL PROTECTED]> writes:
>
> --------------11F00DA8C6694B012FA443FB
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
PCI-Interrupts are level-sensitive so if you don't erase
the cause of the interrupt in your Interrupthandler, Linux
will enter the interrupthandler again and the system hangs!
------------------------------
From: Dave Newton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.questions,comp.os.linux.misc,comp.os.linux.development
Subject: ?: Serial-only Linux box problems
Date: Wed, 12 Apr 2000 15:46:47 GMT
Hi,
I'm currently working with RedHat 6.0 (product requirement for now),
kernel vesion 2.2.5-15 (same). I've recompiled the kernel to allow for a
serial console.
My lilo.conf file has a "serial=1,9600n8" line in the 'global' section
and a 'append="console=ttyS1,9600"' line in the kernel section (of the
kernel in question).
Here's my questions:
1) I'm not getting any input from the serial terminal. Is this a kernel
or configuration issue? The serial cable should be good as I have had it
successfully running getty. (It isn't now.)
2) Should I or should I not be getting the console login prompt on my
serial terminal? I thought I should. Is a serial console only good for
the console messages but not the console login? Is there another way to
get this to work properly (i.e., perhaps my modifying /etc/inittab to
run mingetty on the serial port in question)? I also need to have root
be able to log on over the serial port, but I remember seeing something
about that a long time ago WRT telnet root access.
3) Is the answer to #2 dependant on whether or not there is a VGA card
in the system? (I have tried it with or without; I never get a console
login prompt on the serial terminal.)
4) Am I truly limited to 9600 baud? I really need 57600 due to system
constraints. Is this because it's using the PC BIOS serial routines? If
so, if I have serial port routines in the BIOS that allow greater rates
can I hack the kernel source to allow the higher speeds?
Thanks much,
Dave Newton
------------------------------
From: Dima Volodin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 11:55:10 -0400
Floyd Davidson wrote:
>
> Dima Volodin <[EMAIL PROTECTED]> wrote:
> >Floyd Davidson wrote:
> >
> >> The macro NULL must be a null pointer constant, which is either
> >> an integral constant expression of value 0 or such an expression
> >> cast to a void*. (In other words, it has an all 0 bit pattern.)
> >
> >There's no requirement that ((void*)0) produced all 0 bit pattern.
>
> Yes there is. It is a *null pointer constant* with a value of 0,
> and will not be _converted_ to a null pointer unless it is compared or
> assigned to a pointer type.
There are no any requirements as of to what bit patterns any pointer
type should use, void* or no void*. And there's no requirement that
casting an integer (0 or otherwise) to void* be a no-op.
> The *null pointer* is what is not required to be an all 0 bit pattern.
> Floyd L. Davidson [EMAIL PROTECTED]
Dima
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: catching signals for bad stack
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Apr 2000 16:12:27 GMT
On Wed, 12 Apr 2000 14:27:38 +0200, Henning <[EMAIL PROTECTED]> wrote:
>So my problem is, that no signal handler is called when the stack is
>empty.
>How can I manage to catch the signal, unset the limit in signal handler
>and continue my server as usual?
>
>Does anyone has an idea?
sigaltstack
------------------------------
From: "The Wogster" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Wed, 12 Apr 2000 12:37:53 -0400
aflinsch wrote in message <[EMAIL PROTECTED]>...
>The Wogster wrote:
>
>>
>>
>> I will admit that JES JCL could win an ugly contest, I usually worked
with
>> VSE JCL, and it was a lot easier to work with. The advantage with JCL
was
>
>Easier to work with than MVS JCL, and a simpler syntax also, but with
>greater device dependencies. MVS removed device dependency.
>
>> that you could point a COBOL program to a different dataset, without
having
>
>The way to do that in Linux (and other non big blue COBOLs), would be
>to set an environment variable equal to a filename, then look at the
>value of the variable from within the program. I suppose that under
>COBOL, one would need to diddle with the code for the
>SELECT/ASSIGN/FD/OPEN statements. But first wee would need a GNU
>COBOL. I seem to recall a project to develop one a while back, but
>have not heard about it in a while.
I think there is a GNU COBOL project out there, COBOL is a very high level
language, so the compiler is going to be a pain in the donkey....
>> to recompile the program, and that was a nice feature. I wonder if it's
>> possible to port VSE JCL over to Linux, would be nice for running batch
>> stuff.
>
>Actually, the conditional execution features would be even more handy.
With programmable shells, it's almost as easy anyway, it's just the file
redirection capabilities, hopefully the GNU COBOL project will consider
doing something similar to file redirection.....
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.misc
From: bob smith <[EMAIL PROTECTED]>
Subject: Re: Bootdisks, rdev, and root filesystems...aargh!
Date: Wed, 12 Apr 2000 12:43:29 -0400
Take a look at this how-to, linux from scratch how-to, found at:
http://www.linuxdocs.org/LDP/LGissue49/misc/beekmans/LFS-HOWTO.html
Really great.
/Ugge
On Wed, 5 Apr 2000, Michael Westerman wrote:
> hava look at tombst.
>
> a single linux on a disk dist'n it even give instructions on customising it.
> includes kernel and compressed ramdisk image chokablock with utils.
>
> his web sight may help.
>
> Neil Koozer <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Don Werve wrote:
> > >
> > > Ok. After reading the Bootdisk-HOWTO and rdev manpages, I decided to
> > > start on the path to true geekdom and make my own Linux bootdisk, so
> > > that I could manually build a Linux system from the ground up on one of
> > > my many spare computers. I've been using Linux for about two years now,
> > > but what better way to learn about the guts of the OS than to manually
> > > build a full system?
> > >
> > > Anyways, I made a root filesystem that compressed takes up 900K, and
> > > have a 460K kernel. I used dd to copy the kernel image to the disk, and
> > > then used `rdev /dev/fd0 /dev/fd0 ; rdev -R /dev/fd0 0` to set the disk
> > > as it's own root device. How do you tell the kernel where to look for a
> > > compressed root filesystem, so that it can be uncompressed into a
> > > ramdisk and booted...?
> > >
> > > Ideas? Sorry about the cross-post, but it seemed applicable to each
> > > newsgroup posted to. Please reply via E-Mail, to hari AT iveleague.org
> > >
> > > Thanks in advance! :)
> >
> > This is in the "Setting the ramdisk word" section of the Bootdisk-HOWTO.
> >
> > For a 2-disk boot/root pair, you would use
> > rdev -r /dev/fd0 49152
> > 49152 is 0xc000
> >
> > For a single boot/root disk you would use 0x4000 + the offset to the
> > start of the compressed ramdisk image. The offset is the number of 1k
> > blocks.
> >
> > Neil
>
>
>
------------------------------
From: Philip <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: readline()
Date: Wed, 12 Apr 2000 16:50:37 GMT
> you can't - in ANSI C (it's an faq in comp.lang.c)
And in Linux ?
--
Philip van Hoof aka freax _/_/_/
http://users.pandora.be/skatan _/_/ _/ _/_/ _/_/_/ _/_/ _/ _/
mailto:[EMAIL PROTECTED] _/_/ _/ _/ _/ _/ _/ _/ _/
I could be bought, but Linux_/_/_/_/ _/ _/ _/_/ _/_/_/_/ _/_/
couldn't be. (Linus Torvalds _/_/ _/ _/ _/ _/ _/ _/
8 Sept. 1996) _/_/ _/ _/_/_/ _/ _/ _/ _/
------------------------------
From: "The Wogster" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Idea !!!
Date: Wed, 12 Apr 2000 12:49:03 -0400
Pasi Savolainen wrote in message <[EMAIL PROTECTED]>...
>The Wogster wrote:
>> A better mechanism might be for Linux, BSD, SCO, Solaris to bind together
>> with a common driver interface.
>This is where Linus draws the line. He wants to keep driver
>interface/API fully flexible, no guaranties that it doesn't change in
>next prepatch. And he is totally right. If he'd freeze the api, it'd
>take too long for some functions to come to kernel.
>
>best,
>pasi.
>
>ps. no-one is stopping one from writing
>per-kernel-version-call-translator that'd translate function calls...
>but i'm blabbing again.
A properly written common driver interface (CDI), would leave implementation
to the kernel team, if they want to write it as a translator, then it
becomes a library that gets loaded when a driver needs it. The kernel team
could also just implement the interface right into the kernel. The ideal is
that a hardware vendor could write a driver, using the CDI and offer quick
support to a number of platforms. The 13,000,000 Linux users might not be
enough, but add in the 1,000,000 *nix users and it might just be. The user
knows that all CDI drivers get put in a certain place in the directory tree,
and the driver starts by calling a function in the CDI.
------------------------------
From: "Hung P. Tran" <[EMAIL PROTECTED]>
Subject: PCI soundcard driver
Date: Wed, 12 Apr 2000 16:49:56 GMT
Hi,
Anyone knows of a linux PCI soundcard driver. I have a
PCI based audio (ESS 1698S) in particular running under RedHat 6.1.
Thanks,
hung
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 12 Apr 2000 15:58:01 GMT
Reply-To: [EMAIL PROTECTED]
[Followups restricted to comp.os.linux.development.apps, which strikes
me as the marginally more appropriate group.]
In article <Mt_I4.6098$[EMAIL PROTECTED]>, "The Wogster"
<[EMAIL PROTECTED]> writes:
> I will admit that JES JCL could win an ugly contest, I usually worked with
> VSE JCL, and it was a lot easier to work with. The advantage with JCL was
> that you could point a COBOL program to a different dataset, without having
> to recompile the program, and that was a nice feature. I wonder if it's
> possible to port VSE JCL over to Linux, would be nice for running batch
> stuff.
As far as COBOL programs go, the only COBOL implementation I know of
on Linux (ours) already provides a DD-style filename indirection
method.
In general, though, JCL isn't terribly well suited to batch
processing in a Unixy environment; it would need to be extended in
various ways to deal with Unix filesystem constructs, process model,
etc.
It wouldn't be hard to put together a similar facility using the
native tools. (For batch scheduling, for example, AIX came with a
sample "printer queue" that actually just ran sh on the input under
the appropriate UID, much as atrun does, except on a continual
basis.)
I'd be surprised if there aren't already several free batch execution
environments available for Linux with various bells and whistles.
Sounds like just the sort of thing to attract the Perlists.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Therefore, it is possible to enjoy further by using under the
Netscape 2.0. However, Netscape will hangup at sometimes. You
should give it up. -- roro
------------------------------
From: Ed Carp <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Alternative OS Implementation Languages
Date: Wed, 12 Apr 2000 11:58:39 -0500
Dale Pontius wrote:
> As long as we're mentioning languages other than C, I feel the need
> to bring up Ada. It's interesting that most languages are designed
> to ease the development process. Ada wasn't. It was designed to ease
> the maintenance process, instead. There's a fundamental recognition
> that most of the software cost of imbedded programming is in the
> maintenance, not in the initial development. Since imbedded programming
> is the targeted market for Ada, they attack maintenance. As a side
> effect, one could argue that Ada (and strongly typed languages, in
> general) attacks the debugging problems as much as the maintenance
> problems.
Ada has such strict typing that it's pretty much a given that, if your
code compiles, it'll run without any run time exceptions ;)
------------------------------
From: Bill Hayles <[EMAIL PROTECTED]>
Crossposted-To: uk.comp.os.linux
Subject: Re: Random system hangs on Compaq P166/2.2.14
Date: Wed, 12 Apr 2000 13:12:42 +0200
Reply-To: [EMAIL PROTECTED]
On 11 Apr 2000 13:20:27 +0100, Nix <$}xinix{[email protected]> wrote:
>Bill Hayles <[EMAIL PROTECTED]> writes:
>
>> I'm running the same model (but with 32Mb and no ISDN card) as my server
>> here using SuSE 6.3 and it's been up for weeks. I doubt it's
>> overheating - that's the way Compaq built the things, and there's a good
>> air flow around the processor. As an off-the-wall diagnosis, I'd
>> suspect an iffy 64Mb RAM chip.
>
>What I'm wondering is which component is at fault in one of the boxes
>here.
I wish I could help you further, but you've done everything I'd do
before tearing my hair out in frustration!!
>
>It crashes every so often, and a memtest86 soon reveals the problem; if
>you write 0xFFFFFFF8 to a RAM chip, you should get that back, not
>0xFFFFFFFF. Every single-flipped-bit surrounded by 1-bits or 0-bits
>flipped state.
All I can think of is that this is some sort of parity problem, but I'm
groping in the dark and getting out of my depth (to mix metaphors).
Since this no longer appears to be a Linux specific problem, maybe one
of the gurus in alt.sys.pc-clone.compaq might be able to help.
>From Benitachell, Alicante, Spain
Bill Hayles
[EMAIL PROTECTED]
------------------------------
** 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
******************************
