Subject: Linux-Development Digest #837
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:     Thu, 16 Jun 94 15:13:10 EDT

Linux-Development Digest #837, Volume #1         Thu, 16 Jun 94 15:13:10 EDT

Contents:
  Anyone built tclX linux shared lib? (Neal Becker)
  Re: PLIP throughput.. (John Romein)
  Re: Driver for MPU compatible MIDI interface? (Bjoern Giesler)
  Driver for PCI video cards with S3 VisionX64 chips? (Christoph Berger)
  Re: Status of Modules in Kernel? (Vassili Leonov)
  Re: No Networking w/ Kernel > v1.1.12 (Vassili Leonov)
  Re: getting a value from a port using inb() (Michael K. Johnson)
  Re: My problem? GCC problem? Linux problem? (Charles Hedrick)
  DOSEMU and Novell (Andrew Anderson)
  Linux serial programming (Jim Trocki)
  Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13. (Alan Cox)
  Re: PLIP throughput.. (Alan Cox)
  Re: IDE PERF. PATCH SECURITY HOLE (Mark Lord)
  Re: Anyone built tclX linux shared lib? (Cowie)
  Re: TCP connections too slow to initialize (Mark Evans)
  Re: PGP 2.6 for Linux (Erik Troan)
  Re: Driver for MPU compatible MIDI interface? (Byron A Jeff)
  Re: TCP connections too slow to initialize (Alan Cox)
  question on POSIX.1 & POSIX 1003.4 (P Copeland)
  AD Driver (20MHz) finished, what are the next steps?? (Bernd Mielke)
  Re: Symmetric Multiprocessing for Linux? (max jester)

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

From: neal@ctd.comsat.com (Neal Becker)
Crossposted-To: comp.lang.tcl
Subject: Anyone built tclX linux shared lib?
Date: 16 Jun 1994 12:08:40 GMT

Has anyone tried to build tclX shared libs on linux?

Thanks.

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

From: john@cs.vu.nl (John Romein)
Subject: Re: PLIP throughput..
Date: Thu, 16 Jun 1994 12:30:59 GMT

genie@sting.Berkeley.EDU (Gene Choi) writes:
: 
: Hello there,
: 
: I was experimenting with PLIP 1.02 and linux kernel 1.1.0.
: I connected a 386/20 and a 386/33 together with a parallel laplink
: cable.  I noticed that throughput with FTP was only about 14Kbytes/sec.
: Sure this is way better than any serial connection will give.  However,
: I'm wondering if there is any way to increase this number, and to
: ask if these are the kinds of results I should expect?
: 
: If I remember correctly, using LapLink, some people were copying
: things over the parallel port at least 50-100kbytes/sec,  Sure
: linux is not DOS, but it sure would be nice to have these kinds of results,
: especially using NFS as I plan between the two computers.
: 
: -Gene
: 
: -- 
: Zima zux!
: 

The actual throughput depends very much on the speed of the processors
that are used.  The plip-code is very CPU-intensive, because it has to
split and shift each byte into two 4-bit quantities, and toggle a 5th bit.

John Romein

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

From: un4e@rzstud1.rz.uni-karlsruhe.de (Bjoern Giesler)
Subject: Re: Driver for MPU compatible MIDI interface?
Date: 16 Jun 1994 12:57:07 GMT

Andreas Toenne (atoenne@mpi-sb.mpg.de) wrote:

: intelligent device running the MPU in dumb UART mode but having an internal
: timebase to annotate MIDI events with timestamps wrt. PPQ/MIDI clock.
: This will be essentially a serial driver at a fixed speed with some
: extras.

Yes, DO write one! I'm desperately waiting for something like that to
turn up, since I am currently writing a sequencer for Linux/X11, but don't
have the knowledge of the Linux internals to write a driver on my own.
So far, my sequencer only theoretically supports the m4u serial interface
by Waldorf, which hasn't been released yet.

Hannu Savolainen told me about four weeks ago that he was about to upload
a new version of the VoxWare drivers the following week, which didnt happen
so far.

So please, if you have the ability, write such a driver! I would be very 
grateful (many others as well, suppose).

Bjoern

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

From: berger@informatik.tu-muenchen.de (Christoph Berger)
Subject: Driver for PCI video cards with S3 VisionX64 chips?
Date: 16 Jun 1994 13:02:03 GMT

