Subject: Linux-Development Digest #841
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:     Sat, 18 Jun 94 01:13:04 EDT

Linux-Development Digest #841, Volume #1         Sat, 18 Jun 94 01:13:04 EDT

Contents:
  Re: Linux serial programming (Johann Friedrich Heinrichmeyer)
  Re: What and where is mkimage? (Ron Smits)
  Re: Filesystem semantics protecting meta data ... and users data (Dirk-Jan Koopman)
  cp truncate some dos files, why? (Barry Yip kam-wa)
  Re: cp truncate some dos files, why? (Barry Yip kam-wa)
  Shortest development path to new architectures. Was (assembly language) (Daniel Veillard)
  Custom screen blankers (Aaron Hightower)
  Problem with VLB video cards (Igor Sharfmesser)
  Re: cp truncate some dos files, why? (Grant Edwards)
  NNTP packages on sunsite (Steve Brown)
  Re: Yggdrasil Linux with (Riku Saikkonen)
  Re: Disk-compression for Linux (Kevin B. Fluet)
  Re: Disk-compression for Linux (W.Pierce)
  Re: PLIP throughput.. (Bruce Evans)

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

From: jfh@ES-sun1.fernuni-hagen.de (Johann Friedrich Heinrichmeyer)
Subject: Re: Linux serial programming
Date: 17 Jun 1994 14:09:05 GMT

Jim Trocki (trockij@Cyanamid.COM) wrote:
:   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"?

i think there are complete solutions:

getty_ps or mgetty+sendfax


--
Fritz Heinrichmeyer                             FernUniversitaet Hagen
FAX:   +49 2371/5221                            LG Elektronische Schaltungen
EMAIL: fritz.heinrichmeyer@fernuni-hagen.de     Frauenstuhlweg 31
PHONE: +49 02371/566-243                        58644 Iserlohn (Germany)
WWW:  http://ES-sun2.fernuni-hagen.de



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

From: ron@draconia.hacktic.nl (Ron Smits)
Subject: Re: What and where is mkimage?
Date: 17 Jun 1994 17:51:14 GMT

mkimage is part of tools-2.11, this can be found on most FTP sites and
contains material and documentation about the builing of shared
libraries.
--



                Ron Smits
                ron@draconia.hacktic.nl
                Ron.Smits@Netherlands.NCR.COM

/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
/*-(                They might not be the same                        )-*/

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix,comp.arch.storage
From: djk@dirku.demon.co.uk (Dirk-Jan Koopman)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Fri, 17 Jun 1994 16:10:32 GMT

