Linux-Development-Sys Digest #630, Volume #6     Fri, 16 Apr 99 14:14:24 EDT

Contents:
  Re: script for .procmailrc (Peter Samuelson)
  Re: Timer Function in Linux? (Peter Samuelson)
  Re: Q: Is it possible to compile binaries for a different processor? (Michal 
Jaegermann)
  Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. ("Ciaran Dunn")
  mmap (Rajesh Raju)
  Re: where to download free CORBA for Linux? (Frank Sweetser)
  Re: GNU HURD filesystem - anybody familiar? (Charlie Stross)
  Re: seek for files >2GB (Joel Klecker)
  Re: Uncleanly Unmounted (Kernel 2.2.5) ([EMAIL PROTECTED])
  Re: Yet Another Audio Chip (Nix)
  fopen() fails when it should succeed, linux 2.2.5 ([EMAIL PROTECTED])
  Re: threads, how????? (Edwin Young)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.help,comp.os.linux.misc
Subject: Re: script for .procmailrc
Date: 15 Apr 1999 20:46:35 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>

[George Macario <[EMAIL PROTECTED]>]
> divide only messages smaller than 5 kb into smaller messages of, at
> most, 160 characters, add to each new message "date", "from" and
> "subject" headers of the mail which was divided and forward all
> messages obtained to another address.

This other address sounds sort of like a pager gateway.... (:

> To do this, I need a script for the file .procmailrc; anyone could
> write it for me?

As has already been suggested, you might use Perl.  In particular, the
Mail::Internet module (see CPAN if your installation doesn't already
have it) has saved me a *lot* of headache parsing and manipulating
messages.

And no, probably nobody feels like writing something for you.  But, as
a hint, you don't really need procmail.  Just put two lines in your
~/.forward file: `\username' and `|/the/perl/program'.  That will take
care of saving a copy of each message.

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>

------------------------------

From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Timer Function in Linux?
Date: 15 Apr 1999 20:56:52 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>

[Mridula Shrikant Pradhan <[EMAIL PROTECTED]>]
> I would like to know whether in Linux the timer function is available
> in microseconds.

Oh, you can get it in microseconds -- see nanosleep().  But it won't be
that accurate.  The Linux scheduler (by default on x86) only wakes up a
process every 10000 microseconds, and there's no guarantee your process
would be the next one to wake up at that time, unless it were un-niced
appropriately.  (Not even then, really.)

The realtime clock, which you can read all about in
/usr/src/linux/Documentation/rtc.txt, gives you resolution up to 8kHz,
which of course is 120us.  However, to use it you have to compile RTC
support into your kernel (the config option isn't selected by default,
at least on x86).

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>

------------------------------

From: [EMAIL PROTECTED] (Michal Jaegermann)
Crossposted-To: comp.os.linux.alpha,comp.os.linux.questions,comp.os.linux
Subject: Re: Q: Is it possible to compile binaries for a different processor?
Date: 16 Apr 1999 02:50:58 GMT
Reply-To: [EMAIL PROTECTED]

Chris Gahan ([EMAIL PROTECTED]) wrote:
: I was wondering if it is indeed possible to compile x86 binaries, for
: example, on an Alpha.  

This should be quite easy. gcc had a cross-compilation support for
"always" and I still have around a gcc cross-compiler for producing
Atari ST code. :-) The biggest drag is a set of tools (like 'nm' or 'ar'
and linker) which run on the host computer but operate on binaries of
an intended target and, of course, a set of your target libraries to
link with.

Going the other direction (to cross-compile on x86 for Alpha) seems
to be impossible, or at least very hard, as cross-compiler performs
various arithmetic operations in a target arithmetic and gcc currently
assumes that it can fit them in a host registers.  Registers on
Alpha are twice a width of those on Intel.

Now the good question would be why anybody would really want to set such
cross-compiler?  Intel boxes are all over the place, quite a few of them
rather fast, and creating the whole cross-compilation environment (not
only a cross-compiler itself) is maybe not hard, with all this support
which is already in place, but rather tedious project.

  Michal

------------------------------

From: "Ciaran Dunn" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: Fri, 16 Apr 1999 14:11:46 +1000


Dan Mercer wrote in message <7eivq2$fld$[EMAIL PROTECTED]>...
>Genericity?  That's a new one on me.  To be clearer,  to learn lisp
>only to program my editor seems a waste of effort and neurons.  That
>hardly makes me limited in my knowledge,  which I will stack against
>anyones.


Except of course your lisp knowledge. I find learning a language *never* a
waste of time... but then Im a alnguage freak :)

Cheers,
Ciaran



