Subject: Linux-Development Digest #812
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:     Fri, 10 Jun 94 07:13:08 EDT

Linux-Development Digest #812, Volume #1         Fri, 10 Jun 94 07:13:08 EDT

Contents:
  Re: My problem? GCC problem? Linux problem? (Wayne Throop)
  Re: Filesystem semantics protecting meta data ... and users data (Kevin Brown)
  Re: port access function definition? (Drew Eckhardt)
  Re: 1.n vs 1.n+1 (was: Let's rename v1.0.9!) (Dennis Flaherty)
  gdb on running kernel? (Craig Metz)
  struct hostent *h; h->h_addr to 0.0.0.0 (Simon Johnston)
  Wanted : Mail (siu yan kam)
  Help needed with a project using Linux and SB (w/details) (BRIAN KEITH PIPA)
  Re: SMP supprot for Linux???? (Alan Cox)
  Re: v.35 (56kb -> T1) driver development (Alan Cox)
  Re: New kernels and # of lines on screen (Kurt Klingbeil)

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

From: throopw%sheol@concert.net (Wayne Throop)
Subject: Re: My problem? GCC problem? Linux problem?
Date: 9 Jun 1994 20:01:26 GMT

::     void main() { example("Hello!"); }

It probably doesn't cause your sigsegv on linux,
but it may be worth noting that defining main to return void
is illegal in C, and always has been.  Borrowing from the
comp.lang.c FAQ:

5.12:   Can I declare main as void, to shut off these annoying "main
        returns no value" messages?  (I'm calling exit(), so main
        doesn't return.)

A:      No.  main must be declared as returning an int, and as taking
        either zero or two arguments (of the appropriate type).  If
        you're calling exit() but still getting warnings, you'll have to
        insert a redundant return statement (or use some kind of
        "notreached" directive, if available).

        Declaring a function as void does not merely silence warnings;
        it may also result in a different function call/return sequence,
        incompatible with what the caller (in main's case, the C run-
        time startup code) expects.

        References: ANSI Sec. 2.1.2.2.1 pp. 7-8.

--
Wayne Throop   throopw%sheol@concert.net
               throop@aur.alcatel.com

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Wed, 8 Jun 1994 19:40:18 GMT

I'm not even close to an expert on filesystems, so take what I say
with a grain of salt.  These are just my own thoughts on the
subject...

In article <idletimeCqzHAL.I59@netcom.com>,
Totally Lost <idletime@netcom.com> wrote:
>In article <1994Jun6.073403.4235@wavehh.hanse.de>,
>Martin Cracauer <cracauer@wavehh.hanse.de> wrote:
>>SunOS-4.1.3 has a policy to have asynchronous writes for data, but
>>inodes and other superinformation is always written immedeatly. So, a
>>crash could only affect files that a written at that moment. I think
>>Solairs 2 does this, too. Does anybody know?
>>
>>There was a patch for SunOS 4.1.3 to make the BSD-Filesystem writing
>>inodes async, too. That speeds up writing a large number of little
>>files by a factor of 2 to 3. Of course, a crash could really hurt now
>>that superinformation could be damaged.
>
>Both of these policies are stupidly wrong from a security stand point,
>which is a significant case requiring orderly filesystem updates.
>Actually both are wrong form ANY stand point, except to stupid sysadmins
>and shit head systems programmers that don't give a damn about users data.

The suggestions that you have will help, but they're not quite good
enough, particularly on a complex system.  Ultimately, there is no
substitute for a good system administrator.

>Take the case where a sensitive file {passwd, payroll data, next weeks
>final exam} is is copied/compressed/crypted and the original deleted.
>These same blocks are allocated to a new file, the idnodes and directory
>information are written before the new data for the same blocks, the machine
>crashes at just the right time {hostle user is watching the jobs run with hand
>on power swtich} leaving the sensitive data in the hostile users file and
>fsck will be stupidly happy on the crash recovery reboot.

Your point is well taken, but if the hostile user is at the power switch,
then I'd suggest you have significantly worse security problems then the
one you present above.

>I've raised this point a dozen times, even at the usenix meeting where the
>Berkeley guys first presented their concept of sync written meta data ...
>and they didn't have a clue since they were one-tracked on making the
>system clean from fsck point of view ... not from the users or data base
>managers point of view. If the users/production data is corrupt, the
>filesystem is corrupt!! PERIOD!!

True.  However, in that particular case the damage is likely much more
localized.  The system administrator may have to restore some files from
backup, but much less than restoring the entire filesystem.

It's a tradeoff...

>I'd much rather have a totally unsafe filesystem that trashed on crash
>and required a known good backup recovery over one that is guarenteed
>to do the wrong thing and have dumb sysadmins think that just because fsck
>ran fine all users/production data was fine too.

You ultimately can't compensate for stupid system administrators.  While
more orderly filesystem updates will help, the *real* solution is to get
a good system administrator.

>There are only two acceptable strategies:
>
>       1) require that all data be written prior to the referencing
>          meta data. File data blocks first, followed by Nth level
>          indirect blocks, ...., 1st level indirect blocks, inode.