Totally Lost (idletime@netcom.com) wrote:
: [This was originally cross posted to comp.os.research, the moderator
: removed the other groups when he accepted the thread ... Please
: follow up to comp.os.research so we can move to a better forum for
: continuing this. Enjoy "The RAID 7 Disk Subsystem - band-aid and
: white elephant" thread ...JB]

[stuff deleted]

: I have a significant beef with the educational systems treatment
: of the "Computer Science" dicipline and how students are taught.
: This is the outcome of not only how my formal education progressed
: during the early 70's but how current graduates must be mentored
: to re-examine their teachings which they accept as the gospel
: according to Thomposon, Richie, and Joy - and the thousands of
: converted missionaries.

Here, here.

: This series was fun, and I think necessary to introduce the cold
: reality that things are far from perfect. I don't think a two line
: bug report would have served the purpose or opened up the degree of
: thinking and discussion necessary to have it sink in.

: Some of the Major topics to follow in this comp.os.research series are:

:       * How we got here today (partly covered in this thread)
:         and why that was acceptable then and not now.

:       * the evils of partition filesystem management, specifically
:         the performance and resource partitioning impacts (old data
:         presented to thousands in the past conferences, but lost)

:       * the evils of block at a time filesystem architecture
:         as formalized and standardized by the kernel filesystem
:         interfaces (old data again from both presentations
:         and postings in other groups).

:       * Locality problems and how they strangle disk performance.
:         A well structured arguement for radical architecture
:         changes. The problem goes past just filesystem design
:         as defined by UNIX implementation, and extends into
:         core kernel services, drivers, disk subsystems.
:         (old data again ... widely known, but not acted upon).

Interfaces such as SCSI which reinforce current thinking.

:       * Ignorance of physics and physical properties which
:         criple UNIX filesystem performance and reliability.
:         Sub topics include seek management, rotational latency
:         management, data scrubbing, integrated clustered
:         ecc with automatic recovery from multiple data block
:         failures. Data placement techniques for reliability.
:         (Old data presented in other conferences, training
:         seminars, and to clients).

SCSI again.

:       * Statistical caching, data replication, data migration
:         and fully transparent backup and recovery techniques.
:         Why mirroring, stripping and RAID in the current
:         designs are just flat wrong and stupid. Alternative
:         architecture presented which obsoletes these techniques
:         and greatly moves us forward. (old data not widely
:         presented elsewhere, primarily to my internal staff
:         and clients).

one of the few beefs I have with unix is all these techniques were known
about and/or in use before unix made out of Bell Labs - because of unix
they have all disappeared.

[stuff deleted]

: My detractors at SCO called the above the "Big Bang Theory"
: since I repeatedly said the base problem with UNIX filesystem
: performance was the initial design ... and that no significant
: improvement could be made without a near complete redesign
: which abandoned all the current interfaces and knowledge.

I would have said radical redesign, but one should be able to 
do a lot without having to throw quite everything away, especially 
a lot of programs would cease to run - and regardless of what you think
of the performance of the file system, an approach which significantly
altered the programming interface would probably not be acceptable.

However there are ways round that ofcourse, just because you don't have
an inode anymore doesn't mean that you can't LOOK as though you still 
have...

[stuff deleted] 

: requirements. I think the design and tradeoffs were brillant
: for 1974 ... and simply do not apply today.

I would have said 'suitable for the purpose', there were better designs
available even before then, eg George 3 (yes, I know it's British).

[stuff deleted]

Dirk

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

From: g609296@win.or.jp (Barry Yip kam-wa)
Subject: cp truncate some dos files, why?
Date: 17 Jun 94 03:18:01 GMT

It seems that cp and other commands too will truncate some dos files
such as msbackup.hlp (314236). When use cp to copy to another place, it
changes to msbackup.hlp (248). So there are holes in the file that cp
won't handle. Sorry if it sounds stupid as I am not a unix guru. Any
work around for this. Someone can enlighten me on this.

--
Barry Yip
g609296@win.or.jp

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

From: g609296@win.or.jp (Barry Yip kam-wa)
Subject: Re: cp truncate some dos files, why?
Date: 17 Jun 94 03:24:42 GMT

Barry Yip kam-wa (g609296@win.or.jp) wrote:
>It seems that cp and other commands too will truncate some dos files
>such as msbackup.hlp (314236). When use cp to copy to another place, it
>changes to msbackup.hlp (248). So there are holes in the file that cp
>won't handle. Sorry if it sounds stupid as I am not a unix guru. Any
>work around for this. Someone can enlighten me on this.

Me again :-)

OK it seems the fault is conv=auto fstab. So someone can tell me what's the
problem for this case.
--
Barry Yip
g609296@win.or.jp

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

From: veillard@imag.fr (Daniel Veillard)
Subject: Shortest development path to new architectures. Was (assembly language)
Date: 17 Jun 1994 14:41:56 GMT

In article <CrHz08.33@kerberos.demon.co.uk>, Anthony Lovell wrote:
 > Linus Torvalds (torvalds@cc.Helsinki.FI) wrote:
 > 
 > : Any porters out there should feel happier knowing that DEC is shipping
 > : me an AlphaPC that I intend to try getting linux running on: this will
 > : definitely help flush out some of the most flagrant unportable stuff. 
 > : The Alpha is much more different from the i386 than the 68k stuff is, so
 > : it's likely to get most of the stuff fixed. 
 > 
 > It's posts like this that almost convince us non-believers that there
 > really is a god.

  What does god think of porting Linux to Mach micro-kernel ? Maybe this
would be the shortest way to have linux running on Alpha, by the way
this would provide an easy path to the Power-Pc and 
the_next_new_hot_chip_you_want_to_run_Linux_on once Mach as been ported
to these new architecture. IMHO, Mach runs on Alpha, support SMP on i386
based machines, (it also exists for Suns and Decstation but requires a
source licence). I admit than on mono-processor i[34]86 the monolithic
Linux kernel will probably always feel faster than a Mach Linux server,
but Linux would gain a lot of portability, and lots of tedious developpment
could be avoided assuming the Mach Micro-kernel will be available soon
for the new chips we are looking for or already provides SMP.

   For people interested on port of Linux to Mach, please have a look
at the announce made by Louis-Dominique Dubeau last week on c.o.l.a.
Information are also available on a WWW server : 
     http://boole.info.polymtl.ca:1500/~hallu/
   
  thanks for your attention,

Daniel


-- 
Daniel Veillard :                | Bull-IMAG Systems  |
E-mail : Daniel.Veillard@imag.fr | Centre Equation    |
Tel : (33) 76 63 48 53           | 2 ave. de Vignates |
Fax : (33) 76 54 76 15           | 38610 GIERES FRANCE|


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

Subject: Custom screen blankers
From: aaron@qbert.dseg.ti.com (Aaron Hightower)
Date: Sun, 12 Jun 1994 14:45:30 GMT

I have a need to be able to write a custom screen blanker under linux.
I have found the code under /usr/src/linux/drivers/char/console.c that
controls screen blanking; what I would like to be able to do is to
have an application that is started anytime the screen blanks or gets
unblanked so that I can do something.

Thanks in advance for any help,
 Aaron Hightower (aaron@dseg.ti.com)

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

From: igor@mera.itpm.alma-ata.su (Igor Sharfmesser)
Subject: Problem with VLB video cards
Date: 17 Jun 1994 13:41:04 GMT

Hi!

I am running Linux 1.0.9 (Slackware distr) on a 60MHz Pentium based machine
with ISA and VESA Local Bus. After I've installed VLB video card based on S3
chip, my printer stops to work. When Linux boots printer is initializated
normally. But then, he isn't work: lpr don't print anything. Moreover, I
can't even put it in on-line mode. I've tried 2 VLB video card: S3 86C509
based and Cirrus Logic GD-5426 based, effect is the same. But when I install
ISA video card (Trident T9000) printer works perfectly. BTW all three cards
works in DOS well. Any suggestion?
                                  Igor


--
Igor Sharfmesser, postmaster of irbis.alma-ata.su
Internet: igor@irbis.alma-ata.su
FIDO:     2:5083/11.12



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

From: grante@reddwarf.rosemount.com (Grant Edwards)
Subject: Re: cp truncate some dos files, why?
Date: Fri, 17 Jun 1994 17:05:38 GMT

Romano Giannetti (romano@pimac2.iet.unipi.it) wrote:

  [file being truncated when cp'ed]

: > OK it seems the fault is conv=auto fstab. So someone can tell me what's the
: > problem for this case.

: ...is the 249th char an ascii 26? :-)

Because, you see, the early versions of CP/M (1.4 and 1.7?) didn't
store a file size as part of the directory structure, so you didn't
know where in the last block the data actually ended.

For ASCII files, a ctrl-Z was placed in the file as an EOF marker.

For binary files you just hand to know a priori where the last byte in
the last block was.  For executables you just pad the file out and
ignore the problem.

CP/M _may_ have inherited this problem from DEC RSX-11 as it inherited
some other things (you don't think 8.3 filenames, PIP, etc. were
coincidences, do you?).

Since PC-DOS (and MS-DOS) were "derived" from CP/M, and many of the
early PC-DOS applications were ports of CP/M applications, the
convention of using a ctrl-Z as an EOF marker persisted, even though
PC-DOS (at least in 2.0 and later) keeps track of how long files are
and will return EOF when you try to read past the last "real" data
byte in the last block.

That concludes the history lesson on why Gary Kildall is to blame for
your file getting truncated if there is a ctrl-Z in it.

--
Grant Edwards                                 |Yow!  Hmmm..  A hash-singer
Rosemount Inc.                                |and a cross-eyed guy were
                                              |SLEEPING on a deserted
grante@rosemount.com                          |island, when...

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

From: steve@unicorn.dungeon.com (Steve Brown)
Subject: NNTP packages on sunsite
Date: Thu, 16 Jun 1994 21:13:18 GMT

Hi folks,
   I have been trying to use nntp from sunsite and discovered that you could
not post articles upstream unless your upstream had specifically set you up
as a 'feed' ( ie not a regular end user ). But, if you are a feed then you
have use nntpxmit, not nntpxfer. Problem - nntpxmit uses the IHAVE command, 
which for my feed did not work, and in any case, I am not a feed, I am an
end user who wants to download a few groups at once for offline reading.
nntpxfer does that just fine, BUT, it wont post. So, to that end I have coded
a patch to nntpxfer which enables posting. If there is demand for it I will
happily upload it to sunsite or post the patch here. The code is ugly, but it
works :) ( This article has been posted using it ).

