Linux-Development-Sys Digest #225, Volume #6 Wed, 6 Jan 99 07:14:05 EST
Contents:
Re: Linux 2.2 and current->comm ("Bjorn Wesen")
Re: interrupted system calls (Villy Kruse)
Re: Kernel v2.2 (Theo Honohan)
Re: spin_lock* and SMP (Villy Kruse)
Re: Possible Bug in aic7xxx driver / Ultra2Disk ? (Helmut Kreiser)
Re: interrupted system calls (Andi Kleen)
Re: Redefining time_t (H. Peter Anvin)
Re: Kernel v2.2 (Horst von Brand)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: disheartened gnome developer (Christopher Browne)
Re: interrupted system calls (Andreas Schwab)
Timing events via parallel port?... (Maxwell Lock)
----------------------------------------------------------------------------
From: "Bjorn Wesen" <[EMAIL PROTECTED]>
Subject: Re: Linux 2.2 and current->comm
Date: Wed, 6 Jan 1999 01:05:24 +0100
Gerd Rausch wrote in message ...
>that overwriting comm by sprintf(current->comm, "xxx")
>for a process started from within a module by kernel_thread
>doesn't seem enough. "ps" still shows the "insmod ..."
>command line. Is there any trick, to invalidate arguments,
>so /proc/xx/cmdline will stay empty, or any other way making
>"ps" display current->comm ?
/proc/xx/cmdline shows the argv array, not current->comm. have a sneak peek
in the proc code..
current->mm->arg_start and arg_end points to the first and last (maybe
last+1) array element.
kernel_thread shares memory with the parent (insmod) so that's why you see
the parents argv array in the child.
>Another problem I've discovered is connected to signals.
Pass.
/Bjorn
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: interrupted system calls
Date: 6 Jan 1999 09:44:41 +0100
In article <[EMAIL PROTECTED]>,
Brian McCauley <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Constantinos A. Kotsokalis) writes:
>
>> signal(SIGALRM, alh);
>> alarm(5);
>> tmp = recvfrom(sock, (void *)buf, 4, 0, &sender, &sender_len);
>
>> 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.
>
>Really? I thought POSIX explicitly did not define the behaviour of
>signal().
>
>Use sigaction() not signal().
>
Correct!!!!
Note that with glibc you also got BSD signal behaviour; that is,
the interrupted system calls are restarted, except for a few special
calls such as pause(). The handler remains installed when the handler
is called.
There are still a few utility in linux that relies on the SysV signal
semantics and therefore are broken in a way that signals appear to
be ignored. klogd os one of them.
Villy
------------------------------
From: Theo Honohan <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: 06 Jan 1999 08:33:35 +0000
Edward Lee <[EMAIL PROTECTED]> writes:
>
> Nop, modutils is not the right stuff.
> Modules-X.X.X is a stealth package.
> It is still hidden somewhere out there.
> I am wondering why it is not included in the kernel sources.
> Without it, i can't build any modules at all.
This is wonderfully poetic. However, the programs once distributed in
modules-2.0.0 come in a package called modutils now. It really *is*
what you need.
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: spin_lock* and SMP
Date: 6 Jan 1999 09:53:31 +0100
In article <[EMAIL PROTECTED]>,
Martin Recktenwald <[EMAIL PROTECTED]> wrote:
>Hi,
>
>- If yes, it´s necessary to have some kind of lock around critical
> regions. What lock should I use? spin_lock()? spin_lock_irq() (seems
> quite useless because it seems to turn interrupts off only for the
> current processors which should be off when executing the ISR anyway
> - at least I think so) or just a simple spin_lock() (most likely) or
> even spin_lock_irqsave()?
>
The spinlock will halt the other cpu's if it tries to run the protected
code in an interrupt. Disabling interrupt on the current cpu prevents
this cpu to re-enter the interrupt code and hitting the spin lock.
If it did hit the spinlock held by the same cpu it would never get out
of that lock. The other cpus hitting the spinlock will get out as soon
as the cpu holding the spinlokc releases it.
Villy
------------------------------
From: Helmut Kreiser <[EMAIL PROTECTED]>
Subject: Re: Possible Bug in aic7xxx driver / Ultra2Disk ?
Date: Mon, 04 Jan 1999 11:25:38 +0200
Hi,
i got an answer, which i post in this mail. After adding this patch,
all disks were synchronised fine up to 80 MBytes/sec.
(It seems that it wasn't fixed in 5.1.6)
Best regards and a happy new year.
Helmut Kreiser
=>
=> Path:
=>
einstein.sci.de!tppc13.gsi.de!vger.rutgers.edu!owner-linux-kernel-outgoing
=> From: [EMAIL PROTECTED] ("Timm Gleason")
=> Subject: RE: aic7xxx Driver support faster than 20MB/sec?
=> Date: Fri, 4 Dec 1998 14:50:07 -0800
=> Message-ID: <001101be1fd8$704ddaa0$[EMAIL PROTECTED]>
=> Newsgroups: local.linux.kernel
=> Approved: [EMAIL PROTECTED]
=> NNTP-Posting-Host: tppc13.gsi.de
=> Organisation: (mail2news gateway)
=> Xref: einstein.sci.de local.linux.kernel:17946
=>
=> It apparently was a bug concerning use of the Ultra2Wide controller.
I
=> received a forwarded reply from Doug Ledford and added two lines of
code
=> to
=> the driver source that fixed it.
=>
=> Timm Gleason
=>
=> On Mon, 23 Nov 1998, Neil Conway wrote:
=>
=> > Doug Ledford wrote:
=> > >
=> > > That will be fixed in 5.1.5 (a bug introduced by myself
accidentally
=> while
=> > > dealing with YANSF (Yet Another New Seeprom Format)).
=> >
=> > I don't suppose it's a quickneasy fix ? I'm about to bring a
production
=> > machine back on-line this evening for a (hopefully) multi-week run
and
=> > it'd be nice to get the interface back up to speed, as I'll
probably not
=> > get another chance for many weeks... If it's only a two-liner I
could
=> > just patch the kernel.
=> >
=> > sorry to hassle you - the driver is great in all other ways.
=>
=> It is quick and easy. Around line 8352 make the code look like:
=>
=> if (p->flags & AHC_NEWEEPROM_FMT)
=> {
=> if (sc->device_flags[i] & CFSYNCHISULTRA)
=> {
=> p->ultraenb |= mask;
=> }
=> else if (sc->device_flags[i] & CFNEWULTRAFORMAT)
=> {
=> if ( ((sc->device_flags[i] & (CFSYNCHISULTRA | CFXFER)) ==
0x03)
=> &&
=> !(p->features & AHC_ULTRA2) )
=> {
=> sc->device_flags[i] &= ~CFXFER;
=> sc->device_flags[i] |= CFSYNCHISULTRA;
=> p->ultraenb |= mask;
=> }
=> }
=> }
=>
=>
=> Doug Ledford <[EMAIL PROTECTED]>
=> Opinions expressed are my own, but
=> they should be everybody's.
=>
==========================================================================================
Keith Chau wrote:
>
> [EMAIL PROTECTED] wrote:
>
> >Helmut Kreiser <[EMAIL PROTECTED]> wrote:
> >: we are running Linux systems with the new Ultra2 Disk (LVD), with new
> >: ASUS-Boards including aic7890 on board, supporting the lvd-disks.
> >: With the kernel 2.0.35 plus aic7xxx-patch 5.1.2 the disks were
> >: synchronized up to 80 MBytes/sec.
> >
> >: After installing kernel 2.0.36 (with aic7xxx 5.1.4) the disks are now
> >: only synchronized with 20 MBytes/sec !
> >: Other types ogf disks are recognized correct.
> >
> >Same problem here, although on my aic7890 fast/ultra scsi devices are
> >synchronized at 10MBytes/sec with 2.0.36 as opposed to 20MBytes/sec
> >with the patched 2.0.35.
>
> Same problem here! I am using Asus P2B-LS. My IBM U2 LVD drives can
> only be synced at 20MB/s! I am using 2.0.36 with 5.1.6 aic7xxx
> patches.
>
> >: Does anyone have an idea ? Or is it a small bug in the new drivers ?
> >
> >I have looked at differences in the source, but there are too many to
> >check by myself. You could sent a message to the maintainer of the aic
> >code.
--
========================================================================
G S I -- Gesellschaft fuer Schwerionenforschung
Dr. Helmut Kreiser e-Mail: [EMAIL PROTECTED]
-DV&EE- Computing
System Manager DEC/OpenVMS and Linux
Bldg. Sued C, 1.251
Planckstr.1 Tel.: 49-(0)6159-71-2517
D-64291 Darmstadt Fax.: 49-(0)6159-71-2986
========================================================================
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: interrupted system calls
Date: 05 Jan 1999 22:16:56 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Constantinos A. Kotsokalis) writes:
> 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?
glibc uses SYSV signal semantics for signal() per default, this means
that SA_RESTART is implied (this is a change from libc5 BTW). If you
compile your program with -D_BSD_SOURCE defined it'll assume BSD semantics
and not imply SA_RESTART in signal.
POSIX.1 does not define if signal() implies restarting system calls or not -
actually it does not even have a concept of a "system call".
The best alternative is to use sigaction() directly and tell the system
what you want using sa_flags. signal(2) is obsolete.
-Andi
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Redefining time_t
Date: 6 Jan 1999 00:44:34 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
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.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
------------------------------
From: [EMAIL PROTECTED] (Horst von Brand)
Subject: Re: Kernel v2.2
Date: 6 Jan 1999 02:02:59 GMT
In article <[EMAIL PROTECTED]>, Edward Lee wrote:
[...]
>Where did you get the modules package to compile 2.1.132?Did you find a newer
>modules package in debian somewhere?
ftp://ftp.kernel.org/pub/linux/kernel/v2.1/modutils-2.1.121.tar.gz
Note it has a stupid bug:
--- modutils-2.1.121/insmod/modinfo.c.orig Mon Sep 14 14:55:28 1998
+++ modutils-2.1.121/insmod/modinfo.c Tue Oct 27 23:22:32 1998
@@ -457,7 +457,7 @@
error_file = "modinfo";
while (optind < argc)
- show_module_info(argv[optind], fmtstr, do_parameters);
+ show_module_info(argv[optind++], fmtstr, do_parameters);
return 0;
}
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Viña del Mar, Chile +56 32 672616
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Wed, 06 Jan 1999 10:10:02 GMT
Andrew Morton wrote:
>
> Craig Kelley wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ->The Unix model of:
> > ->
> > ->- Every app has its own config file
> > ->- Every app has its own code to read that file
> > ->- Every app needs a restart when something changes (or SIGHUP: almost
> > ->the same thing)
> > ->- Config is local to this host
> > ->
> > ->is _extremely_ dated, unwieldy, unscalable and expensive. It's
> > ->unreliable and requires excessive administration and training resources.
> >
> > And yet nobody has been able to come up with anything better.
>
> IYHO, Craig.
>
> > It is *not* dated, unscalable nor unwieldy. Using tools such as
> > secure shell or rdist one can easily write a program to update
> > numerous machines automatically. It took me less than an hour to come
> > up with a perl script which updates all of our Linux servers
> > automatically. It does this using RSA encryption, and requires each
> > machine's root password to be typed in before it will execute. The
> > reason why these things are so easy to construct: they use PLAIN OLD
> > TEXT and standard I/O.
>
> - no provision for local overrides (inheritance)
> - apps must be restarted
> - requires clients to be online
> - all the other things we've been saying.
>
> > As for it being expensive for "administration and training resources",
> > I have one word: linuxconf. I think you will be very surprised when
> > RedHat 6+Gnome+linuxconf hits the shelves.
>
> Linuxconf is an attempt to graft a uniform interface onto legacy chaos.
>
> What we're doing here is exploring the requirements and design of a
> _new_ approach which will be uniform from end-to-end. Please stop
> shouting at us - some good may come of all this.
>
> A few random thoughts:
>
> - As one of our Microsoft friends pointed out in the halloween docs, the
> OSS community is good at following tail lights. We are now almost in
> the embarrassing position of being in the overtaking lane. It's time to
> look ahead and to innovate. This will require some evolution of the
> communication and management model.
>
> - The discussion here tends to leap ahead of itself: we're getting into
> fine grain implementation issues without having identified the
> requirements. Can we please take this from the top? George's page at
> http://24.1.97.22/gmd/opStore/index.html seems a good starting point.
> I'd like it to have an explicit 'requirements' section.
>
You got it! Still a bit edgy but a start. I also revamped the pages,
and did a project "kickoff". i.e. I'm in for the duration. Comments
are welcome! I'll take care of the web site, project managment chores,
and any other task that needs doing, anything else is up for grabs.
I still need to add all the news articles I keep snarfing, there are so
many good point's being made!!! Keep it up guy's and we will have something
great!!
> - ACAP http://www.ietf.org/html.charters/acap-charter.html has
> everything I want (I think) but it is heavyweight, in the sense that it
> is unsuitable for configuring many of the /etc/*.conf things.
>
> This problem can be resolved with a periodically invoked (or daemon)
> ACAP client which rebuilds /etc/*.conf based on the ACAP server and does
> all the necessary signalling. [ This requires that named, apache, etc
> can all seamlessly hold their current transactional state across a
> SIGHUP. This I doubt. ]
>
If a program had a known point at which it would accept a config change
you could "attach a debugger" to it, set a break point, then when
it hit's do the change. Kinda sneaky, would be better to send the
program some message so it could handle the config change properly.
This means a mod to the code base?
Actually that's the stuff I want to config into treeps, i.e I
want to be able to have a process specific set of commands on
a right mouse click. The menu items will spawn internal/external
actions to perform the task requested. It means config info
for every process, plus knowing what changes from version to version,
system to system ... And I want ot make it easy for others to add
config info! no small task eh! I'll be using just about every
feature we create!
> - Anyone know how to plug into the anonymous IMAP server? "Archive:
> anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap " - Netscape
> won't let me configure an IMAP server alongside POP :-(
>
> - The gnome-list / [EMAIL PROTECTED] folk have pointed out that XML is
> an appropriate data representation.
>
> - George: any ACAP opinions?
Just did a quick scan of the doc, looks interesting, has a couple of nice
things(server side contexts), need to read the details. At a minimum it
could be a plugin module behind one interface. Did a quick scan on
Yahoo, DejaNews and struck out on both, so it's not widely used(yet). Find
any sample implementations? LGPL source?
XML is the closest thing to a clean conceptual storage model that I have heard
about. Actually the protocol I had in mind might be described as
XML on the wire. I was also thinking a push/pull model allowing config
"objects" to flow more freely and allowing for delayed activation and
syncronization for mobile units. I wan't thinking about implementing such
features right away but do want to think about designing them in.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 6 Jan 1999 02:06:24 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 05 Jan 1999 19:46:56 +0000, Walt <[EMAIL PROTECTED]>
wrote:
>> On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne <[EMAIL PROTECTED]>
>> wrote:
>> >In contrast, if you write code that uses Qt, you indeed *do* have to
>> >negotiate licensing with Troll Tech or an assignee thereof depending on your
>> >circumstances.
>>
>> So they might have to read a license agreement before playing around with
>> the software. Big deal. If they don't want to deal with licensing
>> issues, then they can just ignore Qt-devel and live in bliss.
>>
>> >It all really begs the important question:
>> >
>> > Why do you think Red Hat software would consider it a good idea to
>> > promote Troll Tech's programming tools?
>> >
>> >That really is the upshot of it all.
>>
>> Red Hat wouldn't be promoting Qt at all, certainly not any more than
>> they promoted xv, Metro X, or Applixware.
Note that none of [xv, Metro X, ApplixWare] represent, in their normal
use, development tools. Qt does. Development tools, and the
attribution of licensing thereon, is a fairly complex matter.
>> >If someone installs Red Hat Linux, plays with Qt, and then decides that they
>> >like it, they're going to have to pay Troll Tech the >$1K in order to use it
>> >for anything commercial.
>>
>> Again, big deal. So, if they don't want to pay Troll Tech, they can
>> just ignore Qt-devel.
>>
>> >Please explain how this is beneficial to Red Hat Software, when it is pretty
>> >clear that they want to be involved in selling development and systems
>> >integration services.
>>
>> It is beneficial in that some customers want Qt.
>
>QT is doing an open source version for 2.0. Look at the Kde home page
>http://www.kde.org
Which may satisfy some desires, and not others.
>Qt is by far superior to the gnome development libs.
An arguable claim; see <http://www.computers.iwz.com/e-zine/gtk.html>
for the claim that GTk is quite good.
>Its WAY easier to write apps for.
That doesn't parse particularly well. And is, at best, only true for a
subset of situations, particularly those where the remainder of an
applications is being written in C++. The last "library survey" I did
indicated that there don't actually seem to be all that many widely used
Linux applications written in C++.
It is not evident that it is "way easier" to script up applications
using Guile with Qt than it is to do so with GTk. Ditto for writing
applications using C, or Objective C. Those are all situations for
which "helper code" is available for GTk/GNOME whereby GNOME represents
a preferable choice.
--
"By golly, I'm beginning to think Linux really *is* the best thing since
sliced bread." (By Vance Petree, Virginia Power)
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Subject: Re: interrupted system calls
Date: 06 Jan 1999 12:32:10 +0100
Andi Kleen <[EMAIL PROTECTED]> writes:
|> In article <[EMAIL PROTECTED]>,
|> [EMAIL PROTECTED] (Constantinos A. Kotsokalis) writes:
|> > 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?
|>
|> glibc uses SYSV signal semantics for signal() per default
Nope, it uses BSD semantics.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
From: Maxwell Lock <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Timing events via parallel port?...
Date: Wed, 06 Jan 1999 10:59:15 +0000
Hi Folks,
I'm thinking about developing some code to time slot car
races. I want to write this in Ansi C and maybe use some
embedded assembler. I need to be able to time the length and
interval of a pulse on any given parallel port data line to
a fairly good degree of accuracy. As Linux is not a real
time OS and RTLinux is a little overkill I think
(comments?), I'd like to be able to use interrupts or some
such. Has anyone done this before, or know of any source
code I could use as a guide? I am a novice coder, so any
examples would be gratefully accepted! :)
Thanks, Max.
(Hooray for GNU!)
--
Maxwell Lock, Systems Specialist, CRAY Research / SGI UK.
"There are two major products that come out of Berkeley, LSD
and UNIX.
We don't believe this to be a coincidence." -Jeremy
S. Anderson
------------------------------
** 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
******************************