This makes sense as long as you don't care too much about file data
integrity.  You mention a possible solution to this problem (write
new data blocks), but that has its own set of problems (e.g., low-
space situations).

Of course, writing the metadata first will yield even worse results...

>          If a file is open for writing, and written other than at
>          EOF, the disk inode is updated with a a dirty flag, which
>          is cleared when the file is closed or specifically "sync'ed".

Suppose a file is marked as "dirty", the system crashes, and the
operator has to bring the system back up.  When it comes up, the
file is still "dirty", but what is the operator to do about it?
Restore it from backup?  This is not at all a proper solution if
the "dirty" file is part of a multi-file database.  Restoring the
file from backup while not restoring the other (presumably clean)
files will yield an inconsitent database.

Situations like this simply underscore the fact that there is no
substitute for a system administrator that knows what he's doing
(and knows what his users are doing.  The file above may be part
of a user's *personal* database, rather than a systemwide one).

>          All filesystem file data and meta data will be clean at any
>          interruption of service, with the detectable exception that
>          a file/database may be internally inconsistant.

This cannot be guaranteed, particularly if the interruption occurs
in the middle of a write operation to the middle of a file.
Requiring that new blocks be written will help enormously here,
though.

>       2) any other write policy requires a filesystem to be reload
>          from backup media if service is interrupted while mounted.

This may well be required anyway, even *with* the ideas you suggest.

>Item one can be extended to require updates to existing filedata be done with
>new data blocks, and new meta data, which only is reflected to the
>disk inode when the file is closed or a commit operation performed.

Yup.  But this can be a really significant problem in low-space
situations, particularly if the files being updated are large.

>When done properly with locking operations this makes a system database
>safe as well.

Certainly safer than with existing filesystem policies.

>This policy is neither difficult to implement, nor a significant performance
>hit ... and in fact when done with better algorithms than UFS can be
>3-10X faster.

Do you have any references in the literature to performance analyses
of such schemes?  I don't imagine the performance hit would be that
significant, because the only effect I can see off the top of my
head is the queueing of data in the various passes of the elevator
algorithm...

You'd have to get rid of the idea of a simple buffer cache, though
(would a cache with priority levels be sufficient?).


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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: port access function definition?
Date: 9 Jun 1994 20:59:11 GMT

In article <KWH.94Jun9160427@monaco.cs.brown.edu>,
Kwun Han <kwh@cs.brown.edu> wrote:
>Hi,
>
>       I am trying to interface to a card which need to use word
>io. I saw #define of outw, etc in asm/io.h, however, I have looked
>through then entire kernel source and have not found __outwc_p or any
>other similar definitions. I get undefined errors when compiling the
>kernel. I wonder if any god like person can tell me where they are or
>what I need to do.
>

1.  You need to #include <asm/io.h> in your driver source

2.  You _must_ have optomization enabled when your driver source
    is compiled (the default CFLAGS do this if you start make 
    at the top level of the kernel source tree, starting the build
    else where, or providing an explicit rule which doesn't use 
    CFLAGS will break this), because of how GCC handles the extern inline
    definitions - if optomization is turned off, the inline definition
    is treated as an external declaration and no code is generated.

    Alternatively, 

    #define extern
    #include <asm/io.h>
    #undef extern

    also works - although the calls aren't inlined, code is generated
    and the correct calls made.


