lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest150
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

785 lines
29 KiB
Plaintext
Raw Blame History

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, 10 Sep 94 15:13:10 EDT
Subject: Linux-Development Digest #150
Linux-Development Digest #150, Volume #2 Sat, 10 Sep 94 15:13:10 EDT
Contents:
Linux Micro-Kernel? (ian_vogt@ACM.ORG)
Re: News Spool File System - new filesystem type?? (Tom Limoncelli)
queue_glue: no memory for gluing queue in 1.1.50 (Andy Burgess)
GoldStar VLB IDE controller (Tal Yuval)
Re: Alpha Linux (Johan Myreen)
Re: News Spool File System - new filesystem type?? (Michael Dillon)
Is there Usage Accounting Utilities??? (Tony Schwartz)
Re: How to use diff (Uwe Bonnes)
Re: DOSEMU 0.53p17 & mouse (Uwe Bonnes)
Looking for Donald Becker (Erann Gat)
Re: Non-ANSI constructs in the kernel (was Re: Unicode...) (Richard L. Goerwitz)
Re: IP encapsulated in IPX can linux extract IP (Rob Janssen)
Re: NFSD debug logging error (Rob Janssen)
Re: Why I cannot mount a PhotoCD on Mitsumi ? (Doug McIntyre)
Re: 320x200 X resolution? (Christopher M. May)
Reporting bugs (was ip forwarding/gatewaying with kernel 1.1.18 problems) (Stephen Harris)
----------------------------------------------------------------------------
From: ian_vogt@ACM.ORG
Subject: Linux Micro-Kernel?
Date: 9 Sep 1994 19:04:09 GMT
Reply-To: ian_vogt@ACM.ORG
On a list of context switch times for different operating systems
I noticed that Linux is not too different (only 2.5 times slower)
from QNX - a micro-kernel O/S.
Does Linux use a micro-kernel?
If not, does it use any mico-kernel-type techniques?
Is there any plan to make Linux more like a micro-kernel?
Any thoughts appreciated, Ian.
------------------------------
From: tal@plts.org (Tom Limoncelli)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 10 Sep 1994 10:00:37 -0400
In <34polp$9p9@usenety1.news.prodigy.com> davidsen@elephant.dev.prodigy.com (Bill Davidsen) writes:
>b) why write a complete news system?
> Because doing a general compressed filesystem type is not my
> interest, and doing the article part and waiting for someone
> to put in in a news system would be a waste of time and would
> make debugging really ugly.
Nothing you are doing would prevent you from using INN as your
base. I'm just trying to encourage you to not reinvent the wheel.
>c) why restrict reading to NNTP?
> Because the filesystem type is going to change and I don't want to
> rewrite readers which go directly to /usr/spool/news.
I agree!
>I didn't know INN had the ability to use compressed filesystems, I don't see
>the compressor code, or is that a feature in 1.5? Or do you mean it could be
>hacked into INN by rewriting some stuff? That's true of any news system if you
>have the source.
I mean it could be hacked in with minimal changes. There is exactly
one place in the code where an article is written to disk. There
is exactly one place in the code where an article is read from the
disk. etc. etc.
--tal
--
Tom Limoncelli -- tal@plts.org (home) -- tal@big.att.com (work)
Write to me for info about internet mailing lists on these topics:
Drew University Alumni/ae, IXO/tpage users, New Jersey Unix Sysadmins' Group
(like SAGE), New Jersey motss, North East motss, BiNet/New Jersey, and more!
------------------------------
From: aab@loach.cichlid.com (Andy Burgess)
Subject: queue_glue: no memory for gluing queue in 1.1.50
Date: 9 Sep 1994 12:07:56 -0700
In 1.1.4x and in 1.1.50 under heavy load (make -j 3 with the source
files on an NFS mounted SunOS 4.1.3 disk) I get:
Couldn't get a free page.....
IP: queue_glue: no memory for gluing queue 0x113D158
Couldn't get a free page.....
Couldn't get a free page.....
Couldn't get a free page.....
IP: queue_glue: no memory for gluing queue 0xD0D158
IP: queue_glue: no memory for gluing queue 0xA819D8
IP: queue_glue: no memory for gluing queue 0x625298
IP: queue_glue: no memory for gluing queue 0xA819D8
Couldn't get a free page.....
NFS server cichlid not responding, still trying
NFS server cichlid OK
Utilities are Slackware 1.2. 20Mb RAM and 32Mb swap. INN is also running
but not doing anything via NFS.
Can anyone help?
Thanks
Andy
--
Andrew A. Burgess aab@cichlid.com
Free newsfeeds and SLIP, Santa Cruz CA area, mail info@cichlid.com
------------------------------
Subject: GoldStar VLB IDE controller
From: yuvalt@black.weizmann.ac.il (Tal Yuval)
Date: Sat, 10 Sep 1994 15:18:39 GMT
I have a GoldStar VLB IDE controller. Linux seems to work fine with it.
However, along with the controller I got a diskette with device drivers which
seem to boost things. Did someone hack the kernel to use GoldStar's
functions?
Thanks,
-Yuval
--
Yuval Tal, System programmer // Faculty of mathematics
yuvalt@wisdom.weizmann.ac.il // Weizmann Institute Of Science, Rehovot, Israel
------------------------------
From: jem@snakemail.hut.fi (Johan Myreen)
Subject: Re: Alpha Linux
Date: 10 Sep 1994 16:28:07 GMT
In article <Cvt37v.1EB@dumain.demon.co.uk> wish@dumain.demon.co.uk (Bill Hay) writes:
>Because an int should be the natural wordsize of the processor and should
>therefore be 64 bits.
How do you define the "natural wordsize" nowadays? The size of the
internal registers? The width of the data bus to the RAM? The width
of the bus to the cache?
What is the natural word size of the 68000? Or the 8088? Or a
hypothetical processor with 32 bit registers and a 32 bit external
data path, but with no 32x32 multiplication instruction?
--
Johan Myreen
jem@vipunen.hut.fi
60 11' 55" N, 24 53' 30" E
------------------------------
From: mpdillon@halcyon.com (Michael Dillon)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: Sat, 10 Sep 1994 00:38:24 +0100
> 1) eliminate/minimize directory traversal for article access
> (opens?).
If a program issues an open for comp/os/linux/development/22334 the file
system is free to use an implementation that does not involve the
normal UNIX directory tree traversal.
> 2) combine history and NOV type functionality, and move it out of
> the filesystem (maybe into the database). Think of how databases
> work. We have redundant "indexes" with the current scheme. (the
> current scheme works well, mind you, but I think a paradigm
> shift is needed to make much more inprovement. Something other
> than newer dbz's)
Since history databases merely record the existence of a message with
a given message id and NOV merely gives quick access to headers,
a more efficient news file system should be able to provide that
stuff directly from the message headers and still give good performance.
Of course, you could keep on using the old history and NOV
files too if you wanted to.
> 8) Not use proprietary DB's. IE: free (This may be tough)
> (Could someone write a portable, decent performance, SQL DB
> and post it?) :-)
I think that if you want performance, you need to forget SQL and
work at the lower level of data and index similar to dBase files.
> Hmm, I was the one concerned about a DB type approach, but I see a DB
> as the best chance of doing the above. I feel sure that an approach like
> this is doable with even commercial SQL technology.
Ugghh! I hate SQL. But the idea of building an INN that uses a
well defined database API to access news and control files
makes a lot of sense. Then people can graft on whatever database
they like. I've even heard of a company that is using an Oracle
database instead of /etc/passwd.
cruisin' down the information highway, lookin' for a blast
breakin' all the speed limits as I come zoomin' past!
--
Michael Dillon Internet: mpdillon@halcyon.halcyon.com
C-4 Powerhouse Fidonet: 1:353/350
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
Canada BBS: +1-604-546-2705
------------------------------
From: tony@teleport.com (Tony Schwartz)
Subject: Is there Usage Accounting Utilities???
Date: Sat, 10 Sep 1994 00:17:07
Does anyone know of any built in or add-on accounting functions that will
allow the Linux system to record who is on, when, how long, etc?? I need this
as a new Access provider and dont really want to create it myself.
Ideas are appreciated.
Tony Schwartz
------------------------------
From: bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes)
Subject: Re: How to use diff
Date: Sat, 10 Sep 1994 15:04:06 GMT
Tracy R. Reed (treed@ucssun1.sdsu.edu) wrote:
> I need to know how to use diff to make a patch. I manually applied the
> 1.1.18 accounting patch to 1.1.49 because the diffs didn't work out quite
> right. I would now like to make a new diff so I don't have to do it by
> hand again. I saved the old kernel in /usr/src/linux-old and the new
> kernel is in /usr/src/linux. Can someone give me the diff command to
> compare these to directories and make a patch? My installation doesn't
> have a manual page for diff for some reason. I'll make the patch
> available to anyone who wants it.
diff -ruw (old-directory) (new-directory) >(patchfile).
If you added new file in (new-directory) , add --new-file to the
arguments. You can get a short help with "diff -h"
Hope this helps
--
Uwe Bonnes bon@lte.e-technik.uni-erlangen.de
------------------------------
From: bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes)
Subject: Re: DOSEMU 0.53p17 & mouse
Date: Thu, 8 Sep 1994 20:32:38 GMT
Francesco Defilippo (clint@hal9000.unipv.it) wrote:
> Hi, when i exit from dosemu selection doesn't work,
> I'v linux 1.1.49 & dosemu 053p17
With dos -X, linux 1.1.49,dosemu 053p18 and MSCMOUSE 7.01,
I have no problem exiting
--
Uwe Bonnes bon@lte.e-technik.uni-erlangen.de
------------------------------
From: gat@robotics.jpl.nasa.gov (Erann Gat)
Subject: Looking for Donald Becker
Date: Thu, 08 Sep 1994 14:12:21 -0800
Does anyone know what happened to Donald Becker? He is the author of
many of the Linux network device drivers. He is apparently no longer
at super.org.
Thanks,
E.
--
Erann Gat
gat@robotics.jpl.nasa.gov
------------------------------
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Subject: Re: Non-ANSI constructs in the kernel (was Re: Unicode...)
Reply-To: goer@midway.uchicago.edu
Date: Thu, 8 Sep 1994 21:03:35 GMT
Harald T. Alvestrand writes, regarding apparent non-localizable parts
of the HPFS code:
>The HPFS code is admissible if HPFS has its own builtin assumptions
>about what character sets stuff is stored in. Indeed, it would *have*
>to be coded that way if the HPFS charset was in any way different from
>the one Linux is "natively" using.
I guess the issue is this. If you expect to find 97 in an 8-bit pack-
age, you don't want to designate this via 'a'. Again, this all depends
on whether the kernel will ever set its locale to anything implying a
non-ISO 8859-1 charset. If the kernel will always be compiled with the
same charset, we're fine. Is this a valid assumption, however?
>The toupper() and tolower() macros are IMHO broken.
The trouble is that the kernel can't just access the C library. Is it
worth including separate utilities that are essentially equivalent to
the C library routines? I don't know. I can see how the answer might
be "no" now, but "yes" later. As long as hackers who go into the code
know that the toupper/tolower (and many other sections of the kernel)
are not internationalized, and can locate these readily, it would seem
fine to leave them in as they are.
Too bad Linus is in Australia; I'd really like to know what he says
about all of this.
--
-Richard L. Goerwitz goer%midway@uchicago.bitnet
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: IP encapsulated in IPX can linux extract IP
Reply-To: pe1chl@rabo.nl
Date: Sat, 10 Sep 1994 13:12:48 GMT
In <1994Sep10.011707.17006@news.etc.bc.ca> nwalker@cln.etc.bc.ca (Norm Walker) writes:
>I have been setting up a linux machine to act as an internet host
>on a novell network and got ip and tcp up sharing the ethernet
>now we have several segments on different hardware that we
>would also like to have access to the linux box.
>the problem is that the packets reach the novell server
>and it does not know that they are for the linux box on the other
>network card so it tosses it.
Then you just need to setup IP routing on your Novell server.
It is described in the red books. It is like:
load tcpip
bind ip to card addr=a.b.c.d gateway=e.f.g.h mask=mm.nn.oo.pp
do this for all cards you want to run IP on, and the server will route
the packets.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: NFSD debug logging error
Reply-To: pe1chl@rabo.nl
Date: Sat, 10 Sep 1994 13:16:59 GMT
In <34rt5s$2vk@mustang.sdc.com.au> "Stephen Davies" <scldad@sdc.com.au> writes:
>I am trying to debug a problem with a PC-based NFS client to NFSD on
>Linux and have noticed that the output from log_call in logging.c does
>not appear in /var/log as expected.
>At line 136 of logging.c is the following:
>dprintf(1, "%s]\n\t%s\n", buff, arg);
>The output in my log includes the contents of buff but not of arg;
>which, of course, is what I wish to see.
>I have searched the code but am blind to the reason for this.
I think it is because of the \n in the middle of the format string...
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: merlyn@icicle.winternet.com (Doug McIntyre)
Crossposted-To: comp.os.linux.help
Subject: Re: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 10 Sep 94 16:48:09 GMT
jakmouw@et.tudelft.nl (Erik Mouw) writes:
>I think the errormessage says enough: photo CD's don't have a
>ISO 9660 filesystem on it, otherwise Linux should have mounted it.
>ISO 9660 filesystems is only for CD-ROM, another CD substandard.
>I don't know how to read from a photo CD under Linux, under MS-DOG with
>Windows you van use Corel Draw!...
Sure, PhotoCDs are in ISO9660 format. You may have to put the drive into
a special mode though to read the CD-ROM/XA standard that photo-CDs are
written in (blocks have some extra bytes), to make the CD-ROM appear
to be in the standard block format. I have no clue what that would
be on the mitsumi. I have programs to do that for Toshiba drives.
Then I can just mount them with the iso9660 file system..
--
Doug McIntyre merlyn@winternet.com
Write to info@winternet.com for more information about Winternet's
Internet services and dialups.
------------------------------
From: cmay@titan.ucs.umass.edu (Christopher M. May)
Crossposted-To: comp.os.linux.misc
Subject: Re: 320x200 X resolution?
Date: 10 Sep 1994 17:58:42 GMT
CLAYTON MICHAEL O'NEILL (cs339014@bit.com) wrote:
: Christopher Wiles (a0017097@wsuaix.csc.wsu.edu) wrote:
: : Seriously, IMHO Doom will probably be more useable in the promised
: : pixel-doubling mode than in a straight 320x200. Easier to make things
: : look innocent when the boss walks in ... "Hey, you're not actually
: : _working_ in 320x200, are you?"
Benjamin Alman (alman@myhost.subdomain.domain) wrote:
: Does anyone know how to get a 320x200 or similar resolution in XFree386
: 2.1.1 ??? I have an ATI GUP video card, and a CTX CPS-1560 monitor...
A while ago, some kind soul posted a C program which automatically
calculates modeDB entries based on dot-clock frequency and
horizontal sync frequency.
I cannot take any credit for this program, which is based on
information from the Videomodes.doc provided with XFree.
I also cannot take any credit (or be held responsible)
if use of this program causes damage to your equipment.
Use at your own risk. (*sigh*).
It did, however, allow me to find a 320x240 video mode I can
use to play DOOM on my SONY CPD-1304 *Multiscan* monitor.
After you cut the source from this article, and compile
it, you can get a 320x240 mode with:
xmode -dcf 12 -hsf 29.5
refresh rate for this mode: 28.26Hz
percent of hfl used: 75.37%
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
320x240 12 320 352 392 424 240 243 247 252
I had to add some values to the vertical timing to correct
some weird linearity problem on my monitor (top horiz lines spaced wider...)
Of course this refresh rate is really low, (although it looks fine to me )
I was able to sync to higher rates, but the size was off, so I just
dropped the dot clock, until I had a mode I didn't have to manually
enlarge.
Notice that 320x200 is not a 4:3 aspect ratio. You can probably
edit xmode.c to give a 320x200 aspect, but I like a little border,
so 320x240 works for me.
The original post from the author of xmode.c follows my .signature
--
-Chris May, Computer Science, University of MA, Amherst
- Technical Assistant, P.C. Maintenance Lab
cloister@u.washington.edu (cloister bell) writes:
>i read through VideoModes.doc, and worked through the steps for creating a
>video mode, and well, i was pleased to find that the results actually worked.
>but it occurs to me that someone has to have written a utility to do this
>automatically. something that would take a dcf value and a hsf value and give
>you back a line that you can stick in your Xconfig file. has anyone seen
>something like this?
ok, so maybe it's bad form to answer my own question, but i'm going to anyway.
since i posted the question, i decided it couldn't be that hard to write such a
utility, and i turned out to be correct. it was really easy, in fact, which is
why it surprises me that no such utility is included with the linux
distribution (at least, not with slackware 2.0, which is what i used).
anyway, the following utility takes as input values for your dot clock and
horizontal sync frequency and an optional horizontal sync pulse length, and
gives you back a line of numbers you can stick in your Xconfig file. read the
header comment for details:
/*------------------------------8< cut here 8< ------------------------------*/
/* XFree86 video mode timing generator for Linux. use this to create video
* modes for your Xconfig file from dot clock values and horizontal sync
* frequencies. */
/* to see why all this works, read /usr/X11/etc/VideoModes.doc. I don't claim
* that this program is anything other than a quick hack because i didn't want
* to calculate another video mode manually. one was enough. :) */
/* all the usual public domain stuff applies to this software:
* copyright jason black, 1994. you are free to copy, redistribute, and use
* this software to your heart's content provided that you leave this comment
* intact when you redistribute, that you always include this source file when
* redistributing, and that you don't go trying to sell this to anyone to make
* a profit. if you are redistributing on floppy disk, magtape, or any other
* removable media, then you may charge up to as much as the media costs.
* basically, i don't want anyone trying to in any way limit availability of
* this program, nor do i wany anyone trying to make a profit off my labor. */
/* this program should be easy to compile, as it doesn't do anything even
* remotely sneaky. compile it like this:
gcc xmode.c -o xmode
* this program is also easy to use. invoke it with no flags to get usage
* information. here are two sample runs of the program so you can see how
* easy it is:
foo> xmode -dcf 85 -hsf 64
refresh rate for this mode: 60.03Hz
percent of hfl used: 72.88%
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
1032x774 85 1032 1064 1384 1416 774 777 786 812
foo> xmode -dcf 85 -hsf 56.5 -hsp 3.5
warning: refresh rate is less than 60Hz for this mode.
refresh rate for this mode: 54.47Hz
percent of hfl used: 76.90%
mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl
1200x900 85 1200 1232 1528 1560 900 903 911 945
both of the above are actual results i got on my machine, and both were
functional video modes. the 1200x900 was too flickery to be usable, however,
which is why the less than 60Hz refresh rate warning is in there.
* note that while this program produces video modes that work, you will
* almost certainly have to tweak the hspstart and hspend values for your
* monitor. the program places the hsp more or less in the middle of the
* scanline, which may not be the best place for it for you. tweaking should
* be done in accordance with the tutorial in VideoModes.doc. specifically,
* hspstart, hspend, and hfl are the only numbers you should have to really
* mess with. hspstart and hspend should both be changed by the same amount if
* you change either. incrementing or decrementing hspstart and hspend will
* move the display right or left. incrementing or decrementing hfl will
* stretch or shrink the width of the display. all increments to these
* numbers must be in multiples of 8, as must horizontal timing numbers
* themselves. */
#include <stdio.h>
void main(int argc, char **argv);
void usage(char *argv0);
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen);
void main(int argc, char **argv)
{
float
/* input values: */
dcf = -1, /* dot clock frequency - from command line */
hsf = -1, /* horizontal sync frequency - from command line */
hsplen =3.8, /* length of horiz. sync pulse in microseconds */
/* calculated output values: */
hr = -1, /* horizontal resolution - calculated */
hspstart = -1, /* horizontal sync pulse start - calculated */
hspend = -1, /* horizontal sync pulse end - calculated */
hfl = -1, /* horizontal frame length - calculated */
vr = -1, /* vertical resolution - calculated */
vspstart = -1, /* vertical sync pulse start - calculated */
vspend = -1, /* vertical sync pulse end - calculated */
vfl = -1, /* vertical frame length - calculated */
/* intermediate values: */
hsp = -1, /* length of horiz. sync pulse in clock ticks */
linetime = -1, /* microseconds it takes for one scan line */
vsp = -1, /* length of vert. sync pulse in linetime units */
rr = -1 /* refresh rate */
;
int done = 0, hfl_last_tweaked = 0;
process_args(argc, argv, &dcf, &hsf, &hsplen);
/* now begins the fun stuff */
hfl = (int)(1000.0 * dcf / hsf); /* time for one scan line in dcf ticks */
hr = (int)(0.8 * hfl); /* shouldn't try and display more than 80% of hfl */
/* we need to engineer things so that hsp length is between 3.5 and 4 micro-
* seconds, and so that hfl - hfr = hsp (in clock pulses), and so that hfl,
* hfr, and hsp are divisible by 8. */
hsp = hsplen * dcf; /* 3.8 is in microseconds, hsp is in hsf clock pulses */
hsp -= (int)hsp % 8; /* force hsp to be a multiple of 8; round down */
hfl -= (int)hfl % 8; /* same for hfl */
hr -= (int)hr % 8; /* same for hr */
while(!done)
if(abs(hsp - (hfl - hr)) < 8) /* hsp and (hfl-hr) must be at most 8 apart */
done = 1;
else
{
if(hsp > (hfl - hr)) /* hfl and hr are too close together */
if(hfl_last_tweaked) /* alternately lower hr or raise hfl */
{
hr -= 8;
hfl_last_tweaked = 0;
}
else
{
hfl += 8;
hfl_last_tweaked = 1;
}
else if(hsp < hfl - hr) /* hfl and hr are too far apart */
if(hfl_last_tweaked) /* alternately raise hr or lower hfl */
{
hr += 8;
hfl_last_tweaked = 0;
}
else
{
hfl -= 8;
hfl_last_tweaked = 1;
}
else /* hfl - hr equals hsp. yay! */
done = 1; /* this is redundant, but who cares? */
}
hspstart = hr + 32; /* where the hsp pulse starts; 32 is magic. */
hspend = hr + 32 + hsp; /* where the hsp pulse ends */
hfl = hr + 32 + hsp + 32; /* calculate new hfl for that pulse configuration */
/* now we're done with the horizontal numbers. do a couple of checks: */
if (hr/hfl > 0.8)
fprintf(stderr,"warning: these values use more than 80%% of the hfl.\n");
rr = 1000*dcf/hfl;
if (rr < 60)
fprintf(stderr,"warning: refresh rate is less than 60Hz for this mode.\n");
fflush(stderr); /* just in case */
/* now do the vertical numbers */
vr = (int)(0.75 * hr); /* that 4:3 hr:vr screen ratio */
vfl = (int)(1.05 * vr); /* inverse of vr = .95 * vfl; we already know vr */
linetime = hfl / dcf; /* microseconds it takes for once scan line */
vsp = 150.0/linetime; /* number of scanlines worth of vsp */
vspstart = vr + 3; /* where the vsp pulse starts. 3 = guard time */
vspend = vr + 3 + vsp; /* where the vsp pulse ends; vspstart + vsp */
printf("refresh rate for this mode: %5.2fHz\n",rr);
printf("percent of hfl used: %5.2f%%\n",100*hr/hfl);
printf("mode-name dcf hres hspstart hspend hfl vres vspstart vspend vfl\n");
printf("%dx%d %d %d %d %d %d %d %d %d %d\n",
(int)hr,(int)vr,(int)dcf,
(int)hr,(int)hspstart,(int)hspend,(int)hfl,
(int)vr,(int)vspstart,(int)vspend,(int)vfl);
}
void usage(char *argv0)
{
fprintf(stderr,
"usage: %s -dcf dot_clock_freq -hsf horizontal_sync_freq [-hsp hsplen]\n",
argv0);
fprintf(stderr," -dcf is in MHz, no default value\n");
fprintf(stderr," -hsf is in kHz, no default value\n");
fprintf(stderr," -hsp is in microseconds, default value = 3.8\n");
exit(1);
}
void process_args(int argc, char **argv, float *dcf, float *hsf, float *hsplen)
{
int i;
if (argc < 5) usage(argv[0]);
if (argc%2 != 1)
{
fprintf(stderr,"error: each arg must be a name, value pair\n");
usage(argv[0]);
}
for(i = 1; i < argc; i+=2)
if(!strcmp(argv[i],"-dcf"))
sscanf(argv[i+1],"%f",dcf);
else if (!strcmp(argv[i],"-hsf"))
sscanf(argv[i+1],"%f",hsf);
else if (!strcmp(argv[i],"-hsp"))
sscanf(argv[i+1],"%f",hsplen);
else
{
fprintf(stderr,"unknown argument %s\n",argv[i]);
usage(argv[0]);
}
/* make sure both required args were given */
if(*dcf == -1 || *hsf == -1)
{
fprintf(stderr,"you must specify at least -dcf and -hsf values\n");
usage(argv[0]);
}
}
/*------------------------------8< cut here 8< ------------------------------*/
--
+-------------------------------------------------+---------------------------+
|tactical nuclear sdi stealth nsafood signature. | cloister@u.washington.edu |
+-------------------------------------------------+---------------------------+
------------------------------
Crossposted-To: comp.os.linux.help
From: hsw1@papa.attmail.com (Stephen Harris)
Subject: Reporting bugs (was ip forwarding/gatewaying with kernel 1.1.18 problems)
Date: Sat, 10 Sep 1994 09:17:11 GMT
GJGM (gmatche1@sol.UVic.CA) wrote:
: I seem to have a problem with kernel 1.1.18 (actually any
: kernel from 1.1.13 onward ). I have two machines , call
And later:
: Is this fixed in a later patch ?
First a silly question: why don't you get the latest kernel and find out???
Second: why cross post to .help and .admin ? ( I posted this to 'help' and
'development' because this message is applicable to both ). Cross posting
'help' questions doesn't do anyone any good.
And now a message to everyone:
It should always be realised that the 1.1 kernels are ALPHA, and changing
extremely rapidly (except for now that there are aims to a 1.2 release).
The 1.1.18 kernel is 32 releases old now! Many problems that existed in those
kernels have been fixed.
The first stage in reporting problems in ALPHA kernels is to get a relatively
new version. Preferably the latest :-) Then you determine if the problem
still exists. THEN you ask for help.
Going the other way - posting without getting the latest ALPHA - merely
generates needless traffic in these groups.
--
rgds
Stephen
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink