From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Newsgroups: comp.os.linux
Subject: (none)
Date: 15 Aug 92 00:43:20 GMT
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Organization: The Internet

|From Linux-Activists Fri Aug 14 20:00:16 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 20:35 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
	 id AA25945; Fri, 14 Aug 92 20:09:05 EDT
Received: by bloom-picayune (5.57/25-eef)
	id AA18538; Fri, 14 Aug 92 20:00:40 -0400
Message-Id: <9208150000.AA18538@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 20:00:16 EDT
Subject:  Linux-Activists Digest #634
Content-Type: text
Content-Length: 13222

Linux-Activists Digest #634, Volume #2           Fri, 14 Aug 92 20:00:16 EDT

Contents:
  Re: Problem w/ folppy boot when CD-ROM is attached to scsi controller (Eric Youngdale)
  Re: Stabilizing Linux (Drew Eckhardt)
  Re: Diamond Speed Star SVGA card (Drew Eckhardt)
  Re: X questions: how to run x-program on other machine? (Drew Eckhardt)

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

From: eric@tantalus.dell.com (Eric Youngdale)
Subject: Re: Problem w/ folppy boot when CD-ROM is attached to scsi controller
Date: 14 Aug 92 21:18:13 GMT

In article <1992Aug14.193537.15994@nas.nasa.gov> chiu@wk211.nas.nasa.gov (Ing-Tsau Chiu) writes:
|I got the following message when booting Linux 0.97 from floppy
|
|  aha1542_queuecommand: Two concurrent queuecommand?
|  70 00 02 00 00 00 00 0a 00 00 00 00
|
|I have an Adaptec 1542B scsi controller and a Toshiba XB3201 CD-ROM
|drive.  The computer is a clone 486/33 w/ Maxtor LXT-535 scsi disk.

        There are bugs in the error handling code in the stock scsi drivers
in 0.97.  (I am not sure, but as I recall, the standard CDROM drivers treat
the CDROM like a hard disk).  There are patches to fix this in the
cdrom-0.2.tar.Z distribution, which is available on tsx-11.mit.edu.

        I would be interested in knowing if there are any problems after you
have installed those patches.

-Eric
--
Eric Youngdale
eric@tantalus.nrl.navy.mil

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Stabilizing Linux
Date: 14 Aug 92 23:00:15 GMT

In article <1992Aug14.132232.22899@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
|In article <1992Aug13.195406.23296@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
|| In article <1992Aug13.133313.15221@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
|| >In article <1992Aug12.173012.17552@colorado.edu>, drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
|| >
|| >And the person trying to install on a new machine can't rebuild the
|| >kernel, so s/he needs another working system to get going. Bleh.
|| >Relocation at load time might take 1-2 sec of cpu. Big deal. Without
|| >loadable device drivers you must have a working system to generate a new
|| >kernel.
|| 
|| Most Unices distribute the distribution kernel as a generic kernel,
|| ie one with support for all device drivers compiled in.  It gets a little
|| bloated, but if you can boot it, you can run anything.
|
|  Sounds to me like you think the Linux kernel as distributed contains
|all the devices anyone would ever want to use, so there's no need for
|being able to support new devices.

The assumption is that as new devices get added (such as Ross's 
ethernet drivers), that they will eventually make it into the 
distribution kernel, both in the sources and the generic binary.  

You can recompile (now), or relink (when a working config 
program is implemented) the kernel to add anything you need
before then - propriety GPIB driver, intelligent serial
driver, Ross's ethernet drivers, etc.

|  It also sounds like you're trying to say that you think it's too
|hard, and you personally don't need it, so you want to convince
|everyone it's a bad idea.

My opinion is that the percieved benefits (being able to add drivers at run 
time, saving a relink, rather than regenerating the kernel Makefile and 
relinking), are outweighed by the increased complexity 
of the device driver initialization, and memory allocation code.

- You add a new device driver, when one becomes available, or you
        install new hardware.  Neither is a frequent event. 

- Configuring a system, where you recompile ioconf.c or table.c, 
        and simply link in already compiled .o files for 
        everything else will take less than a minute on 
        anything that isn't thrashing - ie, a minimal 
        386 with ~4M of memory.  A reboot without fsck's 
        (ie, after a clean shutdown) about the same.

        So, you save two minutes everytime you add a new
        device driver.  I added a SCSI disk driver when I 
        finished the code, and will add a SLIP or CSLIP driver
        when one becomes stable.

        That's two drivers since last November.  

- Loadable device drivers let you shrink kernel size by leaving 
        out drivers you don't need.  You get the same effect 
        from a config program, only the kernel is even smaller because
        it doesn't need any of the hacks needed to accomodate 
        loadable drivers.  

I don't see any real benefits there.  

You can argue that loadable device drivers would make debugging 
easier for developers.  What's ideal for developers isn't necessarily 
ideal for users - ask any one who used the early, non-interrupt 
driven versions of the SCSI drivers.  They'll tell you about the 
wonderful interactive performance, and that the system would 
never hang for ~30 seconds while the disk(s) synced.  

When I did the SCSI code, I put in support for both interrupt, and 
non-interrupt driven SCSI drivers, thinking that "It would be 
much easier to debug the non-interrupt driven version."  It was
marginally easier, and all of the initial SCSI efforts ended up 
being of the non-interrupt driven variety that were the bane 
of SCSI users. It took us some time to debug the interrupt code (
one line needed moving in scsi.c), modify all of the 
lowlevel drivers, and get it back into the "stock" Linux distribution.

