Subject: Linux-Development Digest #157
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 11 Sep 94 16:13:09 EDT

Linux-Development Digest #157, Volume #2         Sun, 11 Sep 94 16:13:09 EDT

Contents:
  S3 and 24bit or 16bit
  Curses help (Benjamin B. Rickett)
  Another DOSEMU.52 Problem. . . (Grungie The Wise)
  Re: S3 and 24bit or 16bit (Mihail S. Iotov)
  Re: Alpha Linux (Johan Myreen)
  Re: Why I cannot mount a PhotoCD on Mitsumi ? (Jeff Kesselman)
  File locking--gurus please read. :) (Willis Boyce)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Mike Castle)
  Re: 320x200 X resolution? (Christopher M. May)
  Re: floppy problems in 1.1.49 (Olav Kvittem)
  HP Ethercards Not Supported (Michael Talbot-Wilson)
  DOOM for Linux problem - help. (Dane Jasper)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Robert Sanders)
  Re: Wheres blkdev.h?? (compiling 1.1.49) (Stephen Harris)
  480x360 Res works for me. (Daniel L Moore)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Carlos)
  Re: Developing Distributed Filesystems for Linux? (Derek Atkins)
  Re: Developing Distributed Filesystems for Linux? (John F Carr)
  Re: Alpha Linux (Richard Henderson)

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

From: [email-masked] ()
Subject: S3 and 24bit or 16bit
Date: 11 Sep 1994 17:08:33 GMT

Are there any software on the net that makes it possible to show 24 bit
graphics or perhaps only 16 bit on S3-based graphics cards (including 805).
Svgalib only describes a faulty/non completed S3-driver.

The software/driver only has to be able to plot 24bit-pixels.

I know that XFree86 v3.1 should have 64k-colours on the S3 but I
would like to have solved this problem a little earlier...

- Henrik Wann Jensen

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

From: [email-masked] (Benjamin B. Rickett)
Subject: Curses help
Date: 11 Sep 1994 04:21:49 GMT

I am modifying my curses programs to ahve color, but i'm not exactly sure 
where to start.  Does any body have a simple example of how to use color 
in curses?  If youu do please let me know.
        
        Thanks... Please send Email to [email-masked]

--

                        Internet Alliance Administrator
                             -Benjamin B. Rickett

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

From: [email-masked] (Grungie The Wise)
Crossposted-To: comp.os.linux.help
Subject: Another DOSEMU.52 Problem. . .
Date: 11 Sep 1994 10:23:57 -0700

When compiling Dosemu0.52, I get the following error:

make[1]: Entering directory `/usr/src/dosemu0.52/mouse'
gcc -O2 -Wall  -I/usr/src/dosemu0.52/include -I/usr/src/dosemu0.52
-I/usr/src/linux/include -c mouse.c
mouse.c: In function `fake_int':
mouse.c:587: `VIF_MASK' undeclared (first use this function)
mouse.c:587: (Each undeclared identifier is reported only once
mouse.c:587: for each function it appears in.)
mouse.c: In function `mouse_do_cur':
mouse.c:672: warning: implicit declaration of function `mmap'
mouse.c: At top level:
mouse.c:156: warning: `mousescreenmask' defined but not used
make[1]: *** [mouse.o] Error 1
make[1]: Leaving directory `/usr/src/dosemu0.52/mouse'
make: *** [dossubdirs] Error 1

I commented out the bad code, and it compiled, but I got the same
errors again in dpmi.c.

Thats as far as I got. I dont have time right now to search the code
myself, so I was wondering if anyone has had similar problems, or
knows what VIF_MASK is and where is is defined.

(It has to be a macro expansion, of LWORD, I think, as it is not
directly in the code, but I didnt have a chance to run it through the
preprocessor)

Any help or comments would be appreciated. Hopefully I might find some
time to figure it out.

Jeff

-- 
               __________------== Jeff Townsend ==------___________
       ____----DCC Consultant - Guitarist - CS Major - Simpsons Fan----____
    -==[email-masked]   jefft@xenon    god@cs    grungie@leland ==-
       ----_______"Yes sir. Very much so sir. Obviously insane."_______----

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

From: [email-masked] (Mihail S. Iotov)
Subject: Re: S3 and 24bit or 16bit
Date: 11 Sep 1994 17:38:26 GMT

[email-masked] () writes:

>Are there any software on the net that makes it possible to show 24 bit
>graphics or perhaps only 16 bit on S3-based graphics cards (including 805).
>Svgalib only describes a faulty/non completed S3-driver.

>The software/driver only has to be able to plot 24bit-pixels.

>I know that XFree86 v3.1 should have 64k-colours on the S3 but I
>would like to have solved this problem a little earlier...

Try some DOS program under DOSEMU. My S3 does not work with these either,
but you may have more luck.

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

From: [email-masked] (Johan Myreen)
Subject: Re: Alpha Linux
Date: 11 Sep 1994 17:34:23 GMT

In article <[email-masked]> [email-masked] (N J Plant) writes:

>On the 68000 the external address bus is 20 bits and the external data bus
>is 8.

The external data bus is 16 bits wide on the 68000.

> Internally, the registers, buses and ALU are all 32 bit. It can ADD
>and SUBtract 32 bit numbers or MULtiply 2 16 bit numbers to give a 32 bit
>result. It has fewer pins than a 68040, but its still a 32 bit chip. The
>sizeof the integral types should be the same as any other 68K chip.

32 bits? Do you really think that is the natural integer size
considering the 16 bit external data path and the lack of a 32x32 bit
multiplication instruction? According to the C standard both char and
short operands in an expression are promoted to int before the
operation proceeds. This means all arithmetic operations would be
performed with 32 bit operands, which is *not* *too* *efficient* if
all you've got is a 16x16 multiplication instruction. (Well, I guess a
compiler can optimize sometimes, but not always.)

>The Intel 8088 has a 20 bit address bus, but is otherwise an 8 bit device.
>So:
>  short = 8  bits
>  int   = 16 bits

Hmm, I thought you said it was an 8 bit device?

>  long  = 16 bits
>Neither of these processors has the address space or MMU necessary for
>Linux to run on them, so the natural word size is irrelevant.

I guess you mean irrelevant to this newsgroup. But there are C
compilers for these processors too.

-- 
Johan Myreen
[email-masked]
60 11' 55" N, 24 53' 30" E

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Jeff Kesselman)
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: Sun, 11 Sep 1994 17:26:22 GMT

In article <[email-masked]> [email-masked] (Tamas Badics) writes:
>[email-masked] (Jeff Kesselman) writes:
>
>[many interesting technicalities deleted...]
>
>>The poitn of all this is that ALL CD-ROM types are fully ISO9660 
>>compatable. (other than perhapse really wierd propritary formats-- I won't 
>>even guess what the Atari Jaguar does).
>
>>[email-masked]
>
>OK, it is all nice to know, but how can I read a PhotoCD on a Mitsumi drive?
>(My MS-DOS driver can read them without problems.)
>
>Tamas
>
>
Boy, after all that info I put out, I have to admit that THIS question 
I'm not 100% sure of... mostly 'cause I've never had to do it (all my 
CD-ROM programming has been on dedicated platforms such as C-I, 3DO, etc...)

Why don't you tell us exactly what you are doing, and where it is 
failing?  Are you mounting the CD-ROM using Linux mount?  Does it mount 
successfully or error out?

We may get into details that will need the trained eye of someone who 
actually knows the innards of the CD-ROM drivers under Linux but, 
technically and according to the standards, you SHOULD be able to mount a 
Photo-CD and see its files.

CD type discs can have multiple 'tracks'. On a yellow CD-ROM, the data is 
all in track 0.  I assume Photo-CD by definition would HAVE to be the same...

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

From: [email-masked] (Willis Boyce)
Subject: File locking--gurus please read. :)
Date: 11 Sep 1994 13:55:43 -0400

I've been working recently on a DBMS project under Linux.  My ultimate 
goal is to create a DBMS which compares favorably with commercial systems 
and which provides a very simple interface into C.  The primary DBMS I 
use now (at work) is Sybase, and I am frustrated with the difficulty of 
interfacing that DBMS to C as well as with the temptation to code a lot 
of processing in stored procedures.  My DBMS will deliberately omit 
stored procedures and encourage the user to do most processing in C.

After looking into various methods (I'm pretty new to Unix), I decided to 
use advisory file locks as my concurrency mechanism.  These have two big 
advantages:

1.  They allow me to use a decentralized approach to concurrency.
2.  They have built-in deadlock detection.

Unfortunately, the Linux 1.1.8 that I am running apparently doesn't 
support deadlock detection.  Indeed, there is even a comment in flock.c 
to that effect.  Anybody who has ever used a heavily-loaded DBMS 
knows that deadlock detection is not something that can be done without; 
therefore, I would like to add it.

First, though, I am wondering if anybody has *already* added deadlock 
detection to Linux.  If so, in which version of the kernel did it make 
its debut?  And, what is the most stable kernel version *after* the 
deadlock detection was added?  :)

If deadlock detection is still in need of address, my analysis is that it 
won't be easy.  I'm soliciting suggestions on the best way to proceed.  
I'm interested in the opinions of the other Linux developers, since I 
would like to contribute my patch if/when it is finished.

A simple algorithm that, before blocking task A on B, checks that B isn't 
already blocked on A won't cut it, because true deadlock detection 
requires handling a block chain that could conceivably include every 
process in the system.

Given a file_lock structure that is about to be created (called file_lock
in the locks.c), and a file_lock structure called fl that file_lock would
conflict with, I need to find out if fl's owner is ultimately blocked on a 
file_lock structure which is owned by the current task, called current.  

(The quick and dirty way would be to declare a deadlock if fl's owner was 
blocked at all.  That wouldn't be great, but it would work.  Opinions?)

One problem is that the association between file_lock and wait_queue is
only one-way.  Given a wait_queue, the only way to get the first file_lock
of the waiting task is to search the file_lock chain for a file_lock
structure whose owner is the waiting task. 

It seems like the only to handle it would be a recursive function 
together with a list of already-processed tasks.  The list hold pointers 
to those tasks which had already been determined to *not* be waiting for 
current.  In the event that A and B were both blocked on C, and C had 
been determined to not be waiting for current, the list would prevent C 
from being evaluated a second time.

In the event of a deadlock, do I blow away the task's other file locks, 
or do I let the calling process do it?  (Obviously it has to be done, 
else the process will never be able to obtain its locks.)

Anyway, feel free to mail me at [email-masked] or talk-page me at 
[email-masked] (my SLIP site, non-mailable) if anybody 
feels like discussing this.  Or post a reply.  :)

Will

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

Crossposted-To: comp.lang.fortran
From: [email-masked] (Mike Castle)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Sun, 11 Sep 1994 17:31:04 GMT

In article <[email-masked]>, Dan Pop <[email-masked]> wrote:
>Could you post some examples where a commercial native compiler for x86
>produces _significantly_ faster codes than the free gcc?

IBM's C compilers under OS/2.
Watcom compilers under OS/2 and DOS (do they have unix versions?)
Zortech C compiler (I presume under OS/2 and DOS as well).
Most likely the Mark Williams C compiler (they produce better
  compilers than operating systems (coherent)).

GCC is designed to be PORTABLE first, optimal last.  In almost
all cases, a DECENT architecture specific compiler will be as
good as or beat GCC.  
-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  [email-masked]     and be right all the time, or not work at all
   [email-masked]       and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

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

From: [email-masked] (Christopher M. May)
Crossposted-To: comp.os.linux.misc
Subject: Re: 320x200 X resolution?
Date: 11 Sep 1994 17:51:33 GMT

Andreas Matthias ([email-masked]) wrote:

: :     So.... 320x200 resolution anyone? :)
: : I'll post if I figure out how to do it.

: I have one that's working here (ET4000 with 17'' AOC monitor), but it
: occupies only about half of the screen in vertical direction. I did
: not find out how to make it bigger vertically. Perhaps someone else
: can continue with this:

: **********************************************************************
: ModeDB
: # name        clock   horizontal timing     vertical timing      flags

:  "320x200"     25      320  360  424   440    200  200  240  250
: **********************************************************************

: btw: Could it be that fvwm gets confused with this resolution? It
: seems not to scroll correctly in the vertical direction.

: Ciao,

: Andreas

: --
: Andreas Matthias <[email-masked]>

: Zehntenstr.9 
: D-37120 Bovenden

: Voice: +49/551/81377

You need a lower dot clock frequency in my opinion.  I had the same 
problem with higher dot clocks.  I used a 12Mhz dot clock frequency
in the modedb line I posted earlier.

320x240    12   320 352 392 424       240 243 247 252

--

-Chris May, Computer Science, University of MA, Amherst
-       Technical Assistant, P.C. Maintenance Lab

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

From: [email-masked] (Olav Kvittem)
Subject: Re: floppy problems in 1.1.49
Date: 11 Sep 1994 18:32:50 GMT

In article <[email-masked]> [email-masked] (Wolfram Gloger) writes:

   >: Sep  2 04:58:18 darkstar kernel: VFS: Disk change detected on device 2/0
   >: Sep  2 04:58:22 darkstar kernel: floppy: disk absent or changed during operationSep  2 04:58:22 darkstar kernel: floppy I/O error
   >: Sep  2 04:58:22 darkstar kernel: dev 0200, sector 38

   >[ ... more stuff deleted ... ]

   As this was not while loading a ramdisk, I can't comment.

   >You're not the only one having problems, Mike.

   >I get messages similar to the above when I boot from floppy and
   >the kernel is copying the floppy to the ramdisk.  This occurs
   >with both 1.1.23 and 1.1.45 but not 1.0 or 1.0.9.

   I had this too until 1.1.47 (I believe) then it got fixed - I have
   a bootable rootdisk with 1.1.49 that works just fine.

I have problems even with 1.1.50, 1.1.37 and 1.1.23 but not with 1.0.

I am trying to make my own Slackware bootdisk with  a kernel that
can do NFS  over a D-link adapter.

Olav

--
   Olav Kvittem : UNINETT A/S
      RFC Address     [email-masked]
      OR Address      C=no;ADMD=" ";PRMD=uninett; O=uninett;S=Kvittem;G=Olav
      Postal Address  Box 6883 N-7002 Trondheim
      Phone           +47-7-596981 +47-7-596450(FAX)
      Description     Network Manager
   "Networking needs neat working - Nettverk er nette verk !"

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

From: [email-masked] (Michael Talbot-Wilson)
Subject: HP Ethercards Not Supported
Date: Sun, 11 Sep 1994 13:26:38 GMT

The Ethernet HOWTO describes the HP 27247B and 27252A in these
terms:
    "These cards are high performers (3c509 speed) without
     the interrupt latency problems (32K onboard RAM for TX
     and RX packet buffering).  They both offer LAN
     connector autosense, data I/O in I/O space (simpler) or
     memory-mapped (faster), and soft configuration.  27247B
     was rated Best for ISA Servers by PC Mag this year."

This discussion is under the "Supported:" sub-heading.

In my hands, however, the kernel does not detect these cards.  I
have tried the 27247B in a 386SX IDE and the 27252A in a 486DX2
SCSI.  (Yes, I know the disk makes no difference.)  And I have
tried several generations of the kernel, all compiled with
HP PCLAN support enabled.  I have tried passing the IRQ and
base port address in an ether string at the lilo: prompt and
I have tried the lilo reserve ... ether... parameters.

I compiled a kernel with both HP PCLAN and Intel EtherExpress
support.  When I booted this kernel with the HP 27252A installed
the kernel announced detection of the EtherExpress, and on the
same line, detection of an error and rejection of the card.  It
did not detect the HP card.  I booted this kernel with an
EtherExpress card installed.  That was successful, and for the
first time ever the ifconfigs in rc.inet1 ran without error.

The kernels I tried were 1.0.8, 1.1.38 and 1.1.49.

The HP cards test OK with HP's software under MSDOS and they
are detected by Microsoft Windows for Workgroups.
-- 
Michael Talbot-Wilson

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

From: [email-masked] (Dane Jasper)
Crossposted-To: alt.games.doom,comp.os.linux.help
Subject: DOOM for Linux problem - help.
Date: 11 Sep 1994 18:31:00 GMT

I am having a problem getting DOOM for Linux to run on one of my machines. 
On the 486/66 machines at school, things work just fine.  It's very
depressing not to be able to play DOOM at home!

Here's what I get (system info follows):

# linuxxdoom 
linuxxdoom: using incompatible library '/usr/X386/lib/libXt.so.3.0.1'
        Desire minor version >= 1 and found 0
linuxxdoom: using incompatible library '/usr/X386/lib/libX11.so.3.0.1'
        Desire minor version >= 1 and found 0
                          DOOM System Startup v1.666                          
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon. 
W_Init: Init WADfiles.
        adding ./doom1.wad
        shareware version.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [...................]
P_Init: Init Playloop state.
I_Init: Setting up machine state.
Could not start sound server [sndserver]
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  132 (XTEST)
  Minor opcode of failed request:  1 (X_XTestCompareCursor)
  Resource id in failed request:  0xbffff6a0
  Serial number of failed request:  4
  Current serial number in output stream:  4

The system is a 486/66 with 28 megs of ram and linux 1.0.9.  X is version
2.1, with the XF_SVGA server.  

Does anyone have any ideas?  Is it the libs??

Replies via email are appreciated - post as well if you think it would be of
general interest.

Dane

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

From: [email-masked] (Robert Sanders)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 11 Sep 1994 18:30:04 GMT

On Sun, 11 Sep 1994 17:31:04 GMT, [email-masked] (Mike Castle) said:

> In article <[email-masked]>, Dan Pop <[email-masked]> wrote:
>> Could you post some examples where a commercial native compiler for x86
>> produces _significantly_ faster codes than the free gcc?

> IBM's C compilers under OS/2.
> Watcom compilers under OS/2 and DOS (do they have unix versions?)
> Zortech C compiler (I presume under OS/2 and DOS as well).
> Most likely the Mark Williams C compiler (they produce better
>   compilers than operating systems (coherent)).

I think Dan meant he wanted to see the C source, timings, and the
assembly produced by each, as well as other relevant benchmark
information (input data, RSS, host machine, etc.).

I know that at least one of your statements (the last) is untrue; the
big benefit of the MWC compiler is that it compiles fast; when
Coherent users want code that runs fast, they use GCC.

> GCC is designed to be PORTABLE first, optimal last.  In almost
> all cases, a DECENT architecture specific compiler will be as
> good as or beat GCC.  

This is simply a restatement of the original claim.  We're trying to
verify it empirically, not take a vote.

  -- Robert

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Stephen Harris)
Subject: Re: Wheres blkdev.h?? (compiling 1.1.49)
Date: Sun, 11 Sep 1994 10:32:32 GMT

Dougal Campbell ([email-masked]) wrote:

: I ran across the same thing when I compiled the 1.1.49 kernel.  The
: patches seem to not place some of the files correctly. If you look in 

The patches are perfect.  I have patched from 1.0.0 up to 1.1.50 without
any errors.  

There are a number of things to keep in mind when patching
  1) Always keep a CLEAN tree (ie unconfigued etc) around.  I generally
     keep a 'tar' of the sources just before I configure/compile.
     This is because configure changes files, and so patch might fail.

  2) Always path from the /usr/src directory

  3) Always use the -p0 flag when patching

This is how I do my patching:

  cd /usr/src
  mv linux linux.old
  tar xvf ARCHIVE/linux.49.tar
  gzip -dc < ARCHIVE/patches/patch50.gz | patch -s -p0
  # see if any .rej files exist - shouldn't!
  find linux -name '*.rej' -print
  # Remove the old files
  find linux -name '*.orig' -exec rm {} \;
  # Make a new archive
  tar cvf ARCHIVE/linux.50.tar linux

I can now configure/compile etc.  When the next patch comes along the new tar
file I created is a clean source tree to patch against.

If you don't understand the above, then you probably shouldn't be playing
around with ALPHA level kernels.

-- 

rgds
Stephen

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

From: [email-masked] (Daniel L Moore   )
Crossposted-To: comp.os.linux.misc
Subject: 480x360 Res works for me.
Date: 10 Sep 1994 01:55:57 GMT

Here's a Xconfig line that works for my CrystalScan 1572FS monitor.

"480x360" 25  480 496 504 664  360 360 368 377

It'll will probably work with other monitors that have the following
specs: 

   Horizontal Scan Freq: 30 - 64 kHz
   Vertical Scan Freq: 50 - 100 Hz
   Bandwidth: 80 MHz

Also note that the dot clock is 25MHz for your video card.

DOOM runs fine, now to find solutions to the ctrl, alt - arrow keys
combinations, (my window manager takes over), and getting the sound
to work, probably need to upgrade my driver.
-- 
*******************************************************************************
* Daniel L. Moore                                           [email-masked] *
* University of Illinois at Urbana-Champaign    --     College of Engineering *
*******************************************************************************

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

From: [email-masked] (Carlos)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 10 Sep 1994 00:30:04 GMT

In article <[email-masked]> [email-masked] (Larry Meadows) writes:
   1. Are people interested in a commercial compiler suite for Linux on
      Intel Architecture platforms? The suite would include true compilers
      for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
      High Performance Fortran. C, f77, and C++ could support shared memory
      parallelism (thread-based) if system support is available in Linux.
      HPF would support socket-based communications on networked systems,
      and could support custom interconnects.

About C-C++: if your product is better than gcc, yes. By better I mean not
being buggy and producing faster code (at least 15%, on a 486, on a wide
variety of codes). It doesn't need to produce a lot of warnings, etc. since
this can be done with gcc.

For FORTRAN, only if it's full f90. Of course it should produce SIGNIFICANTLY
faster code than f2c-gcc.

   2. How much would people pay for such a product [ loaded question ]?

Around $500 is reasonable for one language, with an extra one around $200.

   3. What distribution media would be required?

ftp, floppy.

   4. Is there interest in accompanying GUI/non-GUI debuggers and
      performance analysis tools?

If it's not expensive, otherwise not.

Carlos

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

From: [email-masked] (Derek Atkins)
Crossposted-To: alt.filesystems.afs
Subject: Re: Developing Distributed Filesystems for Linux?
Date: 11 Sep 1994 19:57:26 GMT

In article <[email-masked]> [email-masked] (Lincoln Myers) writes:

   Is anyone working on a filesystem for Linux or another freely available UN*X
   which will offer the advantages that these do?

   AFS was a project at CMU before it became a commercial product supported by
   Transarc.  Would it be feasable to port an earlier version (pre-3.0?) to
   Linux?  (Is it freely available?  Would it be compatible with current AFS?
   Would one want to use it?)

   If not, would it be possible to make a freely available implementation of
   AFS or DFS for Linux, without infringing on their current owner's
   (Transarc's) rights?  Is there enough information out there?

Well, I can try to answer _some_ of these questions.  I have ported
Transarc's AFS version 3.3 to Linux.  It is currently in Beta testing
at MIT and soon to be in testing at a few other AFS Licensee sites.
We are _hoping_ to get the rights from Transarc to distribute binaries
to all comers, but at this point in time we are not in a position to
do so.

The distribution is only in object form (no sources), and it comes as
a loadable kernel module (so no, the GPL does not, and need not,
apply, so distribution is not illegal).  No changes are required to
the kernel in order to run Linux-AFS, although it does require a Linux
kernel version of 1.1.33 or higher, and unfortunately because of the
way modules are supported in Linux, it might require a recompile if
certain things change in the kernel.  Right now, the beta test is
using 1.1.48 and 49, and I believe it will also work with 1.1.50
without a recompile.

The current testing and usage shows it to work fairly well under light
load, although there are problems with high usage.  For example,
linking "gdb" into AFS appears not to work (although I haven't tried
to reproduce this, yet, so I haven't verified this behavior).

So, to sum up the current situation: Linux-AFS exists.  It is in
beta-test.  You currently need a Transarc license to use it, and we
need to get permission for each site that wants to get a copy of it.
(We currently have permission for ISU, CMU, and NCSU, although we
still need to determine the method of distribution allowed to us).

If you have any questions, feel free to send me mail at:
        [email-masked]

Enjoy!

-derek
--
         Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
       Member, MIT Student Information Processing Board (SIPB)
    Home page: http://www.mit.edu:8001/people/warlord/home_page.html
       [email-masked]    PP-ASEL     N1NWH    PGP key available

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

From: [email-masked] (John F Carr)
Crossposted-To: alt.filesystems.afs
Subject: Re: Developing Distributed Filesystems for Linux?
Date: 11 Sep 1994 19:56:31 GMT

In article <[email-masked]>,
Derrick J. Brashear <[email-masked]> wrote:

>I too would be willing to work on a project like this, but as to whether
>the answer is to write "free" AFS client software, or to write a totally
>new system, I'm not sure.

A reason I haven't put a lot of effort into my AFS work is because I don't
like AFS.  The only value of AFS is interoperation; if you want a distributed
filesystem you can do better (write your own, or talk to some of the OS
research groups).  Part of the reason I started working on AFS was to get
experience I could use to write something good later.  An idea I've been
thinking about for a while is to write a network filesystem that normally
talks its own protocol but understands AFS or a useful subset of AFS.

So ask, what is the target customer for your filesystem software?  Are you
trying to link Linux users together, or trying to make Linux work better in
an AFS environment?  If you are looking for a distributed filesystem without
concern for compatibility, do you care about non-Linux systems?

-- 
    John Carr ([email-masked])

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

From: [email-masked] (Richard Henderson)
Subject: Re: Alpha Linux
Date: 11 Sep 1994 18:55:42 GMT

In article <[email-masked]>,
Anton Ertl <[email-masked]> wrote:
>Why is this a good thing? And is it also a good thing that programs
>break that assume that an index into an array or the difference
>between to pointers fits into an int?

That is exactly what the ANSI types size_t and ptrdiff_t are
for -- use them.

>And if you say, that such things can be easily fixed by greping for
>"int" and replacing it with "TrueInt", you are wrong. In C int is not
>just another type, it affects many things in the language: Normal
>integer constants have the int type, int plays a special role in
>conversion rules, switch wants an int argument, etc.

No, switch wants a scalar.  And what do you mean by "normal" 
integer constants?  With sizeof(int) == 2, sizeof(long) == 4,
32768 unadorned with "L" is a long constant.

>I have debugged enough programs (one:-) that worked perfectly well on
>decent OSs on an Atari ST to know why I dislike
>sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
>least 5 hours of debugging time of two people (one of them an
>experienced Atari user).

I'll hazzard a guess that the problem of 3 vs 3L likely came
from not prototyping properly?

In short, there aren't nearly as many problems with
sizeof(int) != sizeof(void*) as you'd like to believe.

r~

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

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

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************