------------------------------

From: Rajesh Raju <[EMAIL PROTECTED]>
Subject: mmap
Date: Thu, 15 Apr 1999 19:09:01 -0500


Hi ,
I am writing a device driver.There are 6 base address registers on any
pci device. I want to know how to mmap the region available on each
address register to the user space. 

I am using remap_page_range (...) routine. But I am not able to mmap the
whole space.

Any help is greatly appreciated.

Thanking you,
Rajesh.



******************************************************************************
Raju Rajesh                                     Office address:                 
1120, E LEE BLVD                                #208 Butler Hall
Apt #167                                        Mississippi State
Starkville,MS- 39759                            Univeristy, MS -39762
Phone No: (601) 323 6116                        Phone no: (601) 325 8169

Possible talk locations: talk [EMAIL PROTECTED]
                              [EMAIL PROTECTED]
******************************************************************************


------------------------------

From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: where to download free CORBA for Linux?
Date: 16 Apr 1999 10:47:24 -0400

"Enosh Chang" <[EMAIL PROTECTED]> writes:

> Hi, all:
> 
> I am a beginner of Linux. And I want to learn CORBA.
> So, could you tell me where to download free CORBA for Linux?

poke around at http://www.gnome.org/ - the gnome project uses corba
extensivly, and has some links to very good corba linux sites.

-- 
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net  | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5        i586 | at public servers
The autodecrement is not magical.
             -- Larry Wall in the perl man page

------------------------------

From: [EMAIL PROTECTED] (Charlie Stross)
Subject: Re: GNU HURD filesystem - anybody familiar?
Date: Fri, 16 Apr 1999 15:05:16 GMT
Reply-To: charlie @ nospam . antipope . org

Stoned koala bears drooled eucalyptus spittle in awe
as <[EMAIL PROTECTED]> declared:

>: : >I'm trying to recover some data from a  machine that shows this filesys.
>: : >The o/s is unix system V, Release 3.2 v 2.0.  The people I got it from
>: : >didn't know the root password, just a user account that can't do much.

That'll be a bog-standard old-fashioned SCO UNIX 3.2v2 system -- replaced
by 3.2.4 in, oh, 1992 or thereabouts. The FS will be either Xenix (not so
likely) or SCO's take on the original SVR3 filesystem -- compatible, but
minor tweaks. (3.2v2 was limited to 14-character filenames, IIRC, and is
very "brittle" if you panic the system -- ext2 is a huge improvement!). It
may also use the "divvy" sub-partitioning tool to cram up to eight divvy
disk areas (with a filesystem on each) into each partition on the disk.

You should be able to pick up an old SCO CD or floppy set pretty cheap, but
I concur with the verdict that you want to get the Free SCO OpenServer kit
and use that to recover the partition -- the safest way is to use SCO's own
tools.


-- Charlie (who worked at SCO from '91 to '95)

------------------------------

From: Joel Klecker <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.c-programming
Subject: Re: seek for files >2GB
Date: Fri, 16 Apr 1999 09:23:59 -0700

In article <[EMAIL PROTECTED]>, Georg Ritter 
<[EMAIL PROTECTED]> wrote:

> does anyone know if there is a 64 bit seek interface 
> for linux like in IRIX:
> 
> 
>      off_t lseek (int fildes, off_t offset, int whence);
>      off64_t lseek64 (int fildes, off64_t offset, int whence);