If you dont understand what I mean, but think you may have a need to post
news using nntpxfer then feel free to mail me for more details.

Steve.
-- 
==============================================================================
      Steve Brown         | Full Internet Access via | Act upon what matters,
     +44-473-640523       |  Dial-up. Good service!  |Not how you're perceived
steve@unicorn.dungeon.com |     info@dungeon.com     |    Deborah Gibson.

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

Subject: Re: Yggdrasil Linux with
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Fri, 17 Jun 94 20:01:00 +0200

>: i have seen here in a german store a Distribution of
>: Linux 1.1 from Yggdrasil named PLUG and PLAY LINUX !

A comment for you kernel hackers: I think it very strange to include
the 'alpha' version 1.1 in an official Linux distribution! Think of it -
many buyers of the CD don't necessarily have Internet access to get the
patches!

-=- Rjs -=- riku.saikkonen@compart.fi
GCS/O -d+ p c++(+++) l++ u e m++@ s/- n+ h-- f+ !g w+ t/Tolkien+++ r !y(*)
"`Yet sworn word may strenghten quaking heart', said Gimli.
 `Or break it,' said Elrond. `Look not too far ahead!'" - J.R.R. Tolkien

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

From: kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet)
Subject: Re: Disk-compression for Linux
Date: 17 Jun 1994 09:51:41 -0600