-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: dennisf@denix.elk.miles.com (Dennis Flaherty)
Subject: Re: 1.n vs 1.n+1 (was: Let's rename v1.0.9!)
Date: Mon, 6 Jun 1994 04:06:58 GMT

In article <CqwuFq.Ivv@eecs.nwu.edu>, H. Peter Anvin <hpa@nwu.edu> wrote:
> Followup to:  <2sr86s$9v9@charm.magnus.acs.ohio-state.edu>
> By author:    ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
> In newsgroup: comp.os.linux.development
> >
> > Suggestion: How about attaching a letter or a word in front of these
> > different versions?  For the Linux-Sabre (bleeding edge) versions
> > use "a" or "alpha" (e.g. 1.1.18a or 1.1.18alpha), and for the
> > stable (but, not completely stable (the difference between 1.0.0
> > ["completely stable"] and 1.0.9 ["mostly stable"]) attach a "b"
> > or "beta" on the version number.  For example, how about 1.0.9b or
> > 1.0.9beta?

Because it doesn't matter how the two development trees are labeled;
there will always be people who will grab the latest and greatest, get
burned, and flame about it on the net.  We need two trees, just so that
at least we can *tell* people what version to grab if they honestly want
a stable version.

> > Another thing: I have read somethings that disturb me. Some of
> > the messages in this thread imply that 1.0.* and 1.1.* is being
> > developed/fixed/updated in tandom.  Is this true?
> 
> Not really.  However, some *bug fixes* has been applied to the 1.0.x
> branch, bringing it up to 1.0.9 by now (1.0.9 is hence *more* stable
> than 1.0.0, at least theoretically).  

And thus, Peter, the two trees are being developed in tandem.

> 1.1.x is the development branch;
> at some point a feature-freeze will be applied to this branch (similar
> to the 0.99.x feature freeze), bringing about a 1.2.x mainstream and a
> 1.3.x development branch.

IMHO this would be an unfortunate choice.  I think what we generally
want to avoid is any suggestion that some minor patch level is "final".
I like the idea of allowing the 1.0.x tree continue for bugfixes.

Yet, any minor version number can be patched out for stability if
there's a newer version for hackers to develop new ideas.  To do this,
if a version m.n.p of a system has implemented all desired new features,
it can be copied to m.n+1.0, and m.n.p+1 can be patched out for
stability.  As soon as m.n+1.q has all new features implemented, it can
be copied to m.n+2.0 and then m.n+1.q+1 can be left for bugfixes.

I'd like to see version 1.1.18 copied to 1.2.0, so that all new features
would be applied to this new 1.2.0, and 1.1.19 and so on would be only
bugfixes.  Any past minor version, even 1.0.9, can get a bugfix if
necessary at any time.  That kind of version numbering scheme best
matches reality, always giving a new hacker's version and reserving
noted old versions for stability patches.

-- 
Dennis T. Flaherty              Home: dennisf@denix.elk.miles.com
Flaherty Nanobreweries          Work: dennisf@se01.elk.miles.com
     Oatmeal Stout: It's the Right Thing to Drink!

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

From: cmetz@thor.tjhsst.edu (Craig Metz)
Subject: gdb on running kernel?
Date: 8 Jun 1994 19:27:03 -0400

        Once upon a time, I was under the impression that, with obvious
restrictions, it was possible to use gdb on the Linux kernel while it was
running to look at things. Is this true? If so, how does one get gdb to do
it?

                                                                        -Craig

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

From: skj@oasis.icl.co.uk (Simon Johnston)
Subject: struct hostent *h; h->h_addr to 0.0.0.0
Date: Fri, 10 Jun 1994 08:05:36 GMT

How do I convert the 'thing' pointed to by the h_addr member of a 
struct hostent into a dot seperated IP address, the actual definition
of the h_addr member is a char *, though I dont believe it is a
C string ;-) Any ideas? 


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer              |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk      |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476084|United Kingdom     |
|Internal  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.

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

From: yksiu2@ie.cuhk.hk (siu yan kam)
Subject: Wanted : Mail
Date: Fri, 10 Jun 1994 08:56:14 GMT

I am looking for the source code of the mailing system on Linux.
Please give me some suggestions on how I can find it.
Thx a lot.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Email : yksiu2@ie.cuhk.hk

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


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

From: bkpipa@eos.ncsu.edu (BRIAN KEITH PIPA)
Subject: Help needed with a project using Linux and SB (w/details)
Date: 10 Jun 1994 06:48:58 GMT


I am doing a computer project with Linux and the Soundblaster.
I'm trying to find some information on networking. I want
to be able to send (in real-time) a voice from one computer with a SB 
to another (with a SB) via a network. Our host computer is hooked up 
to the Internet, so the others are on the net via the host. I need 
to have one computer talk (literally) to another.

I desperately need some help with the networking part. Is there an FAQ
or some on-line text I should see (or maybe some example source code
I can look at - in C preferably)? ANY help would be greatly appreciated.
I don't want someone to do the work for me, I just need to know where
to look to find the info I need.

Thanks!
Brian


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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: SMP supprot for Linux????
Date: Fri, 10 Jun 1994 09:33:55 GMT

In article <2t8f95$3hp@charm.magnus.acs.ohio-state.edu> ewalton@magnus.acs.ohio-state.edu (Elaine Walton) writes:
>At present, there has been a lot of talk on the subject--not much done.
>The problem stems from the sheer problem of a highly-coupled MPU (multi-
>processor unit).  Some have suggested porting Linux over to the Transputer
>processors to take advantage of it loosely coupled arrays.  For the most
>part, a MPU would require restructuring the OS and the compilers (unless
>you can manage the critical sectioning yourself--not an easy task;).

With tightly coupled SMP its not so bad. Its very easy to right a 
pessmistic solution that works and refine it later. The initial one many
unixes used for MP was a processor that ran the kernel and syscalls on the
other cpu trapped the process and rescheduled it as a software interrupt
on the 'kernel' CPU. Thats _overly_ pessimistic but gives the idea. 

Alan



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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: v.35 (56kb -> T1) driver development
Date: Fri, 10 Jun 1994 09:35:32 GMT

In article <2t7d1b$och@magus.cs.utah.edu> kruckenb@sal.cs.utah.edu (Joseph Kruckenberg) writes:
>I (finally) found a v.35 interface card for the PC from a company
>called SDL. They have both single and dual-port cards that support up
>to T1 bit rates. Unfortunately, they only have SCO, UnixWare, and BSDI
>drivers for it. I spoke to one of the developers, and they are very
>interested in having a Linux device driver. My company is interested
>in having a v.35 board for our Linux box, and they will let me develop
>it on company time!
>
I'm happy to help give you hints with it. Presumably you are looking at using
the v35 board as a network interface not a synchronous terminal driver ?

Alan


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

From: kurtk@ee.ualberta.ca (Kurt Klingbeil)
Subject: Re: New kernels and # of lines on screen
Date: 10 Jun 1994 07:00:10 GMT

chapmra@u.washington.edu (Randy Chapman) writes:

>OK, I guess I wasn't totally clear on this.  I was driving my video card 
>at 80x50 and everything there worked just peachy.  Then I tried to use my 
>Ampex A-210 (serial 80x24 dumb terminal).  And the system thought it also 
>had 50 lines :(

>However, jumping from 1.1.16 to 1.1.18 fixed the whole problem :)

>Good work, guys!  And thanks for such a WONDERFUL product!

>Randy Chapman

>In article <2st1rn$oji@news.u.washington.edu>,
>Randy Chapman <chapmra@u.washington.edu> wrote:
>>When I upgraded my kernel from 1.0.0 to 1.1.16, my computer suddenly 
>>started thinking my 24-line terminal had 50 lines.  It used to work fine 
>>and I don't think I changed any other relevant code.  Backing back down 
>>to 1.0.0 fixed the problem, but I need the more current kernels for RARP..
>>
>>Does anybody have a suggestion?
>>
>>Thanks,
>>Randy Chapman
>>chapmra@u.washington.edu

I've experienced the same problem (using csh) and recently posted about it
seeking some advice...

Both bash and csh come up with lines and cols set according to
the video mode of the console, even if one is coming in on ttySn.

For bash, one can just export LINES=24; export COLS=80.
Actually, I'm just working on hacking up the /etc/profile to
incorporate ttySn-dependancy to override the "auto-smart-ness".

For tcsh, however, things aren't so easy since term type seems to
be defined even before /etc/csh.login is hit.  The lines/cols
are implicitly set to the console's video mode, but if one
attempts to explicitly setenv LINES/COLS, the "autotracking"
which is related to SIGWINCH (which probably wasn't implemented in 1.0.0 ?)
stomps them back into the wrong values.

Then there's "vim" which appears to ignore both TERMCAP and LINES
and config itself according to the console mode even when run on ttySn.

Looking for a definitive fix...
kk



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


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