Subject: Linux-Development Digest #849
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Tue, 21 Jun 94 18:13:15 EDT

Linux-Development Digest #849, Volume #1         Tue, 21 Jun 94 18:13:15 EDT

Contents:
  Re: Shortest development path to new architectures. Was (assembly language) (Louis-D. Dubeau)
  Re: [Q]: Signal handling in Unix. (Salvatore Valente)
  Re: Solaris x86 disk = 82 = Linux swap (Alan Cox)
  Re: Disk-compression for Linux (Erkki Ruohtula)
  Re: Solaris x86 disk = 82 = Linux swap (Rob Janssen)
  Re: problems with kernel-modules (Frank Lofaro)
  VideoBlaster (Martin Oldfield)
  Re: Disk-compression for Linux (Brandon S. Allbery)
  Xkernel for Sun3 (Steve Meuse)
  Deadlock with unix domain sockets (Frank Lofaro)
  Re: 1.1.20 - Mosaic 2.4 broken? (Michael Bartmann)
  STC: Call for Volunteers to write a clone of ScreamTracker 3 for Linux (Daniel L. Marks)

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

From: hallu@babbage.info.polymtl.ca (Louis-D. Dubeau)
Subject: Re: Shortest development path to new architectures. Was (assembly language)
Date: Mon, 20 Jun 1994 15:52:03 GMT

>>>>> "DV" == Daniel Veillard <veillard@imag.fr> writes:

    DV>   What does god think of porting Linux to Mach micro-kernel ?

I spoke to god before starting the Linuxss project and he told me "go
ahead". But he said he wouldn't participate actively in the project
because he had other things to do (if I remember well).

|              Louis-Dominique Dubeau <hallu@info.polymtl.ca>
|Computer Engineering, Ecole Polytechnique de Montreal (Montreal, Quebec)
|Linux single server project (http://boole.info.polymtl.ca:1500/~hallu/)
|                     -> This sentence is false!!! <-
--
|              Louis-Dominique Dubeau <hallu@info.polymtl.ca>
|Computer Engineering, Ecole Polytechnique de Montreal (Montreal, Quebec)
|Linux single server project (http://boole.info.polymtl.ca:1500/~hallu/)
|                     -> This sentence is false!!! <-

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

From: svalente@ATHENA.MIT.EDU (Salvatore Valente)
Subject: Re: [Q]: Signal handling in Unix.
Date: 21 Jun 1994 12:09:49 GMT

In article <...>, root <root@doom.tromsomh.no> wrote:
>When compiling a program (CD's mudlib) I noticed that I had to change
>a lot of signal() calls in the source code. I got the impression that
>after a call from a SIGINT, you have to "de-signal" it again using
>signal(SIGINT, <this_function_name>);
>
>This seems very odd for me, and this behaviour is hardly what I have seen
>on other UNIX systems.

Well, on BSD systems you set up a signal handler by calling
"signal (SIGINT, function)"
Then, when a SIGINT is received, function() is called, and all SIGINTs
are blocked until function() returns.

For some reason that defies explanation, on SysV systems, the call
"signal (SIGINT, function)"
sets it up so that as soon as one SIGINT is received, the signal
catcher is immediately reset to SIG_DFL.  People try to defeat this
brain-damage by making the first line of function() call signal()
again.  However, this is really not the correct solution, because it
means that SIGINT is never blocked.  So, two signals in rapid
succession will either kill the program or interrupt function() to
call function() again, neither of which is really the desired
behavior.

Currently, Linux uses the SysV defintion of signal() by default.
There is some minor flamage going on about whether it should use the
BSD definition by default.  (Personally, I think it should.)  For now,
you can get the BSD definition on Linux by compiling with
-D__USE_BSD_SIGNAL.

This is probably explained more clearly in various Unix and Linux
FAQs.  Look around for them.

> The man page said that the information was obsolete
> and I have not yet seen any descriptions on this.

Yeah, the signal() man page is pretty bad.  Flame the LDP.  :-)


-- 
/*                 Sal Valente   <svalente@athena.mit.edu>               */
/*  All opinions stated here are shared by my school, my employer, my    */
/*  friends, my family, a large group of people I've never met, the      */
/*  entire cast of "Taxi," President Clinton, the Pope, Elvis, and you.  */

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Solaris x86 disk = 82 = Linux swap
Date: Tue, 21 Jun 1994 10:38:40 GMT

In article <TLP00.94Jun20140423@mtlyell.spg.amdahl.com> tlp00@mtlyell.spg.amdahl.com (Tibor Polgar) writes:
>This may be known, but in case it isn't.  Linux has defined filesystem type 82 as 
>linux swap.  This same filesystem type is used by Solaris to define UFS.  Now since 
>i assume Sun won't change their number, will Linux?  Do i report this problem as a 
>kernel bug or what?

There is nothing you can do about any of these numbers. The are assigned almost
at random with no formal authority. 

A tip however:
        Linux only uses the partition types in an advisory way, eg some of
the install programs use it. So you can install Linux and use a different
partition type. Now try that in Solaris ;-)

Alan

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

From: eru@tnso04.tele.nokia.fi (Erkki Ruohtula)
Subject: Re: Disk-compression for Linux
Date: 21 Jun 1994 11:08:43 GMT

In article <brett.772147292@iitbarr.iit.com> brett@iit.com (Brett Coon) writes:
>kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:
>> Also, with the PROVEN unreliability
>>of compressed file systems, you would only have a few people willing to use
>>it.  
>Compressed file systems are not inherently unreliable.  By its very
>nature, compression eliminates redundancy, which makes it harder to
>recover from disk errors.  However, a well-designed system with error
>control built-in could be more reliable than an uncompressed system.

Yes. Compressed filesystems have got a bad reputation in reliability
because most people have seen them working only under MS-DOS, where
they have two inherent reliability problems that would be absent in
Linux: any errant user program can nuke the data structures maintained
by the compression system, and the compression runs underneath a
normal MS-DOS file system, which is unaware of it (this last applies
to some degree even to Microsoft's DoubleSpace: for compatibility
with ill-behaved programs it has to present a normal-looking
disk layout). In Linux compression software would be protected like the
rest of the kernel, and it could be properly integrated with the file
system. Btw, anyone thinking of implementing a compressed Linux
file system should look at the paper "On-line Data Compression in a
Log-structured File System" in the ASPLOS proceedings of 1992, published
in SIGPLAN Notices September 1992. Log-structured file systems
are more resistant to crashes than conventional file systems,
and in the paper, the authors conclude that they are also better
suited for real-time compression.

--
Erkki Ruohtula     / Nokia Telecommunications Oy
eru@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland
(My private opinions, of course)

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Solaris x86 disk = 82 = Linux swap
Reply-To: pe1chl@rabo.nl
Date: Tue, 21 Jun 1994 07:31:58 GMT

In <TLP00.94Jun20140423@mtlyell.spg.amdahl.com> tlp00@mtlyell.spg.amdahl.com (Tibor Polgar) writes:

>This may be known, but in case it isn't.  Linux has defined filesystem type 82 as 
>linux swap.  This same filesystem type is used by Solaris to define UFS.  Now since 
>i assume Sun won't change their number, will Linux?  Do i report this problem as a 
>kernel bug or what?

There is no real problem with this, as Linux is not checking the filesystem
type, and you can put any value you like.  Linux simply puts all active
partitions in its in-memory table, so you can access them at will.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: problems with kernel-modules
Date: Tue, 21 Jun 94 00:32:07 GMT

In article <2u4ff5$avr@newsserv.cs.sunysb.edu> vassili@cs.sunysb.edu (Vassili Leonov) writes:
>luca@genova.world wrote:
>: >it happend that insmod found some 'unresolved externels' when inserting
>: >the driver, so i examined the kernel-symbol-table which is read by insmod.
>: >i found out that some symbols, which are not in this list, may be used, while
>: >others may not.
>
>: This has happened also to me but then thanks to the author of this
>: very useful package i found the problem.
>: In the kernel directory of the kernel source files tree there is a
>: file called "ksyms.c" where the symbol table for the kernel is
>DONT'T DO THIS!!! Move to the kernel version at least 1.1.13 - all this stuff
                                                       ^^^^^^
>is included there - and in a much cleaner way! Don't use modules on the
>older versions of the kernel.
>Vassili.

Be careful if you use SLIP!
The driver has been unreliable from 1.1.13-1.1.20. ping -l 100 slipserver
causes a panic, for example. You've been warned. 1.1.11 and probably 1.1.12 
doesn't have that problem (I think the new-tty code brought in at 1.1.13 
does it). 1.1.13 and beyond are to be considered bleeding edge alpha code. 
Don't rush into it unless you are sure of what you are doing.







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

From: mjo@mrao.cam.ac.uk (Martin Oldfield)
Subject: VideoBlaster
Date: 21 Jun 1994 12:00:03 GMT

Has anyone started work on a device driver for Creative Lab's
VideoBlaster ?

Thanks,
--
Martin Oldfield, MRAO, Cavendish Labs, CAMBRIDGE, CB3 0HE
Work:  0223 337365 Fax: 0223 354599 Home: 0223 67940
The most positive man is the most credulous - Pope

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Disk-compression for Linux
Date: Tue, 21 Jun 1994 11:33:53 GMT