GNU libc 2.1 has the LFS interface (see `info libc "Feature Test 
Macros"' if you have access to the glibc 2.1 info docs)[1], however the 
kernel side is only implemented on 64-bit architectures.

Once Linux supports 64-bit offsets on 32-bit architectures, glibc 2.1 
might need a few changes to support using it, or it is possible it would 
notice the syscalls in the kernel headers and do the right thing 
automatically (this is at compile time I am talking about).

There is a kernel patch that may work at: 
<ftp://mea.tmt.tele.fi/linux/LFS/>.

Another post suggests llseek, but I think that is primarily for block 
devices.

[1] Here are the relevant parts of that node:

 - Macro: _LARGEFILE_SOURCE
     If this macro is defined some extra functions are available which
     rectify a few shortcomings in all previous standards.  More
     concrete the functions `fseeko' and `ftello' are available.
     Without these functions the difference between the ISO C interface
     (`fseek', `ftell') and the low-level POSIX interface (`lseek')
     would lead to problems.

     This macro was introduced as part of the Large File Support
     extension (LFS).

 - Macro: _LARGEFILE64_SOURCE
     If you define this macro an additional set of function gets
     available which enables to use on 32 bit systems to use files of
     sizes beyond the usual limit of 2GB.  This interface is not
     available if the system does not support files that large.  On
     systems where the natural file size limit is greater than 2GB
     (i.e., on 64 bit systems) the new functions are identical to the
     replaced functions.

     The new functionality is made available by a new set of types and
     functions which replace existing.  The names of these new objects
     contain `64' to indicate the intention, e.g., `off_t' vs.
     `off64_t' and `fseeko' vs. `fseeko64'.

     This macro was introduced as part of the Large File Support
     extension (LFS).  It is a transition interface for the time 64 bit
     offsets are not generally used (see `_FILE_OFFSET_BITS'.

 - Macro: _FILE_OFFSET_BITS
     This macro lets decide which file system interface shall be used,
     one replacing the other.  While `_LARGEFILE64_SOURCE' makes the
     64 bit interface available as an additional interface
     `_FILE_OFFSET_BITS' allows to use the 64 bit interface to replace
     the old interface.

     If `_FILE_OFFSET_BITS' is undefined or if it is defined to the
     value `32' nothing changes.  The 32 bit interface is used and
     types like `off_t' have a size of 32 bits on 32 bit systems.

     If the macro is defined to the value `64' the large file interface
     replaces the old interface.  I.e., the functions are not made
     available under different names as `_LARGEFILE64_SOURCE' does.
     Instead the old function names now reference the new functions,
     e.g., a call to `fseeko' now indeed calls `fseeko64'.

     This macro should only be selected if the system provides
     mechanisms for handling large files.  On 64 bit systems this macro
     has no effect since the `*64' functions are identical to the
     normal functions.

     This macro was introduced as part of the Large File Support
     extension (LFS).
-- 
Joel Klecker (aka Espy)                     <URL:http://web.espy.org/>
<URL:mailto:[EMAIL PROTECTED]>                  <URL:mailto:[EMAIL PROTECTED]>
Debian GNU/Linux Package Maintainer for the GNU C Library.

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Uncleanly Unmounted (Kernel 2.2.5)
Date: Thu, 15 Apr 1999 11:00:58 +0000

Yazid <[EMAIL PROTECTED]> wrote:
> Hi...
> Every once and a while, my Linux does not unmount my \ partitoin
> cleanly. I don't know why. I use 2.2.5 kernel and banshee server. help
> me.. i fear my Linux won't succesfully face the situation in the future.
> (It never happen using my old kernel(donwloaded)). This 2.2.5 kernel is
> self-compiled.
> Thank you.

Are you sure you read the changes and update your system before
compiling the new kernel??

-- 
cu

------------------------------

From: Nix <$}xinix{[email protected]>
Subject: Re: Yet Another Audio Chip
Date: 16 Apr 1999 07:40:48 +0100

Shankar Unni <[EMAIL PROTECTED]> writes:

>                                            productized

*shudder*

-- 
`The purpose of a windowing system is to put some amusing
 fluff around your one almighty emacs window.' -- Mark on gnu.emacs.help

------------------------------

From: [EMAIL PROTECTED]
Subject: fopen() fails when it should succeed, linux 2.2.5
Date: Fri, 16 Apr 1999 16:51:59 GMT

I noticed that when I try to edit /etc/inetd.conf I got a permission denied
error (using vim 5.3, see strace output below).  I was running as root, the
file permissions were 644 and "fuser /etc/inetd.conf" (from psmisc version
17) reported that no one had the file open.  (See note about fuser below)
I was able to update the mtime of /etc/inetd.conf using touch.

To get to a rather minimal description, I wrote some code (see below).  It
shows that I can do an fopen("/etc/inetd.conf", "r") but I can't do an
fopen("/etc/inetd.conf", "wa").  I can, however open /etc/inetd.conf2 for
writing.  See the output from my program:

# ./blah /etc/inetd.conf
Using file "/etc/inetd.conf" uid = 0 euid = 0
        Permissions: st_mode 100644 st_uid 0 st_gid 0
        File is NOT a symlink
        File is a regular file
        File is NOT a directory
        File is NOT a char device
        File is NOT a block device
        File is NOT a fifo
        File is NOT a socket
Open for read OK
Open for write (append) FAILED: Permission denied

# ./blah /etc/inetd.conf2
Using file "/etc/inetd.conf2" uid = 0 euid = 0
lstat FAILED: No such file or directory
Open for read FAILED: No such file or directory
Open for write (append) OK

# ./blah /etc/inetd.conf2
Using file "/etc/inetd.conf2" uid = 0 euid = 0
        Permissions: st_mode 100644 st_uid 0 st_gid 0
        File is NOT a symlink
        File is a regular file
        File is NOT a directory
        File is NOT a char device
        File is NOT a block device
        File is NOT a fifo
        File is NOT a socket
Open for read OK
Open for write (append) OK


The system is a redhat 5.0 system, upgraded to 5.2, then applied the
necessary updated RPM's for the 2.2 kernel.  Versions of everything (except
pcmcia) checked out as good according to
http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html.

Any ideas?
Mike

Portion of the strace output from vim:
 -----------------------------------------------------------------

stat("inetd.conf~", 0xbfffb18c)  = -1 ENOENT (No such file or directory)
unlink("inetd.conf~")  = -1 ENOENT (No such file or directory)
open("inetd.conf~", O_WRONLY|O_CREAT, 0666) = 4 chmod("inetd.conf~", 0644)  =
0 fchown(4, 4294967295, 0)  = 0 read(3, "#\n# inetd.conf\tThis file
descr"..., 8192) = 3332 write(4, "#\n# inetd.conf\tThis file descr"..., 3332)
= 3332 read(3, "", 8192)  = 0 close(4)  = 0 utime("inetd.conf~",
[99/04/16-10:31:50, 99/04/16-09:34:10]) = 0 close(3)  = 0 getuid()  = 0
open("inetd.conf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission
denied) getuid()  = 0 getgid()  = 0 unlink("inetd.conf")  = -1 EPERM
(Operation not permitted) open("inetd.conf", O_WRONLY|O_CREAT|O_TRUNC, 0666)
= -1 EACCES (Permission denied) stat("inetd.conf", {st_mode=0, st_size=0,
...}) = 0 stat("inetd.conf", {st_mode=0, st_size=0, ...}) = 0
unlink("inetd.conf~")  = 0

My source
 -----------------------------------------------------------------
#include <errno.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/stat.h>

int main(int argc, char **argv) {
    FILE *f;
    char file[256] = "/etc/inetd.conf";
    struct stat buf;

    if ( argc > 1 ) {
        strncpy(file, argv[1], 254);
        file[255] = '\0';
    }

  printf("Using file \"%s\" uid = %d euid = %d\n", file, getuid(),
geteuid());  if ( lstat(file, &buf) != 0) {  perror("lstat FAILED");  } else
{  printf("\tPermissions: st_mode %o st_uid %d st_gid %d\n", buf.st_mode, 
buf.st_uid, buf.st_gid);  printf("\tFile %s a symlink\n",
S_ISLNK(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s a regular
file\n", S_ISREG(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s a
directory\n", S_ISDIR(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s a
char device\n", S_ISCHR(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s a
block device\n", S_ISBLK(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s
a fifo\n", S_ISFIFO(buf.st_mode) ? "is" : "is NOT");  printf("\tFile %s a
socket\n", S_ISSOCK(buf.st_mode) ? "is" : "is NOT");  }

    f = fopen(file, "r") ;
    if ( f != NULL ) {
        printf ("Open for read OK\n");
        fclose(f);
    } else {
        perror("Open for read FAILED");
    }

    f = fopen(file, "wa") ;
    if ( f != NULL ) {
        printf ("Open for write (append) OK\n");
        fclose(f);
    } else {
        perror("Open for write (append) FAILED");
    }
    return 0;
}

Note about fuser
 -----------------------------------------------------------------
When I checked the exit value of fuser, it was 1, which I guessed was
bad.  I then checked /proc to see if anything had /etc/inetd.conf open
with the command:  "ls -l /proc/[0-9]*/fd | grep /etc/inetd.conf".
/etc/inetd.conf also only has one directory entry (nlinks == 1):

-rw-r--r--   1 root     root         3332 Apr 16 09:34 /etc/inetd.conf

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

Crossposted-To: comp.os.linux.development.apps
Subject: Re: threads, how?????
From: Edwin Young <[EMAIL PROTECTED]>
Date: 16 Apr 1999 09:54:07 +0100

Sander Zijlstra <[EMAIL PROTECTED]> writes:
> Recently I started using pthreads for my program which I'm writing
> within my graduating-project, but I'm kinda new to programming under
> Linux and especially with thread programming. Here's my question about
> threads:

Unless you explicitly have to use threads, you might want to consider
writing your program as three separate processes with standard UNIX 
pipes between them, eg

socket_reader | fft | modulator > output

This will probably be simpler to program and the mutual exclusion will 
be handled for you. On the downside, it'll probably be slower and won't 
work well if data has to flow "up" the pipe as well.
 

--
Edwin Young

------------------------------


** 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
******************************

Reply via email to