In the PCI-HOWTO of April, 20th (I think it's the newest version) I
read that the chipsets named S3 Vision 864, or Vision 964,
resp. aren't supported by Linux yet. However, I want to get a miro
Crystal 20SD, that contains these chips. Are there any suitable
drivers under development?

        Christoph
--
| Christoph Berger                        berger@informatik.tu-muenchen.de |
|                                                        c.berger@ieee.org |
|                                               Christoph_Berger@m.maus.de |


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

From: vassili@cs.sunysb.edu (Vassili Leonov)
Subject: Re: Status of Modules in Kernel?
Date: 15 Jun 1994 21:06:25 GMT

Christian Holtje (choltje@ux1.cso.uiuc.edu) wrote:
: What is the status of including modules in the Kernel? Are they going to be
: the way of the future? (I saw the /proc/modules and the /linux/modules
In version 1.1.13 they work perfectly (so far to me). I'm using them
to load and unload drivers that I'm writing. Very convinient - compared
to rebooting the system ;-) You hook to an irq on the fly and unhook
as weel. Great stuff!!!
Vassili.

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

From: vassili@cs.sunysb.edu (Vassili Leonov)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: Re: No Networking w/ Kernel > v1.1.12
Date: 15 Jun 1994 21:27:49 GMT

Jon D. Cardwell (jdc@garnet.msen.com) wrote:
: I've been using Linux kernel 1.1.12, and recently went to 1.1.19.
: I also fetched and installed the route program from
: ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linux, but now, even
: after I've set up my route correctly, I can't telnet or FTP
: from one machine to another on a local LAN. I can ping OK
: from one machine to the other, but nothing else works...

: I'm clueless. Can anybody help me out here?
My feeling is that around version 1.1.13 the ip forwarding is not
enabled by default. And you can't change this setting from the
config file (because it's not there ;-) well - it seems like in
version 1.1.18 it's configurable. Anyway - I have got simular problems -
and while fixing that fixed some other problems on my network
(i.e. unneeded frowarding)...
Vassili.

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

From: johnsonm@merengue.oit.unc.edu (Michael K. Johnson)
Subject: Re: getting a value from a port using inb()
Date: 16 Jun 1994 01:39:13 GMT


In article <2tn32h$idq@coranto.ucs.mun.ca> rickp@newton.physics.mun.ca (Rick Power C-3028 x-8844) writes:

   Hi, I have a program which I have listed here to get the value at a port
   using the inb() routine in linux. Somehow I manage to screw up - the
   program is a test -- before I start hacking at ieee 488 controller code
   I want to get the basics down - My program follows -- could someone tell
   me what I am doing wrong

   [program omitted]

   how I compile:

   rupert:~> gcc thefileabove.c -o port_listen

*Here* is your problem.  This is a FAQ, BTW.  You need to compile with
-O or -On, for n in N (integers greater than 0...) for gcc to pick up
the (this is the tricky part) ** inline ** definitions of inb() and
outb().  Because they are inline, you won't get error messages that
look like this:

   /tmp/cca013471.o: Undefined symbol ___inbc referenced from text segment
   /tmp/cca013471.o: Undefined symbol ___inb referenced from text segment

michaelkjohnson

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

From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: My problem? GCC problem? Linux problem?
Date: 16 Jun 94 01:30:06 GMT

ablumer@hubcap.clemson.edu (Aric D. Blumer) writes:

>> void example(s)
>> char *s;
>> {*s = 'h';}
>> void main()
>> {example("Hello!");}

>Should this code cause a Segmentation fault?
>It does running Linux 1.0 and compiled with GCC 2.5.8!
>It doesn't on my Sun.

Yes, it should cause a segmentation fault (or an error of some
kind).  You are trying to change a character in a string
constant.  It's up to the implementor whether this is detected,
but it's certainly bogus code.  I would bet that GCC is putting
string constants in read-only code space.  An attempt to write
to that will generate an error.

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Crossposted-To: comp.os.linux.help
Subject: DOSEMU and Novell
Date: 16 Jun 1994 01:47:59 GMT

I have gotten DOSEMU to allow me to telnet into my Linux box and
login to my Novell file server.  However, DOSEMU appears to be hard-
coded somewhere to use the eth0 network device.  I did a grep on all
of the source code to DOSEMU, and changed all references to the eth0
device, but it will not talk to eth1.

I need to have DOSEMU run on 2 different cards, because the netx client
will give me a security breach if 2 users try to login from the same
ethernet hardware address.  I have asked the novell group if vlm's fix
this (like the OS/2 requestor), but no one has replied.  I really need
to have the ability to run multiple DOSEMU sessions into my Novell
server, so any pointers are appreciated!

Also, while on the subject of DOSEMU, can anyone tell me where to start
looking for the code that updates the screen during a telnet session?
I have noticed that the top half of the screen works pretty well, but
DOSEMU doesn't want to update the bottom half of the screen if it doesn't
have to.  Or is this being worked on in the new release that others
have said is due out "RSN"?

Thanks for any help on any part of this problem,
Andrew

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                         andrew_anderson@cts.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: trockij@Cyanamid.COM (Jim Trocki)
Subject: Linux serial programming
Reply-To: trockij@Cyanamid.COM
Date: Thu, 16 Jun 1994 12:55:38 GMT

  I'm interested in developing a call-waiting monitor which identifies incoming
calls for my Supra modem hooked to my Linux PC. Where can I begin reading about
how to control the serial port with Linux? Are there any simple, reasonably documented
programs that I can refer to as a "hack tutorial"?


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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13.
Date: Thu, 16 Jun 1994 13:31:22 GMT

In article <GTHAKER.94Jun15135411@polyphony.sw.stratus.com> gthaker@polyphony.sw.stratus.com (Gautam Thaker) writes:
>Will this have to wait till full NET 3 or will this be patched
>sooner? 

Probably not sooner unless someone else chooses to take it up. Because of the
way the socket layer/protocol layer needs splitting cleanly it would mean doing
a lot of work before hand and throwing it away.
>
>Will SOCK_DGRAM be supported fully for AF_UNIX?

I hope so. I consider the current AF_UNIX support to be totally inadequate 
although its awfully good at running X

ALan



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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: PLIP throughput..
Date: Thu, 16 Jun 1994 13:36:54 GMT

In article <2tns8c$6v5@agate.berkeley.edu> genie@sting.Berkeley.EDU (Gene Choi) writes:
>>If I remember correctly, using LapLink, some people were copying
>things over the parallel port at least 50-100kbytes/sec,  Sure

Laplink can lock the machine solid for the transfer.. Linux has things to do
and the parallel port wasnt designed for this.

Alan





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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: 16 Jun 1994 14:01:52 GMT

In article <CrGHMM.3M5@frobozz.sccsi.com> kevin@frobozz.sccsi.com writes:
>In article <2tn06k$sm@bmerha64.bnr.ca>, Mark Lord <mlord@bnr.ca> wrote:
>>In article <CrFA2D.2IK@ucdavis.edu> kevin@frobozz.sccsi.com writes:
>>..
>>>2.  "Read-only" access to a device means just that: you can read
>>>    attributes, data, etc. from the device, but you can't make any
>>>    changes to either the status or the data.  Changing a device
>>>    to multiple-mode should thus require write access to the device,
>>>    since that's an attribute change.
>>
>>Hmm.. on my system, I want my "read-only" devices to be just as fast
>>as my read-writable ones.
>
>...and for normal operations (i.e., data reads/writes), it isn't a problem,
>because the open() system call takes care of access control.
>
>The ioctl() interface is different, of course, but do you really
>use it often enough that speed is enough of a concern that it would
>override implementing the "correct" behavior?

The ioctl() call to enable multiple sector reads needs to be done
once per drive after each system reboot.  It does not modify the drive
or any data on it in any physical way, but rather it sets a state in
the linux hd.c disk driver.    

There should remain a way to do this, regardless of whether the device
is read-only or not.  So...

>>  I'll add a check for superuser to the ioctls,
>>and possibly a per-partition enable/disable for the package.
>
>Not what I would consider to be the right answer...oh, well....:-)

Cheers!  :)
-ml
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: martymoo@dcs.qmw.ac.uk (Cowie)
Crossposted-To: comp.lang.tcl
Subject: Re: Anyone built tclX linux shared lib?
Date: 16 Jun 1994 15:23:14 GMT

Neal Becker (neal@ctd.comsat.com) wrote:
: Has anyone tried to build tclX shared libs on linux?

As far as I know they came with my Slackware distribution of Linux, and very nice
they were too. ;)

        Marty
--
...poor fool. Born on the windy side of sense....

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

From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: TCP connections too slow to initialize
Date: Thu, 16 Jun 1994 16:05:40 GMT

David Simmons (simmons@EE.MsState.Edu) wrote:
: On a recent linux installation, I noticed that TCP connections took far
: too long to initialize.  Telnet and finger would hang for a minute or
: so before giving a login prompt or a finger connection.  The problem
: only seemed to occur when connecting to another Linux machine; connections
: to Suns were normal.  The other linux machines could connect fast to this
: one.

Have you checked your nameserver setup. Notably that you do not have a
dead/unreachable entry in /etc/resolv.conf?

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

From: ewt@merengue.unc.edu (Erik Troan)
Subject: Re: PGP 2.6 for Linux
Date: 16 Jun 1994 16:02:13 GMT

In article <2tna93$k1i@pccross.msk.su>,
Eugene Crosser <crosser@pccross.msk.su> wrote:
>In <061394122515Rnf0.78@runic.mind.org> thantos@runic.mind.org (Alexander Williams) writes:
>
>>>If anyone knows what's up, I would appreciate a hint.  As a side comment, I
>>>wonder if any linux site is going to carry the binary of PGP 2.6...

Sunsite won't carry it (I have at note in Incoming to that effect). We're in
the US, and it isn't worth the hassle.

Sorry,

Erik

-- 
===========================================================================
"I'm not like that -- except when I am"   ewt@sunsite.unc.edu  = Erik Troan
                                          sasewt@unx.sas.com
    - Nora from "Pump up the Volume"

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

From: byron@gemini.cc.gatech.edu (Byron A Jeff)
Subject: Re: Driver for MPU compatible MIDI interface?
Date: 16 Jun 1994 16:52:22 GMT

In article <ATOENNE.94Jun16111703@mpii02013.mpi-sb.mpg.de>,
Andreas Toenne <atoenne@mpi-sb.mpg.de> wrote:
>Hi!
>
>I wonder if there is a device driver for MPU compatible MIDI
>interfaces like the Roland, MQX or newer Soundblaster cards?
>
>
>If such a best does not exist I will write one:
>intelligent device running the MPU in dumb UART mode but having an internal
>timebase to annotate MIDI events with timestamps wrt. PPQ/MIDI clock.
>This will be essentially a serial driver at a fixed speed with some
>extras.

Now hold on pardner! Check out the standard sound driver in the kernel.
It already has a MPU-401 interface and does time-stamp. It even has a
/dev/sequencer device for getting the timestamped events.

So look at it first before writing anything.

BAJ
-- 
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: TCP connections too slow to initialize
Date: Thu, 16 Jun 1994 13:45:07 GMT

In article <2to23a$1p0@Tut.MsState.Edu> simmons@EE.MsState.Edu writes:
>in hopes of fixing the problem, but to no avail.  A quick 'sum' showed that
>the 'telnet' binary was identical to the one on the other machines, which
>leads me to believe that the problem must lie somewhere in the kernel
>networking code...

It sounds like a misconfigured name server entry when telneted does the
reverse DNS lookup.

Alan


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

From: p2_copel@banana.uwe.ac.uk (P Copeland)
Subject: question on POSIX.1 & POSIX 1003.4
Reply-To: p_copela@csd.bristol-poly.ac.uk
Date: Thu, 16 Jun 1994 13:32:03 GMT

I'm afraid that the following is a bit long so bare with me. I wish to know
about two aspects of posix complience and RT support in the Linux system

I'm in the middle of exams here but revising through my computing papers, I
came across the following text of signal safe re-enterant functions ie you can
use these functions with signals without having any restrictions or undefined
behaviour. 
        My question is if any of these fail in linux as i'm not sure if i could
code up enough signal traps to check all of these, I suspect that this is one
for hju and co.

(any functions not on this following list are not defined).. 
begin palagerisation(sp?)

access()        alarm()         cfgetispeed()   cfgetospeed()   cfsetispeed()
cfsetospeed()   chdir()         chmod()         chown()         close()
creat()         dup()           dup2()          execle()        execve()
_exit()         fcntl()         fork()          fstat()         getegid()
geteuid()       getgid()        getgroups()     getpgrp()       getpid()
getppid()       getuid()        kill()          link()          lseek()
mkdir()         mkfifo()        open()          pathconf()      pause()
pipe()          read()          rename()        rmdir()         setgid()
setpgid()       setsid()        setuid()        sigaction()     sigaddset()
sigdelset()     sigemptyset()   sigfillset()    sigismember()   sigpending()
sigprocmask()   sigsuspend()    sleep()         stat()          sysconf()
tcdrain()       tcflow()        tcflush()       tcgetattr()     tcgetpgrp()
tcsendbreak()   tcsetattr()     tcsetpgrp()     time()          times()
umask()         uname()         unlink()        ustat()         utime()
wait()          waitpid()       write()


NOTE: the X/Open portibility guide issue 3 requires that the following also 
be 'safe' with respect to signals.

abort()         chroot()        exit()          longjmp()

Next, being a Computing for Real Time Systems student, Posix 1003.4 draft9;
does Linux now have full hooked support for RT applications?
(Text book definition for those who don't know: A RT system is one that can 
guarentee bounded response time to requests for services. Traditional UNIX
systems are not RT because any process can be blocked indefinitely)
        The 1003.4 committee has defined 11 areas where standard interfaces 
are required for RT application programs.
        
        Interface                       Linux

        Binary semaphores               [x] Don't know but i think it's 
                                            There in terms of /dev blocking
        Process memory locking          [?] I think Linus has an algorthem
                                            that tries to work it out
                                            rather than let the program set
                                            it
        Shared memory                   [?] apperently the SysV standard is
                                            not defined or used by 1003.4!
                                            again I'm unsure of the status
                                            of it.
        Priority scheduling             [?] I looked at the Kcode
                                            for this and i'm confused. nice()
                                            drops the priority ok but the
                                            kernel resets it ?!?
        Asynconous event notification   [?] NOT the same as a signal, events
                                            can be queued, I don't know about 
                                            this in linux
        Timers                          [?] sleep() and alarm() are implemented
                                            BUT posix.4 wants nanosleep()
        Interprocess communication      [x] Posix.4 again threw out SysV's version
                                            and decided to use special files???
                                            sounds crazy to me.
        Synchronized I/O                [?] Guarenteed writes, (flush()?) I don't
                                            know if the kernel pretends to write
                                            it or really commits the data to disk
                                            NB NOT SYNCRONOUS
        Asynchronous I/O                [x] This does work,... returning before
                                            operation is complete
        Real Time (high perf.) files    [x] umm,... I suppose swap space qualifies
                                            generally pre-allocation of continuous
                                            files (not fragmented)
        Threads                         [x] Alpha/beta test code in
                                            user space



===============================================================================
  Philip Copeland - aka 'Bryce'                                 (SysAdmin)
  p_copela@uk.ac.uwe.csd
  root@zen.btc.uwe.ac.uk
                                  "... I can resist anything but temptation..."
===============================================================================



Newsgroups: comp.os.linux.development
From: p2_copel@banana.uwe.ac.uk (P Copeland)
Path: pat!p2_copel
Distribution: world
Followup-To: 
Reply-To: p_copela@csd.bristol-poly.ac.uk
Organization: The New University in the West of England, Bristol
(WEB)xrn.replyTo:                    p_copela@csd.bristol-poly.ac.uk
Subject: POSIX.1 & POSIX 1003.4
Keywords: 

I'm afraid that the following is a bit long so bare with me. I wish to know
about two aspects of posix complience and RT support in the Linux system

I'm in the middle of exams here but revising through my computing papers, I
came across the following text of signal safe re-enterant functions ie you can
use these functions with signals without having any restrictions. My question
is if any of these fail in linux as i'm not sure if i could code up enough
signal traps to check all of these, I suspect that this is one for hju and co.

(any functions not on this following list are not defined).. 
begin palagerisation(sp?)

access()        alarm()         cfgetispeed()   cfgetospeed()   cfsetispeed()
cfsetospeed()   chdir()         chmod()         chown()         close()
creat()         dup()           dup2()          execle()        execve()
_exit()         fcntl()         fork()          fstat()         getegid()
geteuid()       getgid()        getgroups()     getpgrp()       getpid()
getppid()       getuid()        kill()          link()          lseek()
mkdir()         mkfifo()        open()          pathconf()      pause()
pipe()          read()          rename()        rmdir()         setgid()
setpgid()       setsid()        setuid()        sigaction()     sigaddset()
sigdelset()     sigemptyset()   sigfillset()    sigismember()   sigpending()
sigprocmask()   sigsuspend()    sleep()         stat()          sysconf()
tcdrain()       tcflow()        tcflush()       tcgetattr()     tcgetpgrp()
tcsendbreak()   tcsetattr()     tcsetpgrp()     time()          times()
umask()         uname()         unlink()        ustat()         utime()
wait()          waitpid()       write()


NOTE: the X/Open portibility guide issue 3 requires that the following also 
be 'safe' with respect to signals.

abort()         chroot()        exit()          longjmp()

Next, being a Computing for Real Time Systems student, Posix 1003.4 draft9
does Linux now have full hooked support for RT applications?
(Text book definition for those who don't know: A RT system is one that can 
guarentee bounded response time to requests for services. Traditional UNIX
systems are not RT because any process can be blocked indefinitely)
        The 1003.4 committee has defined 11 areas where standard interfaces 
are required for RT application programs.
        
        Interface                       Linux

        Binary semaphores               [x] Don't know but i think it's 
                                            There in terms of /dev blocking
        Process memory locking          [?] I think Linus has an algorthem
                                            that tries to work it out
                                            rather than let the program set
                                            it
        Shared memory                   [?] apperently the SysV standard is
                                            not defined or used by 1003.4!
                                            again I'm unsure of the status
                                            of it.
        Priority scheduling             [?] I looked at the Kcode
                                            for this and i'm confused. nice()
                                            drops the priority ok but the
                                            kernel resets it ?!?
        Asynconous event notification   [?] NOT the same as a signal, events
                                            can be queued, I don't know about 
                                            this in linux
        Timers                          [?] sleep() and alarm() are implemented
                                            BUT posix.4 wants nanosleep()
        Interprocess communication      [x] Posix.4 again threw out SysV's version
                                            and decided to use special files???
                                            sounds crazy to me.
        Synchronized I/O                [?] Guarenteed writes, (flush()?) I don't
                                            know if the kernel pretends to write
                                            it or really commits the data to disk
                                            NB NOT SYNCRONOUS
        Asynchronous I/O                [x] This does work,... returning before
                                            operation is complete
        Real Time (high perf.) files    [x] umm,... I suppose swap space qualifies
                                            generally pre-allocation of continuous
                                            files (not fragmented)
        Threads                         [x] Alpha/beta test code in
                                            user space



===============================================================================
  Philip Copeland - aka 'Bryce'                                 (SysAdmin)
  p_copela@uk.ac.uwe.csd
  root@zen.btc.uwe.ac.uk
                                  "... I can resist anything but temptation..."
===============================================================================




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

From: mielke@omega.physik.fu-berlin.de (Bernd Mielke)
Subject: AD Driver (20MHz) finished, what are the next steps??
Date: Thu, 16 Jun 1994 13:41:13 GMT

Hallo,


Today I finished the work on a driver for an ADC (12 bit 20MHz) with parallel
photoncounting(300 MHz counting rate). I think it as good board, so I would 
like to make the driver publically available.
So I would like to know, what is the standard way for doing this.

Bernd

mielke@omega.physik.fu-berlin.de
 


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

Date: Wed, 15 Jun 1994 18:56:11 -0500
Subject: Re: Symmetric Multiprocessing for Linux?
From: mwjester@seldon.cs.twsu.edu (max jester)

benke@mimuw.edu.pl (Marcin Benke) writes:
:
: In article 68328@sdcc12.ucsd.edu, imcclogh@cs.ucsd.edu writes
:
: > >Are there plans afoot to extend Linux to support symmetric
: > >multi-processing (a la Mach?)
: >
: > I sincerely doubt it, since as far as I know, Linux only runs on
: > 386-architecutre
:
: There is a series of WYSE machines which have true SMP and are 486 based.
: I even once thought of launching a project to port Linux there, but WYSE was not interested.

Wyse's SMP implementation is indeed intel-based but very proprietary.
The new systems based on Intel's SMP standard, like the one recently
announced by ALR, would appear to be the way to go.

Regards,
Max J.
mwjester@seldon.cs.twsu.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
******************************