In article <2u66i0$ac2@urmel.informatik.rwth-aachen.de>, dak@hathi.informatik.rwth-aachen.de (David Kastrup) says:
+---------------
| dupke@koma.han.de (Kai Dupke) writes:
| >albayrak@cc.helsinki.fi wrote:
| 
| >:    3. Would it be better to implement whole new file-system
| >:       rather than compress data through some existing
| >:       file-system (like ext2) by using a large file as an compressed
| >:       'disk' (that's how Stacker and DoubleSpace does it).
| I hope not. One bad sector would ruin the rest of your disk.
| Better compress scraps.
+------------->8

Stacker and DoubleSpace use a file to hold the compressed disk image (so they
can use the original DOS I/O routines instead of having to implement their own
hardware drivers), but they compress individual virtual blocks.  You will only
lose individual blocks to e.g. bad sectors --- unless the corruption is in an
allocation record, but that's no different in practice from corruption in the
inode table.

That doesn't mean I particularly trust disk compression :-)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

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

From: swave@dalek.syn.com (Steve Meuse)
Subject: Xkernel for Sun3
Date: Tue, 21 Jun 1994 13:07:46

Hello All,
           I'm trying to get my hands on the Xkernel for linux that allows you 
to boot Sun 3's. I cant find it anywhere. If you dont know where it is, but
for some reason know the file name, drop me a not. In fact I could use
any and all information about the Kernel. Thanks in advance!


Steve Meuse      swave@dalek.syn.com

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Deadlock with unix domain sockets
Date: Tue, 21 Jun 94 05:59:13 GMT

There is a deadlock with unix domain sockets.
It causes one of the test for Tcl-DP to hang.
The test does something like the following:

dp_connect -server ~/socket
dp_connect ~/socket
dp_accept ~/socket

Or the syscalls:

Create server socket.
Bind server socket to pathname
Listen on server socket.
Create client socket.
Connect to server socket.       <--- deadlock
Accept on server socket.

Linux makes the connect to the server socket block until there is an accept
performed on the server socket. But that will not occur until the connect 
goes through, since the process is blocked waiting in connect().

So the kernel makesthe connect() block until the accept().
The app does not call accept() until the connect() is done.

So each operation waits for the other and since there hasn't been a 
successful accept/connect, there can't be a successful connect/accept, 
and so on forever. I.e. deadlock.

TCP/IP sockets do not do this. The connect returns immediately.

Granted the unix domain socket deadlock isn't too bad, but some programs 
may talk to themselves over a unix domain socket for testing/benchmark 
purposes. SunOS 4.1.3 doesn't have this problem. I saw in the kernel 
sources a comment saying deadlock is "ignored, in true unix fashion.", but 
since SunOS doesn't, it doesn't sound too unixy :).

How hard would it be to fix the deadlock? Could it break anything else?

If anything, it would be nice to have tcl-DP finish its tests without 
hanging. :/


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

From: bart@scotch.NoSubdomain.NoDomain (Michael Bartmann)
Subject: Re: 1.1.20 - Mosaic 2.4 broken?
Date: 21 Jun 1994 06:27:34 GMT

In article <1994Jun20.063018.737@kshome.ruhr.de>, karsten@kshome.ruhr.de (Karsten Steffens) writes:
|> Ralph Sims (ralphs@locus.halcyon.com) wrote:
|> : whywhyZ (yyz@video.ne) wrote:
|> 
|> : What is your MTU setting?  You might try running 966, if you've been
|> : using a much lower setting.  Or, beef up your lower setting in increments
|> : of 40 MTU's until the problem goes away (if, in fact, it DOES go away).
|> : I'd suggest data fragmentation due to blocksizes incompatible with
|> : Mosaic.  Since Mosaic is the only constant in your equation... ????
|> 
|> 296. Increasing to 966 did not help, either. So there must be another
|> problem. I even tried MTU 1500... no use. And Mosaic 2.4 is working with
|> 1.1.19, only 1.1.20 makes the problems.
|> 
|> Karsten
|>

I am using Linux-TCP/IP since 0.98 and my WD-kompatible SMC-Elite
never had problems with Mosaic.
But now: the same problem as Ralph Sims reported, I cannot access
URLs OUTSIDE of our domain using 1.1.20.
All other TCP/IP stuff works well though.
Maybe some timeout values have changed ?

Clueless,   Michael
 
-- 
Michael Bartmann                | internet: bartmann@rog.rwth-aachen.de
Rogowski Institut RWTH-Aachen   | tel:      0241/80-7584
52062 Aachen, Schinkelstr. 2    | fax:      0241/80-7605

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

From: dlm40629@uxa.cso.uiuc.edu (Daniel L. Marks)
Subject: STC: Call for Volunteers to write a clone of ScreamTracker 3 for Linux
Date: 21 Jun 1994 06:58:39 GMT



  A Linux Project

  June 21, 1994       
  STC: ScreamTracker 3.01 Clone (the tenative name)
  A Call For Participation

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

1) ScreamTracker Clone - what is it? 

        For the past few weeks, I have been writing code that will
eventually become part of a ScreamTracker 3.01 clone.  ScreamTracker 3
is a music composition program.  Unlike a MIDI composition or
sequencing program, tracker music formats are more for creating on the
computer itself, rather than through a synthesizer.  Instead of
storing music as events, it stores music as "patterns," or slots for
notes to be played at certain beats.  I have written s3mod, which is a
Linux program that will play Future Crew ScreamTracker 3, Amiga
Protracker, and Triton FastTracker files on /dev/dsp supported
devices, or a GUS.  STC will be a player AND an editor.  It will allow
the patterns, orders, and instruments to be changed.  Like the name
suggests, it will be strongly patterned after ScreamTracker 3, though
it will not be the same because some of the limitations and advantages
of Linux.

2) Why write STC?

        A month or two ago, Future Crew released Screamtracker 3.01 to
the public.  IMHO, ScreamTracker 3 is the best program of its kind
(tracker music editor) for any computer.  Unfortunately, its author,
Psi of Future Crew, has stated that he will no longer support the
program.  This disappointed me, I must admit, that such a fine music
composition would not continue to be improved.  ScreamTracker 3 is
only available for MS-DOS, and it still has some annoying bugs in it.
I think that there is an opportunity here to improve on ScreamTracker,
and create a killer Linux application in the process.

3) What are the objectives of STC?

        The objectives of STC are to write a tracker editor that will
support many music formats including S3M, MOD, MTM, 669, and
SoundSmith.  It will convert them all internally to be S3M files so
that they can be edited just like ScreamTracker 3 allows.  The
original ST3 will be used as a guideline because of its successful use
when employed by the Future Crew music writers.  The program will be
written to be as portable as possible, not only to run on versions of
Linux for other non PC-compatible architectures, but hopefully
for other operating systems as well, including DOS via djgpp.

4) What is it written in, how does it work, what is done so far, etc.?

        Currently STC is written in Objective C.  Objective C, a
language that comes standard with the gcc distribution, is another
object oriented version of C.  I have used it rather than C++ because
its dynamic binding capabilities are far superior to that of C++, and
because I like it much more.  Objective C is the language used to
write most of the NextSTEP Operating System.  If you are thinking
about contributing to STC, but don't know Objective C, you should not
worry because Objective C is very easy to learn.  Objective C borrows
from the Smalltalk language (except for speed and efficiency), so
those who know it should have no trouble at all.  I don't believe
being written in Objective C will hinder portability because gcc is
supported with Objective C on all platforms gcc is available for.
        For STC I am writing Objective C classes to turn the NCURSES
library into a event-driven windowing system.  I have also stolen the
code from the "selection" program and created a SerialMouse class so
that STC will have mouse support.  The CursesManager class sets up
NCURSES, including the color, and opens the mouse device.
CursesManager then goes into a run loop and reads events from the
mouse and keyboard, turns them into Objective C messages, and sends
them down the "responder chain."  CursesWindow objects are
hierarchially organized inside each other.  A CursesWindow may contain
other windows, but it may not overlap other windows (an effect not
visually pleasing in a text mode, and hard to maintain on terminals).
Except for a few playing bugs yet to be ironed out (my Gravis
Ultrasound is on its way in the mail), the program s3mod is mostly
converted to Objective C, and has been changed so that songs,
instruments, and patterns are manipulated in memory in a file type
independent format.

5) What license will it be covered under?

        The GNU Public License, of course.  STC, and all its supporting
programs and files will be GPL.  Hopefully STC will server as good
example code of a tracker, and will be useful in coding demos.

6) Who do I need to volunteer?

        Initially I need people who are experienced C coders under
Linux who know or are willing to learn Objective C.  Experience in
programming NCURSES, the Linux sound drivers, the Gravis Ultrasound,
different tracker file formats, or knowing how to write a tracker in
general can all be useful to this project.
        Later, we will need experienced tracker music writers to 
test the software and develop the user interface.  If you are interested
in testing the software, and can write music with a tracker program,
let me know.
        Inquiries into STC can be made to myself,
dlm40629@uxa.cso.uiuc.edu .

7) Where can you get ScreamTracker 3 and see what I'm talking about?

ScreamTracker 3 is available at
ftp.uwp.edu:/pub/msdos/demos/music/ptrackers/scrmt301.zip

Music in S3M and other formats is also available on the same site.

Dan Marks
dlm40629@uxa.cso.uiuc.edu

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

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