Path: bga.com!news.sprintlink.net!EU.net!sunic!news.funet.fi!
hydra.Helsinki.FI!news.helsinki.fi!not-for-mail
From: torva...@cc.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux.development
Subject: Linux 1.1.61, codename 'bugfree' is released
Date: 2 Nov 1994 14:33:06 +0200
Organization: University of Helsinki
Lines: 24
Message-ID: <3980u2$h4j@kruuna.Helsinki.FI>
NNTP-Posting-Host: kruuna.helsinki.fi
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Ok, ftp.funet.fi and ftp.cs.helsinki.fi now contain the latest and
greatest linux kernel, 1.1.61 (also known as "bugfree", for obvious
reasons). You'll find it as patches against 1.1.60 (also known as "the
buggy one") in the directories pub/OS/Linux/PEOPLE/Linus/v1.1 and
pub/Software/Linux/Kernel/v1.1 respectively.
V1.1.61 does:
- new Digital EtherWorks 3 ethernet driver (David Davies)
- updated SBPCD driver (Eberhard Moenkeberg)
- updated qic-02 driver (Hennus Bergman)
- fixed floppy blocksize stuff (Bruno Haible and me)
- various small (u)msdosfs fixes (Jacques Gelinas and Bruno Haible)
- SysV IPC code cleanups (Bruno Haible again - this man is obviously on
steroids, and is working on being elected the "Eric Youngdale of the
year").
- fixed block_read() (me). This fixes the LILO installation failure
and kernel message.
- networking fixes (me). These fix the UDP problem.
Anyway, you obviously realize that this is the version to get, and that
if you find a bug in it you're just misguided. But send me a report in
any case..
Linus
Newsgroups: comp.os.linux.development
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!news.cac.psu.edu!
news.pop.psu.edu!hudson.lm.com!godot.cc.duq.edu!newsfeed.pitt.edu!uunet!
sensor!dnb
From: d...@orgland.ru (Dmitri Belosludtsev)
Subject: Re: Linux 1.1.61, codename 'bugfree' is released
Organization: Firm "Orgland", Zelenograd, Russia.
Date: Thu, 3 Nov 1994 00:40:44 GMT
Message-ID: <Cyo1vy.9D4@orgland.ru>
X-Newsreader: TIN [version 1.2 PL2]
References: <3980u2$h4j@kruuna.Helsinki.FI>
Distribution: world
Lines: 74
Hi!
Linus Torvalds (torva...@cc.Helsinki.FI) writes:
> Ok, ftp.funet.fi and ftp.cs.helsinki.fi now contain the latest and
> greatest linux kernel, 1.1.61 (also known as "bugfree", for obvious
> reasons). You'll find it as patches against 1.1.60 (also known as "the
> buggy one") in the directories pub/OS/Linux/PEOPLE/Linus/v1.1 and
> pub/Software/Linux/Kernel/v1.1 respectively.
> V1.1.61 does:
> - new Digital EtherWorks 3 ethernet driver (David Davies)
> - updated SBPCD driver (Eberhard Moenkeberg)
> - updated qic-02 driver (Hennus Bergman)
> - fixed floppy blocksize stuff (Bruno Haible and me)
> - various small (u)msdosfs fixes (Jacques Gelinas and Bruno Haible)
> - SysV IPC code cleanups (Bruno Haible again - this man is obviously on
> steroids, and is working on being elected the "Eric Youngdale of the
> year").
But SysV semaphores are still broken.
This simple program run successfully on SysV,FreeBSD,BSD/386 and fails on Linux.
The problem is that in Linux the vector of requests is proceessed by
two loops. First loop tests vector of requests with current value and
second loop perform real change of value.
-----------------------------------8<-----------------------------
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
key_t key = 5325633;
int semid;
#ifdef SYSV
union semun {
int val;
struct semid_ds *buf;
unsigned short *array;
};
#endif
union semun U;
int main()
{
struct sembuf test[3] = {
{0, 0, IPC_NOWAIT},
{0, 1, SEM_UNDO},
{0, -1, IPC_NOWAIT|SEM_UNDO},
};
if ((semid = semget(key, 2, IPC_CREAT|0666)) < 0) {
perror("semget(IPC_CREAT)");
exit(-1);
}
if (semop(semid, test, 3) < 0) {
printf("semop failed:\n");
perror("semop(test)"); /* here we got EAGAIN on Linux */
} else
printf("semop succeded!\n");
if (semctl(semid, 0, IPC_RMID, U) < 0) {
perror("semctl(IPC_RMID)");
exit(-1);
}
return 0;
}
-----------------------------------8<-----------------------------
--
Dmitri Beloslioudtsev, Firm "Orgland", Zelenograd, Russia
e-mail: d...@orgland.ru
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!xlink.net!rz.uni-karlsruhe.de!news.uni-stuttgart.de!
news.belwue.de!news.dfn.de!Germany.EU.net!EU.net!uunet!sensor!dnb
From: d...@orgland.ru (Dmitri Beloslioudtsev)
Subject: Re: Linux 1.1.61, codename 'bugfree' is released
Organization: Firm "Orgland", Zelenograd, Russia.
Date: Mon, 7 Nov 1994 17:00:42 GMT
Message-ID: <Cywpx6.69p@orgland.ru>
X-Newsreader: TIN [version 1.2 PL2]
References: <3980u2$h4j@kruuna.Helsinki.FI> <Cyo1vy.9D4@orgland.ru>
<39crsi$rcm@gate.noris.de>
Lines: 35
Matthias Urlichs (urli...@smurf.noris.de) writes:
> In comp.os.linux.development, article <Cyo1vy....@orgland.ru>,
> d...@orgland.ru (Dmitri Belosludtsev) writes:
> >
> > But SysV semaphores are still broken.
> > This simple program run successfully on SysV,FreeBSD,BSD/386 and fails on
> > Linux.
> >
> > The problem is that in Linux the vector of requests is proceessed by
> > two loops. First loop tests vector of requests with current value and
> > second loop perform real change of value.
> The question is -- do the manpages of a "real" SysV system state that
> something like your test program should work?
> The problem is -- what if you process the list in one loop and get stuck
> someplace (i.e. you have to wait, or to return). Returning is easy, you
> just undo the changes. Waiting is not so easy -- should the kernel back out
> of the changes it made so far before calling schedule()?
Yes, kernel must "undo" all changes made before that moment.
> Is it actually specified that the semaphore list is to be traversed from
> top to bottom? If not, Linux IMHO is doing the Right Thing.
I tried to find information about that in Stevens book and manpages but failed.
But all other unixes run this test ok.
I tried to look at FreeBSD implementation of semop and find special
comments about that.
> Does this test case have any real-life significance? I.e., is there any
> "real" program which actually requires the behavior your test program
> checks for? If so, would somebody please kick its programmer? ;-)
The real peace of code is much complex, but test code tests only
needed part. It was part of DBM system.
Path: nntp.gmd.de!xlink.net!rz.uni-karlsruhe.de!news.uni-stuttgart.de!
news.belwue.de!news.dfn.de!swiss.ans.net!gatech!swrinde!ihnp4.ucsd.edu!
network.ucsd.edu!132.239.1.20!djohnson
From: djohn...@seuss.ucsd.edu (Darin Johnson)
Newsgroups: comp.os.linux.development
Subject: Re: Linux 1.1.61, codename 'bugfree' is released
Date: 07 Nov 1994 23:52:52 GMT
Organization: UCSD Computer Science and Engineering Department
Lines: 45
Message-ID: <DJOHNSON.94Nov7155252@seuss.ucsd.edu>
References: <3980u2$h4j@kruuna.Helsinki.FI> <Cyo1vy.9D4@orgland.ru>
<39crsi$rcm@gate.noris.de> <Cywpx6.69p@orgland.ru>
NNTP-Posting-Host: seuss.ucsd.edu
In-reply-to: dnb@orgland.ru's message of Mon, 7 Nov 1994 17:00:42 GMT
In article <Cywpx6....@orgland.ru> d...@orgland.ru (Dmitri Beloslioudtsev) writes:
> > > But SysV semaphores are still broken.
> > > This simple program run successfully on SysV,FreeBSD,BSD/386 and fails on
> > > Linux.
Your problem it seems is that you are using existing implementations
as your definition of what these operations should do, not the
man page or svid definitions. That's always the wrong way to
go about it.
Instead - none of the man pages I read on various systems
indicated what was to happen in this instance. It's an
ambiguous case - you cannot declare which method is correct
or not.
However, here is a tiny blurb I got on an HPUX system. I don't have
any SVID definitions with me, but I wonder what they say about this.
:Semaphore array operations are atomic in that none of the
:semaphore operations are performed until blocking
:conditions on all of the semaphores in the array have been
:removed.
(of course, a big snag is that HPUX doesn't do it this way,
but processes the ops in order :-)
If that blurb is right, then Linux does things the right
way rather than blindly copying AT&T code. However, IMHO,
either method is correct since it's unspecified, and any
program that depends upon a certain behavior is broken.
> > Is it actually specified that the semaphore list is to be traversed from
> > top to bottom? If not, Linux IMHO is doing the Right Thing.
>
> I tried to find information about that in Stevens book and manpages but failed.
> But all other unixes run this test ok.
That's your big mistake - relying upon what other systems
do rather than upon what the standard says. Find out what
the docs say first. The other systems may be just
guessing, same as Linux.
--
Darin Johnson
djohn...@ucsd.edu
Where am I? In the village... What do you want? Information...
Newsgroups: comp.os.linux.development
Path: nntp.gmd.de!xlink.net!xlink100!smurf.noris.de!msn!faulrs!fauern!
news.th-darmstadt.de!News.Uni-Marburg.DE!news.belwue.de!news.dfn.de!
swiss.ans.net!howland.reston.ans.net!EU.net!news.eunet.fi!KremlSun!
sensor!dnb
From: d...@orgland.ru (Dmitri Beloslioudtsev)
Subject: semop implementation in linux
(Was: Re: Linux 1.1.61, codename 'bugfree' is released)
Organization: Firm "Orgland", Zelenograd, Russia.
Date: Wed, 9 Nov 1994 00:05:23 GMT
Message-ID: <Cyz490.7tw@orgland.ru>
X-Newsreader: TIN [version 1.2 PL2]
References: <3980u2$h4j@kruuna.Helsinki.FI> <Cyo1vy.9D4@orgland.ru>
<DJOHNSON.94Nov7155252@seuss.ucsd.edu>
Lines: 38
Darin Johnson (djohn...@seuss.ucsd.edu) writes:
> In article <Cywpx6....@orgland.ru> d...@orgland.ru (Dmitri Beloslioudtsev) writes:
> > > > But SysV semaphores are still broken.
> > > > This simple program run successfully on SysV,FreeBSD,BSD/386 and fails on
> > > > Linux.
> Your problem it seems is that you are using existing implementations
> as your definition of what these operations should do, not the
> man page or svid definitions. That's always the wrong way to
> go about it.
> Instead - none of the man pages I read on various systems
> indicated what was to happen in this instance. It's an
> ambiguous case - you cannot declare which method is correct
> or not.
> However, here is a tiny blurb I got on an HPUX system. I don't have
> any SVID definitions with me, but I wonder what they say about this.
> :Semaphore array operations are atomic in that none of the
> :semaphore operations are performed until blocking
> :conditions on all of the semaphores in the array have been
> :removed.
> (of course, a big snag is that HPUX doesn't do it this way,
> but processes the ops in order :-)
> If that blurb is right, then Linux does things the right
> way rather than blindly copying AT&T code. However, IMHO,
> either method is correct since it's unspecified, and any
> program that depends upon a certain behavior is broken.
I agree with You that the order of operation in one request is not
described in SVID.
But if we want to achieve SCO binary compatibility with iBCS we must
perform that operation in the same way as SYSV.
Dimitri.