Linux-Development-Sys Digest #222, Volume #6 Tue, 5 Jan 99 21:14:11 EST
Contents:
interrupted system calls (Constantinos A. Kotsokalis)
Re: WDM Emulator, anyone? (mlw)
Re: WDM Emulator, anyone? (mlw)
Setting dma with hdparm in 2.2.0-pre4 (David Ronis)
Re: ppp-compress-xx problem in 2.2.0-pre4 (Alan McLean)
Re: Why I'm dumping Linux, going back to Windblows (Victor Wagner)
Re: Registry for Linux - Bad idea (Frank Sweetser)
umount causes segmentation fault w/2.2.0pre4 (Moses Glasner)
Re: Registry - Already easily doable, in part. (Todd Knarr)
Problem with pre2 and pre4 (Jon Frohlich)
Re: Redefining time_t (Tristan Wibberley)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Constantinos A. Kotsokalis)
Subject: interrupted system calls
Date: 5 Jan 1999 16:42:41 GMT
Reply-To: [EMAIL PROTECTED]
Heya :-)
I have been trying to run the following code on my Linux 2.0.36
system (glibc 2.0.7), without success:
=================================================================
/* This is as small as it gets :-) */
#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <signal.h>
extern int errno;
void alh(int a){
fprintf(stderr, "Caught alarm\n");
}
main(){
int sock, tmp;
struct hostent *hp;
struct sockaddr_in ba, ra;
struct sockaddr sender;
int sender_len = sizeof(struct sockaddr);
int remote_len = sizeof(struct sockaddr);
unsigned char *buf = (unsigned char *) malloc(4);
if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1){
perror("socket");
exit(errno);
}
ra.sin_addr.s_addr = inet_addr("127.0.0.1");
ra.sin_port = htons(37);
ra.sin_family = AF_INET;
ba.sin_family = AF_INET;
ba.sin_addr.s_addr = htonl(INADDR_ANY);
ba.sin_port = htons(0);
if (bind(sock, (struct sockaddr *)&ba, sizeof(struct sockaddr_in)) == -1){
perror("bind");
exit(errno);
}
if (sendto(sock, (void *)buf, 4, 0, (struct sockaddr *)&ra, remote_len) == -1){
perror("sendto");
exit(errno);
}
signal(SIGALRM, alh);
alarm(5);
tmp = recvfrom(sock, (void *)buf, 4, 0, &sender, &sender_len);
if (tmp == -1){
perror("recvfrom");
exit(errno);
}
alarm(0);
exit(0);
}
=================================================================
According to POSIX.1 (and Dr. Stevens ;-)) this should wait for
five seconds (provided there is a time server at port 37), then
catch SIGALRM, print ``Alarm caught'' and return from the recvfrom()
system call with a value of -1 and an error of interrupted system
call - then exit. This is what happens on Solaris 2.6, and HP/UX
(I don't remember the version number, sorry). On the other hand,
when run on my Linux box the handler is called, the message is
printed on the screen and it returns to the system call which
never exits. Taking a fast look through the kernel sources (so much
for my kernel programming virginity) I realised that when a system
call is interrupted, it calls the signal handler (if any) and then
restarts. This does not seem to happen in all cases though, but
depends on regs->eax content. I could not find more information on
this, and unfortunately I could not find my way into bypassing this
annoying bug (well some would call this a feature, I guess).
I should also note that if I do not set a handler for SIGALRM,
when it occurs the default handler prints ``Alarm clock'' on the
screen and the program exits - which seems to be quite normal.
To come to my question, does anyone know if there is some way
to make it behave according to POSIX.1? In other words, can I
tell the kernel somehow that I do not want the system call to start
over, but rather end right after the handler returns?
Thanks in advance,
Costas
--
Constantinos A. Kotsokalis || [EMAIL PROTECTED]
National Technical University of Athens - GREECE
Electrical and Computer Engineering Department
"Artificial intelligence is no match for natural stupidity."
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Tue, 05 Jan 1999 16:58:08 +0000
Inaki Castillo wrote:
>
> > Actually, WDM starts with the NT Driver model. We would probably start
> > with the NT DKK.
> >
>
> Have you any idea of what are you saying ?
>
> NT DDK is nothing by itself, you should reproduce all NT Kernel
> components to do any simple piece of driver to work. That is all the
> operating system. Win32 is in fact a layer above that.
>
> Maybe is better to move to NT.
I have been hacking the NT kernel for a while now. I know it very well.
Yes it is a *lot* of work. So is Mountain biking and child rearing. A
lot of work is not the issue. The issue is who is up for the challenge?
Are you?
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Tue, 05 Jan 1999 17:02:33 +0000
> >I am not saying this should be done to hurt Microsoft. Far from it, I
> >want to do this to help Linux. These two motives are not the same thing.
> >
That's my line and I'm sticking to it! ;-)
> I say stick with WDM. It limits the scope of your effort and leverages
> microsoft's efforts to ease windos out of the picture.
>
Wow, you seem to care about the project, should I count you in? I got
one other developer and an open invitation from the wine guys you use
whatever I need from wine.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Setting dma with hdparm in 2.2.0-pre4
Date: 5 Jan 1999 17:48:48 GMT
I normally tweek the settings of one of my drives with hdparm (3.5) at
boot time as:
/usr/local/sbin/hdparm -m8d1 /dev/hda
Since upgrading to 2.2.0-pre4 this gives:
/dev/hda:
setting multcount to 8
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted <==== This is new
multcount = 8 (on)
using_dma = 0 (off)
Moreover, running hdparm with no options shows that using_dma is off.
The drive in question shows,
/dev/hda:
Model=WDC AC31600H, FwRev=20.15T20, SerialNo=WD-WT2890799431
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=3148/16/63, TrkSize=57600, SectSize=600, ECCbytes=22
BuffType=3(DualPortCache), BuffSize=128kB, MaxMultSect=16, MultSect=8
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
CurCHS=3148/16/63, CurSects=3173184, LBA=yes
LBA CHS=787/64/63 Remapping, LBA=yes, LBAsects=3173184
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
IORDY=on/off, tPIO={min:160,w/IORDY:120}, PIO modes: mode3 mode4
which if I understand the output indicates that DMA is supported
(another drive where maxDMA=2 shows the same problem).
Here are the relevant lines from my .config file:
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
...
CONFIG_IDEDMA_AUTO=y
------------------------------
From: [EMAIL PROTECTED] (Alan McLean)
Subject: Re: ppp-compress-xx problem in 2.2.0-pre4
Date: Tue, 05 Jan 1999 14:25:00 GMT
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> David Ronis <[EMAIL PROTECTED]> writes:
>
> > There is a module request in ppp.c, and I suspect that the problem is
> > that I need an alias in /etc/conf.modules. Unfortunately, grepping
> > the source tree for ppp-compress doesn't show what it is.
>
> alias ppp-compress-21 bsd_comp
> alias ppp-compress-24 ppp_deflate
> alias ppp-compress-26 ppp_deflate
I believe the last one should be
alias ppp-compress-26 slhc
As you stated the docs are lacking, however, theres a good
chance a problem has been hashed out before on usenet.
http://www.dejanews.com/ is your friend, when the docs are
lacking.
cheers
-amcl
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 5 Jan 1999 23:01:51 +0300
Reply-To: [EMAIL PROTECTED]
Mike ([EMAIL PROTECTED]) wrote:
: I'm sorry! But this sentiment on the user interface is simply
: nonsense. Wanting to learn or use "vi" as opposed to something like
: super note tab is like wanting -- insisting-- on using a rock instead
: of a hammer to do your cabinet making.
I'll disagree - it is more like using open fire for cooking instead
of microwave. But there are a lot of thing, one can do with open fire
and couldn't with microwave, for example make glasswork or forging iron.
But it takes time to learn these things, and even takes some time to
learn how to cook with open fire. But once you've learned, you scarcely
give up ability to do complicationg things for simplicity of simple
things.
: This business of congratulating yourself on having overcome a steep
: learning curve, just tells many us us that you are waste a lot of time
: (or might be a masocist). Why not just insist on sensible tools that
: do the best work for the job at hand.
Problem is that it is impossible to do best work without learning,
regardless of tools you use. If something is so simple that you can use
it without learing, you can do only silly things with it.
There is a good compromise however - system which allows you to do silly
things silly way and clever things clever way. Linux is exactly this
compromise. Only problem with it that it is hard to find person who
would teach you how to do silly things, becouse any clever person simply
doesn't understand why one don't want to learn clever way from
beginning.
--
========================================================
I have tin news and pine mail...
Victor Wagner @ home = [EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 19:59:16 -0500
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> > > IMHO, this can be done using a network filesystem such as CODA, then the
> > > server just gives the configuration and the software accesses it as
> > > normal. You get encryption (?) and cacheing to boot. I have another
> > > message somewhere (very recently) about this.
> >
> > that's one option. and it does give those advantages. however 1) last
> > time i looked, CODA was pretty difficult to set up, and 2) program authors
> > still end up writing their own config file parsers. for most programs, the
> > ability to simply call something like get_config(option_name) instead of
> > doing it manually will completely eliminate the need to muck about with
> > groking the config files manually.
>
> In answer to:
> 1) instead of coming up with some new hard to configure scheme, wouldn't
> it be more productive to help make CODA easy to configure?
no. it would indeed be a worthy project on it's own merit, but is only
slightly related. it will be much more flexible, in that you can pick your
choice of flat text file, database, corba, etc, and the app needs to
neither know nor care how or where it's stored.
> 2) then a couple of libraries for parsing flat text will be most
> appropriate no? Simplest to implement.
agreed. this would be the first logical module to implement. i actually
have two of them in front of me now (profile code from the kerberos package
courtesy ted t'so, and libconfig from sunsite), one of which will probably
end up getting stuffed into the flat text module.
> The talk of complex network databases is far too premature at the moment
> - everyones always in such a rush to "innovate".
you certainly have a point - there always seems to be a few people looking
to implement the latest, sexiest theoretical paradigms, the type who want
change for change's sake. however, sometimes change can be a good thing.
i think that the opStore project has the potential to definatelly be a good
thing.
> I have to admit that the overriding values for local machines will be
> awkward to implement using the network fs scheme, but I hope to figure
> out a way of doing it that's quite easy to configure on the backend, and
> transparent on the client. Maybe write some scripts to help.
simply check the values in /etc/foo.defs, ~/.foocfg, then in /etc/foo.cfg,
and have the last assigned value take precedence.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
*** The previous line contains the naughty word "$&".\n
if /(ibm|apple|awk)/; # :-)
-- Larry Wall in the perl man page
------------------------------
From: Moses Glasner <[EMAIL PROTECTED]>
Subject: umount causes segmentation fault w/2.2.0pre4
Date: 05 Jan 1999 19:29:30 -0500
I am running 2.2.0pre4 on a 486 and get the following
when doing umount on a dos partition.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
current->tss.cr3 = 00d25000, %cr3 = 00d25000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0126e64>]
EFLAGS: 00010286
eax: 00000000 ebx: c1250000 ecx: 00000301 edx: c1244ea0
esi: 00000000 edi: c1250000 ebp: 00000301 esp: c0d27f7c
ds: 0018 es: 0018 ss: 0018
Process umount (pid: 121, process nr: 21, stackpage=c0d27000)
Stack: 00000000 00000301 c0125cb9 c1250000 00000000 08040301 c0cf0b30 bffffb38
c0125d97 00000301 00000000 c0d26000 0804e731 0804c26b c0125dbc 0804e730
00000000 c0107b84 0804e730 0000006d 0804e730 0804e731 0804c26b bffffb38
Call Trace: [<c0125cb9>] [<c0125d97>] [<c0125dbc>] [<c0107b84>]
Code: 8b 40 08 66 8b 40 2a 25 ff ff 00 00 50 e8 0a c1 ff ff 83 c4
Segmentation fault
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 6 Jan 1999 01:29:35 GMT
In comp.os.linux.development.system Andrew Morton <[EMAIL PROTECTED]> wrote:
> I was referring to the proposals which would require kernel
> modifications: magical /proc files, files which are in reality attached
> to processes, etc.
OK, now that _would_ be Linux-specific ( or at least specific to those
machines that supported /proc in a Linux-like way ).
> What I'm getting at is that a one-line change implies all config is to
> be rescanned. This edit/SIGHUP scheme works now because application
> developers have never had anything else available.
True, but it is working. IMHO anything nominated as a replacement should
work at least as well, keeping all the advantages of the manual-SIGHUP
scheme ( eg. precise control of when configuration changes get committed
to the running servers ).
> One should, for example, be able to add/delete/modify a line to
> /etc/inetd.conf and not have to whack inetd. This is a trivial case.
> If a mechanism existed for applications to be notified of
> reconfiguration, they would have used it extensively and ave been more
> sophisticated as a result.
I write software that has complex configuration. I've tried to set it up
to only change the bits it needs. Inevitably, I wind up tossing the lot
as too complex and going back to the old "Read the new configuration into
a blank slate. If you read it correctly replace the global configuration
with the new data and reconfigure everything as if you had just started
up, otherwise report an error and continue to use the old configuration."
method. It's more code, but it is mostly shared with the code needed to
read in the configuration on startup anyway and it usually winds up being
simpler and more robust. The fancier I get with configuration, the more
fragile the code inevitably is and the more things break as the system
evolves and changes.
> [ You should see the crap I have to go through to be able to PPP into
> either uow.edu.au _or_ Nortel's intranet - sedding /etc/resolv.conf,
> massaging named.boot, restarting named. It stinks. ]
I think this has more to do with the type of reconfiguration you're
doing than anything else. I've had to set this up at one point, and
I simply worked out the steps involved and put them into the scripts
that bring the interfaces up. Every time I bring an interface up, the
appropriate things get done ( mainly through symlinks, eg. I have two
copies of named.conf, one for each network, and the interface-up script
symlinks named.conf to the appropriate one ).
If you're running a local caching nameserver, point resolv.conf at
127.0.0.1 and use "forwarders" lines in named.conf to get the nameserver
to point to the correct places. Switch named.conf, SIGHUP named and
you're using the new set of nameservers without needing to muck with
resolv.conf.
This is a case where some changes would help. Not so much a change in the
way things are stored, but a standard way of storing per-connection copies
of the neccesary files so that the scripts can take a "connection name"
tag and locate and install the correct files without you having to hand-hack
the scripts for your machine. It also points up the problem with a lot
of configuration designs: they are limited by what the designers thought
of at the time. I would note a feature of the current system: you _can_
hack your way around the original limitations with the existing Unix
setup, where with a lot of the registry-type suggestions you'd be SOL
if the original design didn't anticipate your particular bit of insanity.
--
We won, didn't we? Cope!
-- Mimi, Reality Check #8
------------------------------
From: [EMAIL PROTECTED] (Jon Frohlich)
Subject: Problem with pre2 and pre4
Date: 6 Jan 1999 00:58:17 GMT
Hopefully someone can help me out with this problem. I've
compiled both pre2 and pre4 and have gotten the same problem. I
compile and isntall the kernel and reboot, when the machine comes back
I have no username/password login prompt. If I attempt to telnet
into the machine I get the following error:
"Can't change to /dev/ttyp0 : Bad file number"
Also happens the one I got connected /dev/ttyp1.
Brief hardware list:
Pentium 90
Intel Neptune Motherboard (other than that I don't know)
Seagate ST15150N 4.3 gig scsi drive
4x SCSI Cdrom
3com 3c509 network card
Anyone got any clues? Somone I talked to suggested emailing Alan Cox
which I found extreme. All config settings when making the kernel have
been checked and rechecked.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Redefining time_t
Date: Wed, 06 Jan 1999 01:46:33 +0000
Reply-To: [EMAIL PROTECTED]
H. Peter Anvin wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author: [EMAIL PROTECTED]
> In newsgroup: comp.os.linux.development.system
> >
> > Long long should not be used - see below for why.
> >
>
> Why not? I don't see any below. "long long" is added in the new C
> standard.
>
> >
> > Isn't time_t guaranteed to be a 32 bit signed interger value
> > representing the time since 00:00 1 Jan 1970? If so, the format is not
> > guaranteed (good :), so no applications manipulate it directly (if they
> > do, let them break - it's the programmers own stupid fault). So you can
> > redefine it as 64bits, and change the libc functions. Then recompile and
> > everythings done except storage and communication formats that assume
> > 32bits. Any sensible format holds a format version key, and the format
> > can be redefined with the new time_t.
> >
>
> time_t is guaranteed to be a signed integer value representing the
> number of seconds since 1970-01-01 00:00:00 UTC (possibly with the
> exception of leap seconds.)
>
> Not necessarily 32 bits.
Good job I asked what the exact specification is then... :)
As to the long long. If you define it as long long, you guarantee the
format of time_t (manually alterable as a long long normally is), then
future changes like this break source code.
Since the standards don't define it as 32bit, and not much CPU time is
ever spent on time_t manipulations, It would be acceptable I think for
time_t to be made 64bit on 32bit machines. I don't think this should
happen until the kernel folks are ready to support it because the format
will need to be defined by them to allow the kernel to use only offsets
on 32bit machines (and get high efficiency converting for userland).
It could possibly become a 2.3 thing, so that should give you an idea of
how long it may be.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