Interrupt driven SCSI drivers didn't make the stock distribution until
.97, and we've had SCSI versions since .12, support in the 
stock distribution since .95.

It's easier to do it right the first time, and avoid things of 
questionable value that may come back to haunt you.

I don't know that loadable device drivers would help that much 
during code development.  Much of the time is spent in design
and coding.  With device drivers, there are good chances of a 
bad device driver (ie wild pointer) corrupting the rest of the 
system.  Even if you can unload the driver, recompile, and load a 
new one, you may not want to, because something may have 
become corrupt in the rest of the system.  If you are booting 
from harddisk, the reboot-test cycle is not that bad.

I wouldn't say that loadable device drivers are "too hard" to implement - 
just that the added mess in the Linux code, and time it would take 
to do so aren't worth the benefits.

Linux is not a completely clean design.  Isolation between the 
various parts is not absolute.  Especially in the cases of 
pseudo-devices, like the lowlevel SCSI drivers, there is an
incestuous relationship between the driver code and the surrounding 
kernel.  The hard disk and SCSI drivers have special consideration 
given to them in ll_rw_block.c so they can get multi-block 
requests as one device driver request.  All of this would 
have to change, and in some cases, you may get nicer (but 
less tight) code.  

Like BSD, Linux uses certain "pseudo-devices."  These have 
a different interface than the normal block/character devices,
and will need special handling code.  Examples would include 
SYSV STREAMS, BSD network drivers, the Linux low level 
SCSI code.

Different parts of Linux are very dependant on eachother - for 
instance, some of the device drivers assume that kernel memory
is identity mapped.  malloc() preserves this assumption, but can 
only allocate 1 page at a time.  The same is true for get_page().

Current Linux devices have no way to "dettach" from the system,
necessary if you use loadable drivers for debugging, the only 
real reason you would want them. You need that, a way to track
what's mounted on block devices, etc.  

Current Linux code initializes all devices before the move to 
user mode, and most of it happens before buffercache, etc, is 
allocated.  (Well, sys_setup() is called from user mode, but that
just handles the partition tables on disk devices).  You'll need
to add all of the code to keep Linux happy when a new device 
is added.

It shouldn't be difficult, but I'd rather see people dedicate their
time to useful projects, like a SLIP driver for the TCP/IP package, 
a new VM using one page table per process to ease VM386 support,
remove the 64 process limit, increase the address space size, and 
support SYSV sghared memory semantics.  

Personally, I'll finish the SCSI driver rewrite (Experiments show that 
we can expect 3X current performance on unbuffered disks with 1K block file 
systems, 2 block read ahead, 12X if we move to 4K block sizes on the 
new file systems.  Buffered devices will see SOME improvement, I don';t
have one and can't say how much.) before playing with something useless.  






-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Diamond Speed Star SVGA card
Date: 14 Aug 92 23:18:19 GMT

In article <1992Aug14.171832.23483@usenet.ins.cwru.edu> mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
|
|
|
|
|anyone got this to work with X under Linux????

Yes.

|
|And also, is it true that the Diamond Stealth card won't work 'cuz
|it has that new S3 chip???

Yes.  There is currently no freely available S3 driver for X386.  However,
some of the Linux crew are working on one.  When available, it will probably
be folded into the X386 1.2 sources.  

The folks making the S3 are very friendly, and distribute accurate
doccumentation on their chips, for free.  Consequently, the S3 will be 
supported some time in the forseable future, x386 users will have 
an option for high speed graphics (I've seen X on a '486 running 
with the commercial S3 server.  VERY fast.  Very similiar to a 
fast RISC workstation, like an HP snake), S3 vendors will have 
a new market, and every body will win.

Colorado Memory Systems should take note of this - to the emerging 
free Unix market, and users of BSDI's product, many of their 
products are absolutely worthless, as they refuse to provide 
hardware documentation to anyone.


-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: X questions: how to run x-program on other machine?
Date: Fri, 14 Aug 1992 23:23:37 GMT

In article <zhao.713807106@unixg.ubc.ca> zhao@unixg.ubc.ca (Jiansheng Zhao) writes:
|Hi, there,
|I have X running, but still have some questions. 
|1). I couldn't run any x-program (xrn, etc) on our university's mainframe
|unix machine, which has all those wonderful x-program. There supposed to be
|a xhost or something, or setenv DISPLAY xxx.xxx.ca:0, which I cann't figure
|out. University Computing Centre cann't help much, they were suprised to
|know I am running X on a PC under L-I-N-U-X. Is it possible to dial-in and 
|run x-program from my linux-X machine?

Not yet.  To run the stock X server and clients, you need to have 
either a unix domain socket (local machine), or a TCP/IP socket
connection.  This means you need to have IP access to the 
net on which the host computer runs.

IP access may be attained through either a dirrect ethernet connection,
or via SLIP or CSLIP - Serial Line IP, or Compressed SLIP.  

In order to run SLIP, both ends must be support SLIP software.  Generally,
you need th sysadmin of the remote site to add you in so that they will 
route packets to you.

Another possibility is setting up a bogus X server on the remote
machine as some display other than :0, and coming up with a scheme 
for transmitting requests to your local clients through some propriety
scheme.  

Certain vendors do this.

You might look at xmx if you are interested.

|2). In which subdirectory should I unpack those X-program sources to
|compile? 

Normally, it doesn't matter, as long as you have xmkmf installed on 
your system.  Xmkmf will "do the right thing", setting up the 
include directories, etc, as defined in your X config directory.
-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 


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


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

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

    Internet: Linux-Activists@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
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************
Newsgroups: comp.os.linux