Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest269
2024-02-19 00:24:15 -05:00

827 lines
28 KiB
Plaintext

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, 6 Oct 94 07:13:12 EDT
Subject: Linux-Development Digest #269
Linux-Development Digest #269, Volume #2 Thu, 6 Oct 94 07:13:12 EDT
Contents:
Re: What GUI to write for? (Nhi Vanye)
LINUX & VESA vs ISA (C. Joseph Bridwell)
Re: Improving SLIP latency under Linux (John Richardson)
Re: Adaptec 1542/SCSI under Linux (Steffen W. Schilke)
Re: mounting > 32 drives (H. Peter Anvin)
1.6Mb floppies under Linux? (ron house)
Re: Improving SLIP latency under Linux (Nick Kralevich)
Re: [STATUS] Linus Floppy Driver Development (David Holland)
Re: linux-activists@Niksula.hut.fi (Rob Janssen)
Re: mounting > 32 drives (Hannes Reinecke)
Re: 1.1.45 config? (Rob Janssen)
Re: umount problem! (Rob Janssen)
Re: DOSEMU Questions (386 mode?) (Rob Janssen)
Re: Improving SLIP latency under Linux (Rob Janssen)
Re: Does linux implement semaphores? (Karl Keyte)
1.1.45 config? (Marty Leisner 25733)
A bunch of stuff about DOSEMU (long) (Marty Leisner 25733)
----------------------------------------------------------------------------
From: offer@robots.ox.ac.uk (Nhi Vanye)
Subject: Re: What GUI to write for?
Date: Tue, 4 Oct 1994 16:02:13 GMT
In article <36hcj5$b38@panix2.panix.com>,
Marten Liebster <mmarten@panix.com> wrote:
>I want to write a X application or two. At first they would be for
>personal use, but eventually I might make them availble for the
>public to use.
>
>I am not sure which GUI/toolkit to use. It would be nice to keep it
>portable to use under various UIs. Do I have to use Xlib? or can I
>write them using XView?
>
>I would appreciate any guidence I could recieve. Thanks for any and
>all help.
Ah, ha, this sort of message is the equivalent of lighting the blue
touch paper and taking 2 steps back :-)
Which GUI to use is now becoming a religeous issue of the same size as
C v Pascal was five years ago.
Everybody is going to say use <xxx> (where <xxx> is their favourite
GUI) for <yyy> (where <yyy> is a (possible) reason for using it).
Your choice (and it is yours) depends on several factors:-
1) any experience of any GUI.
2) intended customer base
3) programming language
1) if you have used Motif/Windoze/OpenLook before then stick with it.
2) initially you, but then what, is it the sort of program that would
be used across multiple architectures (be honest). The more machines
it runs on the more standard you are going to have to be. If you are
hoping to get in into big sites (with commercial Unix), then Motif
isn't really a problem, it is however for all us linux people ('cept
me) but you can ship a static binary..
3) are you using C or C++, if C++ then why not make use of a class
library that supports both Motif and athena transparently. If you
don't mind not talking to widgets directly then why not use a generic
API, like (ah my minds gone blank...).
Thats the advantage of democracy, you have a choice, Motif or
something a load of rubbish :-)
richard.
>
>Marten
>
>--
>----------------------------------------
>Marten M. Liebster Please no flames for spelling,
>mmarten@panix.com I already know I can't spell!!
--
------------------------------
From: darkwind@chinook.halcyon.com (C. Joseph Bridwell)
Subject: LINUX & VESA vs ISA
Date: 5 Oct 1994 00:55:53 GMT
I'd like to know whether people installing LINUX have had more, the same,
or less problems depending on whether the PC was VLB or ISA.
------------------------------
From: jrichard@cs.uml.edu (John Richardson)
Subject: Re: Improving SLIP latency under Linux
Date: 5 Oct 1994 01:52:27 GMT
Anyone who doesn't mind testing out a small patch to fix TOS
queuing (probably only noticable under SLIP, PPP, etc): send me some
mail at jrichard@cs.uml.edu and I'll send you the patch.
It makes ftp-ing huge files and telneting at the same time bareable
if the MTU is set to about 296. However, it is still pretty ALPHA
and not tested much... but I'm using it now and I can barely tell
I'm ftp-ing linux-0.01.tar.Z. :)
--
John Richardson
jrichard@cs.uml.edu
------------------------------
From: sws@tora.RoBIN.de (Steffen W. Schilke)
Subject: Re: Adaptec 1542/SCSI under Linux
Date: Sat, 1 Oct 1994 21:18:09 GMT
Jason Malaure (Jason@indev.demon.co.uk) wrote:
: I would like to know how reliable SCSI generally is under Linux. I have
: had some problems witj my Fujitsu floptical but I am quite prepared
: to accept that lies with the way the drive behaves, however I would
: be very interested to find out how people have been getting with
: large SCSI drives (>1 gig or so) as I am thinking of buying one!
Here a 1542CF runs fine with a 1.2 GB Toshiba HD and 2 SCSI CD ROM
drives (Apple CD150 and Toshiba 3301). The only problem was the
translation mode (I still have a 700 MB DOG partition) after I switched
it of (and did all the fdisk stuff again) it worked fine.
I get the messeage "> 1024 Cyl." but if you keep the root directory below
the 1024st Cyl. the rest works fine and can access everything above 1024
Cyl.
: Many thanks
: Jason.
: --
: Jason Malaure
--
[Standard Disclaimer] in addition I would like to speak with my lawyer ....
S. Schilke; PoBox 1213; 61102 Bad Vilbel; Germany a.k.a sws@tora.RoBIN.de
Sokonoke Sokonoke tora-sama ga touru
$@%9%F%U%'%s(J $@CN2H!Z%7%k%1![(J $@$=$3$N$1$=$3$N$18WMM$,DL$k(J
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: mounting > 32 drives
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Wed, 5 Oct 1994 06:46:41 GMT
Followup to: <36tego$pc0@hobbes.cc.uga.edu>
By author: taylor@pollux.cs.uga.edu (john taylor)
In newsgroup: comp.os.linux.development
>
> I would like to mount more than 32 drives, but the mount program will
> not let me. Is there a #define somewhere /usr/src/linux/include/linux
> that I can change to fix this. I looked, but was unable to find it in
> the code. Any ideas on how I can mount more than 32 drives?
>
The file is /usr/src/linux/include/linux/fs.h; the parameter you're
looking for is NR_SUPER.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
#include <sig/virus.h>
------------------------------
From: house@helios.usq.EDU.AU (ron house)
Subject: 1.6Mb floppies under Linux?
Date: Thu, 6 Oct 1994 03:43:26 GMT
For years I have used a DOS program called smax, which formats
floppies to 1.6Mb on a 1.44Mb drive, (and similar increases on the
other 3 drive types). The documentation with that prog. said that
DOS disks had 10 sectors per track, but that DOS, for whatever
reason, only used 9 of them, and so the prog. simply told the
drive to use all 10. A little TSR was also involved. I have
used hundreds of these disks with no problems. Now, Linux won't
read them, because of the assumptions in the floppy devices under
/dev.
My question: where are the 'sources' for the /dev floppy drives?
Do they need recompilation of the kernel in order to add new
drive types? It would be nice if Linux gave everyone 1.6Mb drives,
the difference is very useful indeed.
--
Ron House. USQ
(house@usq.edu.au) Toowoomba, Australia.
------------------------------
From: nickkral@po.EECS.Berkeley.EDU (Nick Kralevich)
Subject: Re: Improving SLIP latency under Linux
Date: 5 Oct 1994 07:37:48 GMT
In article <1994Oct3.191439.12908@pvi.com>,
Christopher Michael Joslyn <chrisj@pvi.com> wrote:
>The main problem is that an ftp packet is much larger than, say, a telnet or
>ping packet. Because the ftp packet is large, the packets must be broken up
>into sizes that can be sent over the line (this is your MTU at work), thus
>the ftp packet takes longer to send. Additionaly, an ftp connection typically
Actually, I think I came up with a different solution of my own.
As I started doing more and more investigations, I found that the
interactive SLIP delay during heavy ftp transfers was about 3 seconds.
John sent me a patch to try to solve the problem, and it reduced the
problem a bit, but not by much. I eventually figured out what I
think might be the problem.
My modem is a US Robotics Sportster 14.4 modem. The modem has a
built in transmit data buffer of 3.25 Kbytes, and a receive data buffer
of 2 Kbytes. I believe it is this buffer which is killing my
interactive response during large transfers.
The transmit data buffer can be reduced to 1.5 Kbytes by turning off
error correction, however, that's not somthing I want to do. Does
anyone know how to turn off/down the buffer size? I've tried going
through the manuals, to no avail.
In my rush to blaim the kernel for my problems, I completely forgot
to look at my own hardware. Forgive me. :)
Thank you to everyone who helped.
Take care,
-- Nick Kralevich
nickkral@cory.eecs.berkeley.edu
--
Nick Kralevich nickkral@cory.eecs.berkeley.edu
"A man sits with a pretty girl for an hour and it seems shorter than
a minute. But tell that same man to sit on a hot stove for a minute,
it is longer than any hour. That's relativity." -- Einstein
------------------------------
Subject: Re: [STATUS] Linus Floppy Driver Development
From: dholland@husc7.harvard.edu (David Holland)
Date: 1 Oct 94 13:51:35
gjh@ukc.ac.uk's message of Wed, 28 Sep 94 16:20:41 GMT said:
> This is easy. It also implies the biggest gain by having this code
> exist - in the kernel, or as a loaded driver.
>
> You mount by volume name.
> [good description omitted]
Exactly.
--
- David A. Holland | -- "Do you have a moment?" -- "Yes.
dholland@husc.harvard.edu | Unfortunately, it's a moment of inertia."
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: linux-activists@Niksula.hut.fi
Reply-To: pe1chl@rabo.nl
Date: Wed, 5 Oct 1994 20:48:27 GMT
In <19941004.183438.730669.NETNEWS@ESOC> kkeyte@esoc.bitnet (Karl Keyte) writes:
>In article 58K@PE1CHL.AMPR.ORG, rob@pe1chl.ampr.org (Rob Janssen) writes:
>>But unfortunately you can't specify the address yourself. It blindly
>>takes the address it finds in the From: line. This loses badly when your
>>address has changed, or the translation of the From: address which happens
>>in the mail routers has changed.
>>
>>I have experienced already two times that the only way to unsubscribe was
>>to write a message to the operator :-(
>The change in mail routing is exactly the problem I have. I cannot unsubscribe.
>I have also tried mailing root, postmaster and operator, but to no avail. I think
>the system needs to be made a little more inteligent in its handling of addresses.
>How do I even SEE the addresses it THINKS it has for me?
Read the document that you get mailed to you when yoi do something wrong.
It explains how to get a list of channels a specified user is on. Call
that function with a certain string that is likely to be in your mail address
after all the mishandling (e.g. your login-name).
That will return you the list of channels and the full address the darned
thing expects to see in the From: header for you to unsubscribe. But when
you cannot re-produce that address for whatever reason you are out of luck...
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: hare@zarquon.mathi.uni-heidelberg.de (Hannes Reinecke)
Subject: Re: mounting > 32 drives
Date: 05 Oct 1994 22:32:39 GMT
taylor@pollux.cs.uga.edu (john taylor) schrieb:
I would like to mount more than 32 drives, but the mount program will
AEHMM .... How do you actually _connect_ 32 drives ???
4 SCSI-Adapters or what ?
not let me. Is there a #define somewhere /usr/src/linux/include/linux
that I can change to fix this. I looked, but was unable to find it in
the code. Any ideas on how I can mount more than 32 drives?
And, by the way, what do you _want_ with 32 drives ?
Sheer curiosity.
Thanks,
John
Dito,
Hannes
=======
Hannes Reinecke |
<hare@vogon.mathi.uni-heidelberg.de> | XVII.: WHAT ?
|
PGP fingerprint available | T.Pratchett: Small Gods
see 'finger' for details |
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.45 config?
Reply-To: pe1chl@rabo.nl
Date: Wed, 5 Oct 1994 22:21:03 GMT
In <1994Oct4.174558.21475@news.wrc.xerox.com> leisner@batman (Marty Leisner 25733) writes:
>I got the 1.1.45 kernel from sunsite (I'm currently running 1.1.19).
>There's no config file with it...
>Should I use my 1.1.19 configuration?
No, you just "make config".
Please read the README file provided with the kernel to know how to
patch, configure and compile it.
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: umount problem!
Reply-To: pe1chl@rabo.nl
Date: Wed, 5 Oct 1994 22:30:02 GMT
In <36uoue$1lj@mark.ucdavis.edu> slouken@cs.ucdavis.edu (Sam Oscar Lantinga) writes:
>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>: Arghh!! The fix for this has been on this group *so many* times that
>: it is really your own fault when you don't know about it...
> Okay, so when is it going to come out in a kernel patch?
>Are there any more kernel patches coming out, or are we moving to a
>code freeze?
No, our hero is taking a few days off. Just be patient.
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: DOSEMU Questions (386 mode?)
Reply-To: pe1chl@rabo.nl
Date: Wed, 5 Oct 1994 22:32:58 GMT
In <36ugt2$id3@DGS.dgsys.com> hitman@dgs.dgsys.com (Douglas Rankin) writes:
> I know this is probably a dumb question. does dosemu emulate 386 protected
>mode? If not are there plans to do so?? The reason I am wondering is that
>I have several dos programs that use Phar Lap dos extender and it won't
>run becasue it say the chip is in 8086 mode. Is there a way to have it run
>in 385 mode so I can run thse programs, If so how, any help would
>be apprecited!! Thanks
It doesn't, and I don't think it will do it any time soon.
However, most dos extenders (I don't know Phar Lap) are also willing to
live with one of the protected mode interfaces, like DPMI. This is
currently being worked on in dosemu.
(incomplete DPMI support already exists, people are debugging and extending
it)
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: Improving SLIP latency under Linux
Reply-To: pe1chl@rabo.nl
Date: Wed, 5 Oct 1994 22:37:28 GMT
In <36tl4c$ecv@agate.berkeley.edu> nickkral@po.EECS.Berkeley.EDU (Nick Kralevich) writes:
>In article <1994Oct3.191439.12908@pvi.com>,
>Christopher Michael Joslyn <chrisj@pvi.com> wrote:
>>The main problem is that an ftp packet is much larger than, say, a telnet or
>>ping packet. Because the ftp packet is large, the packets must be broken up
>>into sizes that can be sent over the line (this is your MTU at work), thus
>>the ftp packet takes longer to send. Additionaly, an ftp connection typically
>Actually, I think I came up with a different solution of my own.
>As I started doing more and more investigations, I found that the
>interactive SLIP delay during heavy ftp transfers was about 3 seconds.
>John sent me a patch to try to solve the problem, and it reduced the
>problem a bit, but not by much. I eventually figured out what I
>think might be the problem.
>My modem is a US Robotics Sportster 14.4 modem. The modem has a
>built in transmit data buffer of 3.25 Kbytes, and a receive data buffer
>of 2 Kbytes. I believe it is this buffer which is killing my
>interactive response during large transfers.
>The transmit data buffer can be reduced to 1.5 Kbytes by turning off
>error correction, however, that's not somthing I want to do. Does
>anyone know how to turn off/down the buffer size? I've tried going
>through the manuals, to no avail.
This is a known problem (at least to me and my group at work) with all
compressing-and-error-correcting modems.
For a project we are doing, we have decided we don't want any compression
and error correction in the modems, it has to be done in the routers.
We operate the modems in HDLC mode, and the resulting buffer is very
small. (it depends on the type of modem, but it could be as small as 12 bits)
This results in a big improvement in interactive response while file
transfers are running.
(the project is about routing LAN traffic over PPP links, but the problems
are essentially the same as what you are discussing)
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
Date: Wed, 5 Oct 1994 09:57:27 +0100
From: kkeyte@esoc.bitnet (Karl Keyte)
Reply-To: kkeyte@esoc.bitnet
Subject: Re: Does linux implement semaphores?
In article D93@IX.DE, hm@ix.de (Harald Milz) writes:
>In comp.os.linux.development, Neal Patrick Howland (nhowland@ksu.ksu.edu) wrote:
>> I was wondering in the standard linux develpment packages implemented
>> a semaphore synchronization call. If not, how do you synchronize two
>> processes to keep them from entering their critical sections at the same
>> time?
>
>Using named pipes is an elegant method to achieve this.
I always find semaphores useful for this!
Yes, Linux DOES provide semaphores.
Karl
=========================================================================
Vitrociset S.p.A. Tel : +(49) 6151 902041
European Space Agency Fax : +(49) 6151 904041
64293 Darmstadt, Germany e-Mail: KKEYTE@ESOC.BITNET
------------------------------
From: leisner@batman (Marty Leisner 25733)
Subject: 1.1.45 config?
Reply-To: leisner@sdsp.mc.xerox.com
Date: Tue, 4 Oct 1994 17:45:58 GMT
I got the 1.1.45 kernel from sunsite (I'm currently running 1.1.19).
There's no config file with it...
Should I use my 1.1.19 configuration?
--
marty
leisner@sdsp.mc.xerox.com
Member of the League for Programming Freedom
Object techonology is to software what microprocessors are to
hardware.
Phillipe Kahn
------------------------------
From: leisner@batman (Marty Leisner 25733)
Subject: A bunch of stuff about DOSEMU (long)
Reply-To: leisner@sdsp.mc.xerox.com
Date: Wed, 5 Oct 1994 16:03:19 GMT
I tried to join the DOSEMU tract of linux-activists, but I'm not convinced its working
(I did a join, never received a response or any messages).
Is there anything coming over the tract?
Anyway, I'm running 1.1.19 and dosemu53pre22
1) I need to do a kill -9 to terminate it as root
when its hung.
Shouldn't I be able to do something else (like kill -QUIT).
2) I'm not sure I like the idea of if stderr == stdout,
redirecting stderr to /dev/null. I think it may make more
sense and be easier to use to do stderr to mktmpfile.
For example, I had to run it under strace to realize it was
reading my .dosrc file but not the /etc/dosmeu.conf file...
and I got:
pen("/u/marty/.dosrc", O_RDONLY) = 5
brk(0x11d000) = 0x11d000
ioctl(5, TCGETS, 0xbffff688) = -1 EINVAL (Invalid argument)
fstat(5, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
read(5, "#\n", 1024) = 2
read(5, "", 1024) = 0
read(5, "", 1024) = 0
ioctl(5, TCGETS, 0xbffff67c) = -1 EINVAL (Invalid argument)
close(5) = 0
rmdir("/tmp/dosem01342aaa") = -1 ENOENT (No such file or directory)
setitimer(ITIMER_REAL, NULL, NULL) = 0
sigaction(SIGALRM, {0x200064a0, [ALRM], SA_RESTART}, NULL) = 0
sigaction(SIGSEGV, {0x200064a0, [ALRM], SA_RESTART}, NULL) = 0
sigaction(SIGILL, {0x200064a0, [ALRM], SA_RESTART}, NULL) = 0
sigaction(SIGFPE, {0x200064a0, [ALRM], SA_RESTART}, NULL) = 0
sigaction(SIGTRAP, {0x200064a0, [ALRM], SA_RESTART}, NULL) = 0
write(2, "leavedos(0) called - shutting do"..., 35) = 35
write(2, "calling close_all_printers\n", 27) = 27
write(2, "LPT: closing printer 0 ((null))\n"..., 32) = 32
write(2, "LPT: closing printer 1 (lpt2)\n", 30) = 30
write(2, "LPT: closing printer
It would be nice if something was announced by default, instead
of redirecting stderr to something other than stdout...
Also, 2 reads at EOF, followed by an IOCTL, so
I don't really understand what's going on.
It doesn't look right.
3) How do I run the emulator in an xterm without curses?
If I just want straight tty emulation (to capture to a logfile), I don't want
the curses characters mixed in.
The best I can do is run script on dos and it appears to be right.
4) I'm usign Ian Stewartson's msh...when I use the 32 bit shell
with the Rational systems extender, it exited the program quietly (probably
because stderr=stdout)
5) I really don't understand why the architecture is as is...
i.e. dos is a small program which loads a shared library...
Why not make one executable...
(this is what I ended up doing)
Also all the subdirectories use ld instead of just generating objects
or libraries to get linked in...
When you call make, always call $(MAKE) so make -n works right...
The make architecture is somewhat cumbersome...i.e. make most tries
to do a make install and a make dep...
It would be much easier if make did a make without acking any questions
(this won't run from nohup) and a "make most"
would do
most: dep $(TARGETS)
make install should be a seperate step, I don't run make install as
root and if I need to setuid executables, I do it by hand.
Also, it doesn't easily pass down CFLAGS... I ended up doing
make CC='gcc -g'
to get debugging turned on.
6) I'm running a 1.1.19 kernel.
I had to make these changes:
in dpmi.c, seg_not_present isn't there and isn't needed...
I'm not even using dpmi yet, so it doesn't make a difference...
eving revision 2.7
diff -c -r2.7 dpmi.c
*** 2.7 1994/08/05 22:31:46
--- dpmi.c 1994/10/01 02:27:24
***************
*** 164,170 ****
--- 164,173 ----
ldt_info.contents = contents;
ldt_info.read_exec_only = read_only_flag;
ldt_info.limit_in_pages = limit_in_pages_flag;
+ /* for some reason, this isn't the 1.19 kernel */
+ #ifdef NEW_KERNEL
ldt_info.seg_not_present = 0;
+ #endif
if (__retval=modify_ldt(1, &ldt_info, sizeof(ldt_info)))
return __retval;
***************
*** 195,201 ****
--- 198,206 ----
((ldt_info.read_exec_only ^ 1) << 9) |
(ldt_info.seg_32bit << 22) |
(ldt_info.limit_in_pages << 23) |
+ #ifdef NEW_KERNEL
((ldt_info.seg_not_present ^1) << 15) |
+ #endif
0x7000;
return 0;
}
I can't even make the sillyint stuff, so I didn't (took out sig
in the master Makefile).
I didn't read the sig/Howto carefully, but I saw 1.1.45 and
I'm not sure if its important or not...
7) Look at automatically generating the dependicies...
gnu make has a section on this in the manual...each .c file
produces a .d file... so you see it instead of .depend...
8) You have a strategy of :
# Set X_SUPPORT to 0 if you don't have X windows installed.
This doesn't work, since
ifdef
in make is true if X_SUPPORT is defined...
I had problems with the X_SUPPORT, so I took it out for now...
9) It seems the -F file options didn't work...
I reworked the parser. I also find using FILE volatile *fd
was a confusing thing...it doesn't seem necessary to be
volatile, and fd normally means an fd...
Here's my changes:
*** 1.1 1994/10/02 06:35:47
--- parser.y 1994/10/02 06:59:18
***************
*** 1287,1295 ****
}
int
! parse_config(char *confname)
{
! FILE *volatile fd;
#if YYDEBUG != 0
extern int yydebug;
--- 1287,1296 ----
}
int
! parse_config(char *confname /* file name passed down */)
{
! /* what ??? -- why volatile -- fd is a bad name for a FILE * */
! FILE *file;
#if YYDEBUG != 0
extern int yydebug;
***************
*** 1306,1333 ****
/* If that doesn't exist we will default to CONFIG_FILE */
{
- char *home = getenv("HOME");
- char *name = malloc(strlen(home) + 20);
- sprintf(name, "%s/.dosrc", home);
if (getuid() != 0) {
if (!exchange_uids()) die("Cannot exchange uids\n");
if (!exchange_uids()) die("Cannot changeback uids\n");
}
! if (!(fd = open_file(name))) {
! fprintf(stderr, "Cannot open user config file %s, Trying default.\n",name);
! if (!(fd = open_file(CONFIG_FILE))) {
fprintf(stderr, "Cannot open default config file %s, Aborting DOSEMU.\n",CONFIG_FILE);
exit(1);
}
}
! yyin = fd;
line_count = 1;
if (yyparse())
yyerror("error in user's configuration file");
! close_file(fd);
}
#ifdef TESTING
--- 1307,1355 ----
/* If that doesn't exist we will default to CONFIG_FILE */
{
if (getuid() != 0) {
if (!exchange_uids()) die("Cannot exchange uids\n");
if (!exchange_uids()) die("Cannot changeback uids\n");
}
! if(confname) {
! file = open_file(confname);
! if(file == NULL) {
! char buffer[strlen(confname) + 40];
!
! sprintf(buffer, "Cannot open %s\n", confname);
! die(buffer);
! }
! goto found_file;
! } else {
! /* try users dosrc file */
! char *home;
!
! home = getenv("HOME");
! if(home) {
! char name[strlen(home) + 20];
!
! sprintf(name, "%s/.dosrc", home);
!
! file = open_file(name);
! if(NULL != file)
! goto found_file;
! }
! /* try default fault */
! file = open_file(CONFIG_FILE);
! if(file == NULL) {
fprintf(stderr, "Cannot open default config file %s, Aborting DOSEMU.\n",CONFIG_FILE);
exit(1);
}
}
! found_file:
! yyin = file;
line_count = 1;
if (yyparse())
yyerror("error in user's configuration file");
! close_file(file);
}
#ifdef TESTING
10) I see some instances of exit(-1). What this does it
the same as exit(0xff). Probably is better to just do exit(EXIT_FAILURE)
or exit(1).
I'm very impressed by it so far...
--
marty
leisner@sdsp.mc.xerox.com
Member of the League for Programming Freedom
Committees do not design! They are never held responsible, nor are
they rewarded or punished. Committees can review.
C. Gordon Bell
------------------------------
** 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
******************************