Linux-Development-Sys Digest #761, Volume #7 Wed, 12 Apr 00 10:13:13 EDT
Contents:
Q: is there a free secure network filesystem for Linux? (Michael Pronath)
catching signals for bad stack (Henning)
Help: problem on interupt handling (Guillaume Lorand)
Adding functionality to Right-Click mouse button ("C. Gross")
Re: WRITE into sockets takes much time (Andreas Gies)
Re: How compatible is Linux with .. Linux ("The Wogster")
Re: How compatible is Linux with .. Linux ("The Wogster")
Re: Idea !!! ("The Wogster")
Re: To core or not to core - You tell me (Ron Natalie)
Re: To core or not to core - You tell me (Ron Natalie)
Re: Alternative OS Implementation Languages (Dale Pontius)
----------------------------------------------------------------------------
From: Michael Pronath <[EMAIL PROTECTED]>
Subject: Q: is there a free secure network filesystem for Linux?
Date: 12 Apr 2000 13:47:22 +0200
Is there a network filesystem, that has useful security features (i.e. not
NFS), and is free and open source available for Linux (i.e. not AFS) ?
What would you use for a small LAN, Home Office or so? Samba?
Michael
--
------------------------------
From: Henning <[EMAIL PROTECTED]>
Subject: catching signals for bad stack
Date: Wed, 12 Apr 2000 14:27:38 +0200
Hy folks (again),
I'm writing a sort of RPC-Server based on a propriatary protocol.
I have a process that loads shared libraries and executes a function.
I have a signalhandler to catch nearly all sorts of SEH-exceptions for
development and log reasons.
Now I want to be sure that no stack overflow can appear.
I use
==================snip==================
getrlimit(RLIMIT_STACK, &orlim);
rlim = orlim;
rlim.rlim_cur = some_small_value_for_testing;
setrlimit(RLIMIT_STACK, &rlim);
call_the_function();
setrlimit(RLIMIT_STACK, &orlim);
==================snap==================
to reduce the stack amount the function can use.
In my testalgorithm I call
==================snip==================
long throwstack(char* pcIn, unsigned short usLenIn,
char** ppcOut, unsigned short* pusLenOut)
{
loop();
return 0;
}
static void loop(void)
{
char szSpace[255];
memset(szSpace, 0, sizeof(szSpace));
loop();
}
==================snap==================
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?
------------------------------
From: Guillaume Lorand <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Help: problem on interupt handling
Date: Wed, 12 Apr 2000 14:51:37 +0200
==============11F00DA8C6694B012FA443FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear all
I intend to develop a Linux driver for a PCI board (based on the S5933
AMCC chip) under the kernel x86 version 2.2.9. Currently, I am able to
access to the different I/O registers in write/read mode without any
trouble (no hardware conflict).
Nevertheless, when I try to implement a interrupt handler which is used
by writing in a mailbox, the system crash. The IRQ 11
is not shared by other devices, so I guess it isn't a hardware issue
but could due:
- to the implementation (declaration, installation, etc. ??)
of the interrupt handler which currently does nothing.
- some mistake between my implementation, the kernel features
and/or the PCI handling.
CPU0
0: 323796 XT-PIC timer
1: 12031 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 30574 XT-PIC serial
5: 89255 XT-PIC eth0
8: 2 XT-PIC rtc
13: 1 XT-PIC fpu
14: 39115 XT-PIC ide0
15: 522776 XT-PIC ide1
The code below crash when I launch it with insmod.
Please could you give me recommendation/information on the subject.
Thanks in advance
Best Regards
Guillaume Lorand
[EMAIL PROTECTED]
This is my code :
#include <linux/module.h>
#include <linux/pci.h> /* pci mask */
#include <linux/sched.h> /* irq */
#include <asm/io.h> /* for inb(), outb() etc. */
#include "amcc5933.h"
struct pci_dev *pdev = NULL ;
void my_interrupt (int irq, void *dev_id, struct pt_regs *regs)
{
}
int init_module (void)
{
u_long iobase = 0 ;
u_long temp = 0 ;
if (!pci_present())
return -ENODEV ;
/* retrieve the PCI board's parameters */
if( (pdev = pci_find_device(0x1234,0x5678,pdev)) != NULL){
/* interrupt handler installation */
request_irq(pdev->irq,my_interrupt,SA_INTERRUPT,"testirq", NULL) ;
/* retrieve the base address of the I/O ports */
iobase = (pdev->base_address[0] & PCI_BASE_ADDRESS_IO_MASK) ;
/* reset the board */
outl( (S5933_MCSR_MAILBOX_FLAG_RESET |
S5933_MCSR_ADDON_FIFO_RESET |
S5933_MCSR_PCI_FIFO_RESET |
S5933_MCSR_ADDON_PIN_RESET),
iobase+0x3C );
outl(S5933_MCSR_READ_MULTIPLE_ENABLE, iobase+0x3C );
/* unmask interrupt */
temp = inl( iobase+0x38);
temp &= S5933_INTCSR_IN_MAILBOX_MASK;
temp |= S5933_INTCSR_INCOMING_INTERRUPT ;
outl(temp,iobase+0x38);
/* Write in the mailbox in order to known if the board is ready
(OpCode 0x00) */
outb(0x00,iobase) ;
}
return 0 ;
}
void cleanup_module (void)
{
/* release the IRQ */
free_irq(pdev->irq,NULL) ;
}
==============11F00DA8C6694B012FA443FB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dear all
<p>I intend to develop a Linux driver for a PCI board (based on the S5933
AMCC chip) under the kernel x86 version 2.2.9. Currently, I am able to
access to the different I/O registers in write/read mode without any trouble
(no hardware conflict).
<p>Nevertheless, when I try to implement a interrupt handler which is used
by writing in a mailbox, the system crash. The IRQ 11
<br>is not shared by other devices, so I guess it isn't a hardware
issue but could due:
<blockquote>- to the implementation (declaration, installation, etc. ??)
of the interrupt handler which currently does nothing.
<br>- some mistake between my implementation, the kernel features and/or
the PCI handling.</blockquote>
<tt><font size=-1>
CPU0</font></tt>
<br><tt><font size=-1> 0:
323796
XT-PIC timer</font></tt>
<br><tt><font size=-1> 1:
12031
XT-PIC keyboard</font></tt>
<br><tt><font size=-1> 2:
0 XT-PIC
cascade</font></tt>
<br><tt><font size=-1> 4:
30574
XT-PIC serial</font></tt>
<br><tt><font size=-1> 5:
89255
XT-PIC eth0</font></tt>
<br><tt><font size=-1> 8:
2 XT-PIC rtc</font></tt>
<br><tt><font size=-1> 13:
1 XT-PIC fpu</font></tt>
<br><tt><font size=-1> 14:
39115
XT-PIC ide0</font></tt>
<br><tt><font size=-1> 15:
522776
XT-PIC ide1</font></tt>
<p>The code below crash when I launch it with insmod.
<p>Please could you give me recommendation/information on the subject.
<p>Thanks in advance
<br>Best Regards
<p>Guillaume Lorand
<br>[EMAIL PROTECTED]
<p>This is my code :
<p><tt><font size=-1>#include <linux/module.h></font></tt>
<br><tt><font size=-1>#include
<linux/pci.h>
/* pci mask */</font></tt>
<br><tt><font size=-1>#include
<linux/sched.h>
/* irq */</font></tt>
<br><tt><font size=-1>#include <asm/io.h> /* for inb(), outb()
etc. */</font></tt>
<p><tt><font size=-1>#include "amcc5933.h"</font></tt>
<br>
<p><tt><font size=-1>struct pci_dev *pdev = NULL ;</font></tt>
<p><tt><font size=-1>void my_interrupt (int irq, void *dev_id, struct pt_regs
*regs)</font></tt>
<br><tt><font size=-1>{</font></tt>
<br><tt><font size=-1>}</font></tt>
<br>
<p><tt><font size=-1>int init_module (void)</font></tt>
<br><tt><font size=-1>{</font></tt>
<br><tt><font size=-1> u_long iobase = 0 ;</font></tt>
<br><tt><font size=-1> u_long temp = 0 ;</font></tt>
<p><tt><font size=-1> if (!pci_present())</font></tt>
<br><tt><font size=-1> return -ENODEV ;</font></tt>
<p><tt><font size=-1> /* retrieve the PCI board's parameters */</font></tt>
<br><tt><font size=-1> if( (pdev = pci_find_device(0x1234,0x5678,pdev))
!= NULL){</font></tt>
<p><tt><font size=-1> /* interrupt handler installation
*/</font></tt>
<br><tt><font size=-1>
request_irq(pdev->irq,my_interrupt,SA_INTERRUPT,"testirq",
NULL) ;</font></tt>
<p><tt><font size=-1> /* retrieve the base address of
the I/O ports */</font></tt>
<br><tt><font size=-1> iobase = (pdev->base_address[0]
& PCI_BASE_ADDRESS_IO_MASK) ;</font></tt>
<p><tt><font size=-1> /* reset the board */</font></tt>
<br><tt><font size=-1> outl( (S5933_MCSR_MAILBOX_FLAG_RESET
|</font></tt>
<br><tt><font size=-1>
S5933_MCSR_ADDON_FIFO_RESET |</font></tt>
<br><tt><font size=-1>
S5933_MCSR_PCI_FIFO_RESET |</font></tt>
<br><tt><font size=-1>
S5933_MCSR_ADDON_PIN_RESET),</font></tt>
<br><tt><font size=-1>
iobase+0x3C );</font></tt>
<p><tt><font size=-1> outl(S5933_MCSR_READ_MULTIPLE_ENABLE,
iobase+0x3C );</font></tt>
<p><tt><font size=-1> /* unmask interrupt */</font></tt>
<br><tt><font size=-1> temp = inl( iobase+0x38);</font></tt>
<br><tt><font size=-1> temp &=
S5933_INTCSR_IN_MAILBOX_MASK;</font></tt>
<br><tt><font size=-1> temp |= S5933_INTCSR_INCOMING_INTERRUPT
;</font></tt>
<p><tt><font size=-1> outl(temp,iobase+0x38);</font></tt>
<p><tt><font size=-1> /* Write in the mailbox in order
to known if the board is ready (OpCode 0x00) */</font></tt>
<br><tt><font size=-1> outb(0x00,iobase) ;</font></tt>
<br><tt><font size=-1> }</font></tt>
<p><tt><font size=-1> return 0 ;</font></tt>
<br><tt><font size=-1>}</font></tt>
<br>
<p><tt><font size=-1>void cleanup_module (void)</font></tt>
<br><tt><font size=-1>{</font></tt>
<br><tt><font size=-1> /* release the IRQ */</font></tt>
<br><tt><font size=-1> free_irq(pdev->irq,NULL) ;</font></tt>
<br><tt><font size=-1>}</font></tt>
<br>
<br> </html>
==============11F00DA8C6694B012FA443FB==
------------------------------
From: "C. Gross" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Adding functionality to Right-Click mouse button
Date: Wed, 12 Apr 2000 07:54:54 -0400
Hello All,
I would like to add functionality to the right-click mouse button.
I would like to add a menu item/action if a right-click is performed
on an desktop icon. For example, if I were to click on the icon of a
Star Office document in the KDE Home Directory file browser, I would
like to be able to select my own menu item, like a print command,
underneath the menu item "Delete" or "Copy" or "Move to Trash."
Does anyone know how to do this or if it is possible for us to add
this functionality in KDE and GNOME?
Thanks.
-- C
------------------------------
From: Andreas Gies <[EMAIL PROTECTED]>
Subject: Re: WRITE into sockets takes much time
Date: Wed, 12 Apr 2000 14:54:46 +0000
I'm glad, no more help required.
The reason for the blocking WRITE was the
time sharing of the processes.
Andreas
------------------------------
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 09:09:29 -0400
Peter T. Breuer wrote in message <8ctb9f$6cf$[EMAIL PROTECTED]>...
>In comp.os.linux.development.system The Wogster <[EMAIL PROTECTED]>
wrote:
>
>: Peter T. Breuer wrote in message <8clafc$o9p$[EMAIL PROTECTED]>...
>:>In comp.os.linux.development.system The Wogster <[EMAIL PROTECTED]>
>:>: Peter T. Breuer wrote in message <8ccqgp$eg2$[EMAIL PROTECTED]>...
>:>:>In comp.os.linux.development.system The Wogster
<[EMAIL PROTECTED]>
>:>:>: VMS, HPUX, AIX, Irix, MVS, VSE or other environment. Heck, three
years
>:>:>: ago, I could have asked the same question!
>:>:>
>:>:>OK, what IS the difference between VMS and MVS, then! Apart from the
>:>:>first letter (of their manufacturer).
>
>: Me, I don't wish to fight with anyone, just trying to make a point, this
>: thread when it began, had you accusing someone of asking a "dumb"
question,
>: because they didn't know something that you know. Now I have allways
>: thought that turning the tables in that case is "fair play" :-) 'Nuf
said,
>: I think the intended point has been received.
>
>Somehow I don't think so, in this case, at least. Note that *I* asked the
>"question" what is the difference between VMS and MVS! I'd equally
>well have asked the question "what is the difference between york and
>serrano ham". The point being that the difference might be of great
>importance to those who care, but it (1) doesn't matter two hoots here,
>because this isn't a ham newsgroup (;), and (2) I'm NOT PRETENDING TO
>be a person whose company is interested in supplying us with ham.
>
>
>:>So what is the difference between a mini and big iron then? Speak up
>:>... ;)
>
>: Mini's are smaller.... Of course now that a decent Micro has more power
>: then the initial mini's and big irons put together....
>
>:>: VMS: OS used by Digital Equipment Corporation on it's VAX series of
>:>: computers, these are classed as mini computers, very similar to Unix in
many
>:>: ways, really different in other ways. Best feature, smooth scrolling
on
>:>: text based terminals no less. Could be crashed by 45 College students
>:>: starting a COBOL compile at the same time.
>:>
>:>Not in the classical sense of crashing.
>
>: The system required that the operator restart the system, that sounds
like
>: crashing to me....
>
>Close enough.
>
>
>:>: MVS: OS used by International Business Machines on their biggest iron,
the
>:>: only similarity to Unix is the fact that it runs multiple users and
multiple
>:>: tasks at the same time. Best feature, you can actually run MVS as an
>:>: application under MVS (VM the other IBM Big Iron OS also has this
feature).
>:>: MVS (and VM) are almost totally crash proof I used to work with these
>:>: systems, and running for many months is common.
>:>
>:>I have run and worked under both. Both too long ago to even want to
>:>remember (memories of nights spent feeding tapes into the IBM 370
>:>between writing chess-playing programs in fortran scanned from incoming
>:>card decks). I never saw a crash, but planned downtime was common.
>
>: I liked the basis of the technology, if IBM would have built a micro370,
and
>: a trimmed down version of VM/370 instead of signing on with Microsoft, we
>: would all be using true blue systems for this stuff.
>
>Possibly. JCL was inflexible gobbledegook.
>
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.
------------------------------
From: "The Wogster" <[EMAIL PROTECTED]>
Subject: Re: How compatible is Linux with .. Linux
Date: Wed, 12 Apr 2000 09:12:10 -0400
John Alvord wrote in message <[EMAIL PROTECTED]>...
>On Mon, 10 Apr 2000 13:45:47 -0400, "The Wogster"
><[EMAIL PROTECTED]> wrote:
>
>>
>>John Alvord wrote in message <[EMAIL PROTECTED]>...
>>>On Fri, 7 Apr 2000 14:04:09 -0400, "The Wogster"
>>><[EMAIL PROTECTED]> wrote:
>>>
>>>>
>>>
>>>MVS under MVS is new to me (and I have been watching it since 1969).
>>>VM has the only virtualizing operating system in the IBM world.
>>>
>>>MVS also has a pretty good unix-posix services feature the last few
>>>years.
>>>
>>
>>
>>I have heard of MVS under MVS, so it must be technically possible, (how do
>>you test new patches, if production and test are on the same box,
>>otherwise).
>
>You are probably think of LPARs. That is a way you can divide a box
>into multiple independent operating machines. It is kind-of VM like,
>but is installed as a hardware feature, has much lower overhead and
>isn't as flexible. On a 10 CPU box you can have 8 dedicated to
>production and 2 dedicated to testing. I knew one of the fellows that
>worked on it, brilliant fellow.
Possibly, I didn't do a lot of work on the technical side with MVS, I don't
remember much about using it either, except that it tended to generate
innumerable HASP messages, usually timed so that as soon as you had what you
wanted on the screen up would come 15 HASP messages, so that it was scrolled
long by....
------------------------------
From: "The Wogster" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Idea !!!
Date: Wed, 12 Apr 2000 09:18:27 -0400
Oh Yuck, buggy Windows drivers, running under Linux. It's possible, you
would need some kind of emulation layer, is it reasonable, I hope not. This
is the kind of thing that killed OS/2, it did such a good job of emulating
Windows 3.0, that nobody wrote native programs for it. When Microsoft
changed the rules, it died because they could not emulate the newer version.
A better mechanism might be for Linux, BSD, SCO, Solaris to bind together
with a common driver interface.
Akbar Avliyaev wrote in message <8cvoar$svq$[EMAIL PROTECTED]>...
>The main problem of Linux is hardware support.
>On the other hand Windows supports most of hardware,
>most vendors ship products with drivers for windows.
>I'm thinking about making a way to use windows drivers in Linux.
>Have anyone thought about it?
>Is it reasonable/possible?
>
>
>
------------------------------
From: Ron Natalie <[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 09:37:44 -0400
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).
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 you were to compare it to char* or
> double or something else
Again in C++, casting a null pointer of one type to another pointer type is
supposed to result in the null pointer of that type.
------------------------------
From: Ron Natalie <[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 09:38:49 -0400
Mark McIntyre wrote:
> This says that either its (int)0 or else (void*)(int)0. it says
> nothing at all about whether the bit pattern is all-zeros or all ones.
That's the C rules, in C++ the void* cast is not part of the null pointer
constant. The null pointer constant is always something that evaluates
to zero.
------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Alternative OS Implementation Languages
Date: 12 Apr 2000 13:52:36 GMT
In article <b6TI4.82804$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christopher Browne) writes:
> Centuries ago, Nostradamus foresaw a time when Donal K. Fellows would say:
>>In article <[EMAIL PROTECTED]>,
>>Tom Mitchell <[EMAIL PROTECTED]> wrote:
>>> Are there M3 compilers in the gnu world that are up to the task?
>>> At least three processor targets.
>>
>>I think the one I'd heard of (log ago, admittedly) used the gcc
>>back-end, so targetting loads of processors shouldn't be a problem.
>
> <http://research.compaq.com/SRC/modula-3/html/platforms.html> reports
> successful builds on:
> a) AIX386 (believe it or not!)
> b) Digital Alpha
> c) HP PA-RISC
> d) AIX PPC
> e) IRIX MIPS
> f) Linux ELF ia-32
> g) Sun SPARC
>
> <http://m3.polymtl.ca/m3/binaries/> reports a similar set of
> successful platforms.
>
> They do not specifically include any non-IA-32 Linux platforms, but
> *do* include commercial UNIXes on pretty much all the important
> platforms that Linux runs on, so that it *ought* to be feasible to get
> the SRC implementation running on other architectures...
>
> This is *precisely* why I mentioned M3 as an option; it might be well
> and neat to propose writing an OS using CMU-Lisp or some Scheme, but
> neither of *those* "general options" provide code generators for such
> a diverse set of architectures.
>
> The other option would be Eiffel.
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.
Dale Pontius
NOT speaking for IBM
------------------------------
** 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
******************************