albayrak@cc.helsinki.fi writes:

>       I would like to discuss about on-fly disk compression. My
>       opinion is that implementing DoubleSpace(R) and Stacker(R)
>       -type compressing file-system is one of the most important
>       future enhancements needed for Linux.

I think  on-the-fly compression has been discussed by many people over the
last year, but nothing has come of it.  Basically, with hard drive prices
dropping dramatically every week (almost), it may not be worth the trouble. 
Prices are WELL under $1/MB these days.  Also, with the PROVEN unreliability
of compressed file systems, you would only have a few people willing to use
it.  

I must admit, though, that it would be nice to compress my news spool and
fit in another couple days of storage.  I'll never have enough news spool
space...  

-- Kevin

============================================================
Kevin Fluet                WorldGate Public Access Internet
fax: (403) 444-7720         kevin@worldgate.edmonton.ab.ca      
email info@worldgate.edmonton.ab.ca for rates and other info

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

From: pier1@rembrandt.its.rpi.edu (W.Pierce)
Subject: Re: Disk-compression for Linux
Date: 18 Jun 1994 01:53:10 GMT

In article <CrKAFI.2Hy@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>In <2tntbq$bom@kantti.Helsinki.FI> albayrak@cc.helsinki.fi writes:
>
>
>>      I would like to discuss about on-fly disk compression. My
>>      opinion is that implementing DoubleSpace(R) and Stacker(R)
>>      -type compressing file-system is one of the most important
>>      future enhancements needed for Linux.
>
>It already exists.  Check the "double" package.
>(I have no personal experience with it)


If you would like run-time/transparent decompression of compressed DATA
files, check out the zlibc package.

I use it myself-- it works beautifully.

It works on any filesystem transparently, quickly, and (IMO) efficiently.

Saves me megabytes.

(I don't want to start a thread on zlibc though, it has all been hashed
out before.)

-- 
[     Will      ] Linux/PGP/WWW/Objectivism/Atheism/Vegetarian/pink triangle
[    Pierce     ] Objectivism: http://www.rpi.edu/~pier1/phil/objectivism.html
[ pier1@rpi.edu ] TOOL Page:   http://www.rpi.edu/~pier1/music/music.html
[ Living  Free  ] S.N.:        http://www.rpi.edu/~pier1/

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

From: bde@kralizec.zeta.org.au (Bruce Evans)
Subject: Re: PLIP throughput..
Date: 18 Jun 1994 05:35:14 +1000

In article <CrHpFo.1w1@cs.vu.nl>, John Romein <john@cs.vu.nl> wrote:
>genie@sting.Berkeley.EDU (Gene Choi) writes:

>: 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,

Well, it's better.  A 386/20 can handle 9 or 10K/sec SLIP thrroughput.

>: If I remember correctly, using LapLink, some people were copying
>: things over the parallel port at least 50-100kbytes/sec,  Sure

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

No, it's very i/o intensive.  PLIP takes a minimum of about 15 i/o
instructions per byte.  This takes about 20 usec on most systems with
an 8 MHz ISA bus, so it's hard to get more than 50K/sec throughput.
386's are reasonably fast at shifting and even a 386/20 can reassemble
a byte in about 1 usec, at least if everything is kept in registers.
-- 
Bruce Evans  bde@kralizec.zeta.org.au

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


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